Security Practices

01Scope and approach

This page describes how Adoptiv Inc protects the data customers put into the product. It is written to be checked. Where we describe a control, it is a control that exists and that you could ask us to demonstrate. Where we do not have something, this page says so rather than reaching for a phrase that sounds like we do.

Two things follow from that. We do not describe a testing calendar we cannot keep to, and we do not publish a recovery time we have not measured. Both are common on pages like this one and both are worth less than nothing, because the first person to check them finds out.

Adoptiv Inc is a Delaware corporation at 2810 N Church St STE 88783, Wilmington, DE 19802, United States. Security questions go to security@adoptiv.com.

02Access control

Who can see a record inside a workspace is decided by the customer, not by us.

• Role hierarchy. Roles form a tree. A role sees its own records and, by default, the records of the roles beneath it. Moving a person in the tree changes what they can see immediately, because the permission caches for that workspace are flushed as part of the change rather than left to expire.
• Permission profiles. Each role points at a profile that holds the actual permissions: which objects can be read, created, edited, deleted, exported and imported, and which administrative capabilities are granted.
• Sharing rules. Access across branches of the tree is granted explicitly by a rule, so a sales manager can be given a peer team's pipeline without being moved above them.
• Field group permissions. Permissions go below the record. A field group, for example the financial fields on a company, can be hidden or made read-only for a profile while the rest of the record stays visible.
• Single sign-on. SAML 2.0, and OAuth 2.0 with Google Workspace and Microsoft Entra ID. The OAuth flow uses PKCE and a nonce, both bound to the browser that started the sign-in, and a state value that is checked on the way back.
• Multi-factor authentication. Time-based one-time codes, with recovery codes issued at setup.
• Sessions. The session cookie is HttpOnly, SameSite Lax, and Secure in production. It lasts 7 days, or 30 days if the person asks to be remembered. An administrator can force a member's sessions to end immediately.

Adoptiv staff do not browse customer data. A platform administrator can enter a workspace to support it, and when they do: the session is capped at 4 hours, the original administrator session is held separately and handed back at the end, a banner is shown for the whole session, the support messenger is suppressed so no conversation is ever opened as the customer, and the entry is written to the audit log.

03Encryption

In transit, everything is carried over TLS. Call media between the browser and our telephony fleet is carried over SRTP.

At rest, the secrets that would be most damaging to lose are encrypted before they are written to the database. Mail account credentials and integration OAuth tokens are encrypted with AES-256-GCM. Each record gets its own random salt and its own initialisation vector, the key is derived per record with PBKDF2-SHA256 at 100,000 iterations, and the GCM authentication tag is verified on read, so a modified ciphertext fails to decrypt rather than decrypting to something else.

The application refuses to start in production without an encryption key configured. There is no silent fallback to a default key outside development.

Passwords are never stored, in any form that can be turned back into a password. What is stored is a PBKDF2-SHA256 hash at 100,000 iterations with a random salt generated per password, and sign-in compares the hashes in constant time so the comparison itself leaks nothing.

Card numbers never reach Adoptiv. Payments go to Stripe, a PCI-DSS payment processor, and what we hold is a token that is useless anywhere else.

04Tenant isolation

Every customer workspace gets its own PostgreSQL schema. Your contacts, deals, calls, custom fields and audit records live in tables that belong to your workspace and to nothing else. There is no shared table with a tenant column that has to be filtered correctly on every query.

Be clear about what that is and is not. This is logical isolation, enforced at the query layer: workspaces share database infrastructure, and they do not share tables. It is not physical isolation, and we will not describe it as such.

The mechanism is that a request resolves its workspace first, from the host it arrived on and only then from the session, and the database client handed to the rest of the request is already bound to that workspace's schema. Code further down the request cannot reach another workspace's tables by forgetting a filter, because it never holds a connection that can see them.

05Controls built into calling

Some of what protects your business is in the dialer rather than in the infrastructure.

• Do-not-call screening runs before the dial, not after it. A number that screens as listed does not get connected.
• Litigator screening runs on the same check, so numbers associated with serial filers are flagged before a rep is on the line.
• Calling hour rules are applied per contact, so a dial that would land outside permitted hours where the contact is does not go out.
• Compliance lookups run in a separate service that owns the compliance database and its credentials. The web application cannot query it directly, calls to it are authenticated, and each lookup is logged.

06Network and infrastructure

Adoptiv operates its own infrastructure. Web application hosting runs on machines the company runs itself, in Europe and the United States. We are not reselling a platform and describing it as ours.

