Security at Introd

01

Our security principles

Introd is a relationship intelligence product, which means the data we hold is unusually sensitive: who you know, how well you know them and what you have talked about. We design around that rather than treating it as ordinary application data.

Four principles govern every engineering decision we make.

• Collect the minimum. If a feature works without a field, we do not sync the field.
• Compute for one account. Relationship signals derived from your data are only ever surfaced back to you and, where you opt in, your workspace.
• Default to least privilege. Every integration scope, every employee role and every service credential starts at nothing and is widened only with justification.
• Assume compromise. Controls are layered so that a single failed control does not expose customer data.

02

Data classification

We classify all data we hold so that controls, retention and access reviews can be applied consistently. Handling requirements escalate with each tier.

03

Encryption

All traffic between your browser and Introd is encrypted with TLS 1.2 or higher using modern cipher suites; HTTP requests are redirected to HTTPS and HSTS is enabled on our domains.

Data at rest is encrypted with AES-256 by our infrastructure providers, including primary databases, object storage, backups and snapshots. Encryption keys are managed by the provider key management service, are never held in application code and are rotated on the provider's schedule.

04

Infrastructure and network security

Introd runs on managed cloud infrastructure in United States regions. Production is a separate environment from staging and development, with no shared credentials, no shared databases and no copying of production data into lower environments.

• Databases are not publicly routable; access is restricted to application services within a private network.
• Administrative access to infrastructure requires SSO with multi-factor authentication and is limited to a small on-call group.
• Edge protection includes DDoS mitigation, WAF rules and rate limiting on authentication and API endpoints.
• Infrastructure is defined as code and changes are peer-reviewed before they are applied.
• Availability and error-rate monitoring runs continuously with automated paging to an on-call engineer.

05

Application security

Tenancy isolation is enforced at the data layer, not only in application code. Every query against relationship data is scoped by account identity, and row-level policies reject reads that fall outside the caller's tenant.

• Authentication supports multi-factor authentication and SSO on team plans.
• Sessions are bound to short-lived tokens with rotation, and can be revoked centrally by an administrator.
• Input is validated at the boundary; output is escaped by the framework to prevent injection and cross-site scripting.
• Cross-site request forgery protection, strict cookie attributes and a restrictive content security policy are enabled.
• Authorisation is tested as part of the automated test suite, including negative cases for cross-tenant access.

06

Secure development lifecycle

Security work is part of shipping, not a separate gate at the end of a quarter.

• Every change is reviewed by a second engineer before it merges.
• Static analysis, dependency vulnerability scanning and secret scanning run on every pull request.
• Dependencies are patched on a risk-based schedule; critical advisories are actioned within 48 hours.
• Features that touch restricted data go through a written design review covering data flow, retention and access.
• Deployments are automated, versioned and reversible, so a bad change can be rolled back in minutes.

07

Access control and personnel

Access to production customer data is the exception, not a job requirement. Engineers build against synthetic and self-owned data, and production access is requested for a specific reason, for a limited time.

• Access is granted by role, follows least privilege and is reviewed quarterly.
• Break-glass access to restricted data requires a documented reason, an approver and generates an audit record.
• Employee laptops are managed with disk encryption, screen lock and endpoint protection.
• Background checks where permitted by law, security training at onboarding and annually after that.
• Access is revoked on the last day of employment as part of a documented offboarding checklist.

We do not access your message content to browse it. Support staff cannot read message bodies; they see account metadata needed to resolve a ticket.

08

Integrations and permission scopes

Every connected source requests the narrowest scope that makes a feature work. Where a provider offers a read-only or metadata-only scope, we use it in preference to full access.

You can review connected sources in settings and disconnect any of them at any time. Disconnecting stops further syncing immediately and queues deletion of the data derived from that source.

09

Data residency, retention and deletion

Customer data is stored in United States regions. Backups are encrypted and stored in the same jurisdiction.

Retention is tied to the purpose of the data. When you disconnect a source, delete an object or close your account, deletion propagates to production systems and then to backups on our standard backup cycle.

10

Subprocessors

We use a short list of vendors to run Introd. Each is assessed for security posture and bound by a data processing agreement with confidentiality and security obligations. We publish material changes to this list before they take effect and notify customers on annual plans by email.

A current, named subprocessor list with entity names and locations is available on request from security@getintrod.ai and is attached to our data processing agreement.

11

Vulnerability management and testing

We treat vulnerability handling as an operational process with defined ownership and timelines rather than a best-effort activity.

12

Logging, monitoring and detection

Application, infrastructure and administrative access events are shipped to centralised, append-only log storage separate from the systems that generate them.

• Authentication events, permission changes and break-glass access generate alerts.
• Anomaly rules cover unusual export volume, impossible-travel sign-ins and repeated authorisation failures.
• Alerts page a human; there is a documented on-call rotation with escalation.
• Logs are retained for up to 12 months to support investigation.

13

Incident response

We maintain a written incident response plan covering detection, triage, containment, eradication, recovery and post-incident review. Roles are assigned in advance: an incident commander, a communications lead and a scribe.

Notifications describe what we know, what data was affected, what we have done and what you should do — even when the picture is still incomplete.

14

Business continuity and disaster recovery

Production databases are backed up continuously with point-in-time recovery, and backups are encrypted and tested by periodic restore exercises. Restores are practised rather than assumed.

15

AI and automated processing

Introd uses models to extract relationship signals such as who introduced whom, how recent an interaction was and how strong a connection appears. This processing is scoped to your account.

• Customer content is not used to train third-party foundation models, and we contractually require zero-retention or no-training terms from model providers we use.
• Signal outputs are advisory. Introd never sends a message or makes an introduction without an explicit human action.
• Where a score influences ranking, you can see the underlying evidence — the interactions behind it — rather than an unexplained number.
• You can disable model-derived enrichment for your workspace in settings.

16

Compliance and diligence

We build to the control expectations of SOC 2 Type II — access control, change management, monitoring, vendor management and incident response are documented and operating — and we are progressing towards formal attestation. We will publish the report here when it is issued and will not claim a certification before it exists.

For GDPR and UK GDPR, Introd acts as a processor for customer data and a controller for account data. We offer a data processing agreement including standard contractual clauses for international transfers. For CCPA/CPRA we act as a service provider and do not sell or share personal information.

17

Controls you hold

Security is shared. These controls are available to you today, in the product, without contacting support.

• Multi-factor authentication on your Introd login, and SSO enforcement on team plans.
• Role-based permissions in team workspaces, including view-only roles.
• Session review and remote sign-out of any device.
• Per-source connection review, with one-click disconnect and derived-data deletion.
• Visibility settings that control what teammates can see about your relationships.
• Full data export in a portable format, and account deletion from settings.
• Audit log of workspace membership and permission changes on team plans.

18

Responsible disclosure

If you believe you have found a vulnerability, email security@getintrod.ai with steps to reproduce, the affected endpoint and any supporting evidence. We acknowledge within one business day and keep you updated until the issue is closed.