Security overview
How Pact protects your data: encryption, tenant isolation, RBAC, and audit logging.
Pact is built for teams that handle sensitive customer data. Security is a first-class concern at every layer of the stack.
Encryption
In transit — All traffic is served over TLS 1.2+. Pact enforces HTTPS at the edge (cloud CDN) and rejects plaintext connections.
At rest — Data is stored in a managed Postgres service with Transparent Data Encryption (TDE) enabled. In-memory cache and queue run in a private network with no public endpoint. Backup snapshots are encrypted with platform-managed keys.
API keys and credentials — Integration credentials (OAuth tokens, SMTP passwords, AI API keys) are encrypted with AES-256 before being written to the database. The encryption key is stored in a dedicated secrets vault, separate from the application.
Tenant isolation
Pact is a multi-tenant system. Every database table that stores customer data has a tenant_id column. Every API request is authenticated and the tenant_id is derived from the auth context — it can never be passed in the request body by a client. The database query layer enforces tenant scope on every read and write.
Tenants cannot see each other's data. Even if two tenants use the same Pact instance, their data is logically isolated at the query layer and separately encrypted.
Authentication
Email + password — Passwords are hashed with bcrypt (cost factor 12). Password reset emails expire after 1 hour.
SSO — Organizations can configure SAML 2.0 or OIDC single sign-on via Settings → Security → SSO. When SSO is enforced, email/password login is disabled.
Session tokens — Sessions are short-lived JWTs (1-hour access token, 7-day refresh token). Refresh tokens are rotated on each use.
MFA — Under Settings → Security & MFA, each user can register passkeys (sign-in) and an authenticator app with one-time recovery codes (confirming sensitive changes). Owners and admins can require a passkey for every sign-in on the same page, and require MFA per role under Admin → IAM → Policies. See Multi-factor authentication.
Role-based access control (RBAC)
Every user belongs to one or more roles. Built-in roles:
| Role | Capabilities |
|---|---|
| Owner | Full access; billing; manage tenant settings |
| Admin | Manage users, integrations, sequences; cannot change billing |
| Member | Create/edit contacts, accounts, sequences; no settings access |
| Viewer | Read-only across all CRM data |
Custom roles are available on the Enterprise plan. Go to Settings → Roles to create and assign them.
Audit logging
All user actions that modify data generate an audit event: create, update, delete, permission changes, login and logout. Audit events include:
- Timestamp (UTC)
- Acting user ID and email
- Resource type and ID
- Old and new values (for update events)
- IP address
- Tenant ID
Audit logs are available in Settings → Audit Log and can be exported as CSV. Logs are retained for 90 days on standard plans and 1 year on Enterprise.
Vulnerability disclosure
If you discover a security vulnerability in Pact, please email [email protected]. We aim to acknowledge reports within 24 hours and resolve critical vulnerabilities within 72 hours. We do not operate a bug bounty program at this time but will credit researchers who report in good faith.
Compliance
Pact's architecture is designed to support GDPR compliance. See Privacy & GDPR for details on consent management, data subject rights, and data processing agreements.
Pact runs its own SOC 2 control program in the product: a policy library mapped to every Trust Services criterion, automated evidence collection, and a signed auditor package that lists every control with its owner, governing policy, evidence and last test date, including the gaps. No independent audit has started yet, so there is no SOC 2 report. Our managed Postgres provider holds SOC 2 Type II attestation for the data layer; that attestation is the provider's. Contact [email protected] for the evidence package under NDA.