The database tier is PostgreSQL, with a primary and read replicas distributed across separate datacenters, fronted by connection pooling and load balancing, with automatic failover under a quorum that spans three locations so the loss of any one location does not take the cluster with it.

Databases are not reachable from the public internet. They are reached by the application tier over a private network, and administrative access is restricted to the machines that need it.

The telephony fleet is likewise ours. Signalling and media pass through infrastructure we provision and configure, rather than through a general-purpose voice reseller.

07Secure development

The practices, rather than a cadence we would then have to defend.

• Changes are reviewed before they merge and go through automated checks before they deploy.
• The codebase is typed end to end, and request bodies are validated against schemas at the API boundary rather than trusted and then patched up later.
• Mutating endpoints carry an explicit permission guard. The posture is deliberate and uniform: workspace administrators pass, everyone else needs the specific capability on their profile.
• Dependencies are pinned by lockfile so a build is reproducible and a compromised upstream release cannot arrive unannounced.
• Secrets live in environment configuration and are never committed to the repository.
• Errors from production go to Sentry, where they are triaged rather than watched.

On independent testing: we do not publish a penetration test schedule here, because publishing one we then miss is worse than publishing none. Where a customer requires an independent test, the scope and timing are agreed in the contract, and we will share the result of a test we have commissioned under an appropriate agreement.

08Logging and monitoring

Access and changes are recorded. An audit entry holds the action, who performed it, the workspace, the resource and its identifier, the address the request came from, the browser and device, and the time. Sign-ins, permission changes, role and team changes, exports and support sessions all write entries.

Application errors and performance go to Sentry. Sentry's session replay is configured to mask all text and block all media, so what an engineer sees while reproducing a crash is the shape of the page and not the contents of your records.

09Vendors and sub-processors

Adoptiv uses a small number of third parties to run the service. Every one of them is named, with what it does and where it processes, at /legal/sub-processors. That page is the list, and it is kept current rather than written once.

A vendor is assessed before it is introduced: what data it would touch, whether it is necessary, where it processes, and what its own security posture and contractual commitments are. Vendors that process personal data on our behalf are under a written processing agreement with the transfer mechanisms the law requires.

Customers under a data processing agreement are told before a new sub-processor starts, with time to object. The terms of that are at /legal/dpa.

10Business continuity and backups

The database cluster replicates continuously to standby nodes in separate datacenters, and failover to a standby is automatic rather than a call somebody has to make at three in the morning.

Backups are taken on a schedule and held separately from the running database, so a failure that destroys the primary does not destroy its backups. A workspace schema can be restored on its own, without restoring every other customer alongside it.

We do not publish a recovery time objective or a recovery point objective on this page, because a figure we have not measured under load is a guess presented as a promise. Where a contract requires those figures, they are agreed in that contract and we hold ourselves to what we signed. The uptime commitment we do make is at /legal/sla.

11Incident response

Security incidents have one intake, security@adoptiv.com, monitored by the people who can act on what arrives.

The sequence is triage, contain, eradicate, recover, and then a written review of what happened and what changes as a result. Containment comes before diagnosis: we would rather cut off access and understand it afterwards.

Our notification commitment is specific. Where a personal data breach affects your data, we will notify you without undue delay and in any case within 72 hours of becoming aware of it. Where the law requires notification to a supervisory authority, that goes within the same 72 hours. The first notice will be sent with what is known at the time rather than held back until the picture is complete, and it will be followed as the picture changes.

The notice will say what happened, which categories of data and roughly how many records are affected, what we have done, what we are still doing, and what you should do. If we do not yet know something, the notice will say that rather than leave it out.

If you have found a vulnerability rather than suffered an incident, the reporting process, the rules and our safe harbour commitment are at /legal/vulnerability-disclosure.

12Certifications

The SOC 2 audit is in progress.

13Requesting documentation

Write to security@adoptiv.com. Say who you are, which company you are evaluating on behalf of, and what you need.

• Security questionnaires: send yours and we will complete it. We do not require our own form.
• Architecture and data flow summary: available under a mutual non-disclosure agreement.
• Sub-processor list: published, no request needed, at /legal/sub-processors.
• Data processing agreement: at /legal/dpa, countersigned on request.
• Retention and deletion schedules: at /legal/retention.
• Penetration test results: shared under a non-disclosure agreement where a test has been commissioned.

If something on this page is not clear enough to rely on in a review, say so and we will make it clearer. Adoptiv Inc, 2810 N Church St STE 88783, Wilmington, DE 19802, United States. Phone +1 (636) 556 0022.