Data security policy.

01Encryption at rest

Every store that holds customer Personal Data is encrypted at rest with AES-256. That includes Postgres clusters, DO Spaces object buckets, Redis snapshots, backup archives, and any local disk on a production VM that touches customer data. There is no opt-out and no "legacy unencrypted" tier.

We use envelope encryption: a per-resource data encryption key (DEK) protects the bytes, and a master key in AWS KMS (the key encryption key, KEK) protects the DEKs. The KEKs are managed by Message and rotated on a quarterly schedule. Enterprise customers can supply their own KMS keys (bring-your-own-key), in which case revocation by the customer immediately breaks decryption of new reads.

02Encryption in transit

All inbound and outbound traffic uses TLS 1.2 at minimum, TLS 1.3 preferred. TLS 1.0 and 1.1 are refused at the edge. We publish HSTS with includeSubDomains and a 1-year max-age, and message.com is on the HSTS preload list shipped with major browsers.

Internal service-to-service traffic between production nodes is also TLS-encrypted; we do not assume the private network is safe. Database connections from application servers to Postgres use TLS with certificate verification.

The widget bundle served from CDN is signed with subresource integrity (SRI) hashes so customers can detect tampering at load time.

03Key management

Production secrets, API keys, and database credentials are stored in AWS KMS-backed Doppler vaults. Application code reads secrets at boot via the standard SDK; secrets are never committed to source control, baked into Docker images, or written to logs.

Master encryption keys (KEKs) rotate quarterly. Data encryption keys (DEKs) rotate on the same cadence for cold storage and on a per-write basis for high-churn data. Old DEKs remain available for decryption of historical reads until the data is re-encrypted under the new key, then the old DEK is destroyed.

Access to the KMS console is restricted to a small number of named engineers (currently two). Every key operation produces an immutable CloudTrail log entry retained for at least 12 months.

04Access controls

Production access is governed by:

• SSO with mandatory MFA. No password-only access exists for any production system. MFA factors are restricted to TOTP and WebAuthn; SMS is not accepted.
• Role-based access control. Engineers, support staff, and finance have separate roles with least-privilege scopes. There is no shared "admin" account.
• Just-in-time elevation. Sensitive actions (running a production query, touching a customer record, reading a call recording) require a ticket-bound, time-boxed elevation that auto-expires.
• Quarterly access reviews. Every named identity is reviewed against the role matrix once a quarter. Stale access is removed within five business days.
• Offboarding within 30 minutes. When a staff member leaves, the SSO directory disables their identity and every downstream system loses access automatically.

05Logging and audit

We log every authentication event, every privileged action against production, every read of a customer record by a Message employee, and every API call from a customer integration. Logs are streamed to Grafana Cloud and to an immutable write-only S3-compatible bucket with object lock enabled. Retention is 12 months minimum for security-relevant logs, 30 days for application telemetry.

The audit log is append-only: nobody, including the engineers who run the platform, can edit or delete a past entry. Tampering attempts are themselves logged.

Customers can pull their workspace's audit log via the Settings dashboard or the audit-log endpoint of the REST API. Enterprise customers can stream the log to their own SIEM (Splunk, Datadog, Sumo Logic, Panther) in near real time.

06Vulnerability management

We treat vulnerability management as continuous, not a once-a-year checkbox.

• Static application security testing (SAST) runs on every pull request via GitHub Advanced Security and Semgrep. Builds fail on new high-severity findings.
• Dynamic application security testing (DAST) runs nightly against a staging environment that mirrors production.
• Dependency scanning (Dependabot and Snyk) raises pull requests for known-vulnerable packages within hours of publication.
• Container scanning runs at image build time and weekly against the running registry.
• Independent penetration testing happens quarterly. Current providers under rotation are Cobalt and Bishop Fox. Findings are remediated on severity-based SLAs: critical in 7 days, high in 30, medium in 90.

Customers can request a redacted pentest letter (scope, methodology, severity counts) under NDA. Email [email protected].

07Secure development

Every change to production passes through:

• Mandatory code review by at least one engineer other than the author.
• Automated test suite (unit, integration, end-to-end) before merge.
• Signed commits with verified email identities.
• SAST and dependency scanning gates as described above.
• Staged rollout to a canary subset of workspaces before fleet-wide deployment.
• Automated rollback on error-rate or latency regression beyond a defined threshold.

Production hotfixes follow the same pipeline. There is no "emergency push" that bypasses review or testing. If we cannot ship a hotfix safely, we accept the incident and communicate openly.

08Network security

Production runs in private VPCs with the database tier on private subnets that have no public ingress. Application servers reach the database over a private network only. Administrative access from Message staff to the production network is mediated by Tailscale, with device posture checks (OS up to date, disk encryption on, screen lock enforced).

Cloudflare sits in front of every public endpoint, providing DDoS protection, bot management, rate limiting, and a managed WAF. Origin IPs are not published, and the origin only accepts inbound traffic from Cloudflare ranges.

Hardware that hosts AI inference (the self-hosted GPUs in Houston) sits behind the same Tailscale tailnet as production application servers. There is no public IP exposing the inference endpoints.

09Incident response

We maintain a written incident response plan that covers detection, triage, containment, eradication, recovery, and post-incident review. The plan is exercised at least twice a year (one tabletop, one live drill on a non-production environment).

• Named on-call rotation, 24/7, with a 30-minute paging SLA for severity-1 incidents.
• Status page at status.message.com is updated within 15 minutes of confirmation of a customer-impacting event.
• For Personal Data breaches, the customer's security contact is notified without undue delay and within 72 hours of awareness, as required by the GDPR.
• Post-incident reviews (blameless, public for customer-impacting incidents) ship within 10 business days.

Suspected vulnerabilities or active incidents involving Message infrastructure should be reported to [email protected]. Our PGP key is published on the same page.

10Workspace isolation

Every workspace is isolated at the database row level using Postgres Row Level Security (RLS) policies. Every table that contains workspace-scoped data carries a workspace_id column with an RLS policy that prevents one workspace from reading or writing rows belonging to another. The policy is enforced by the database, not by application code; even a serious application-tier bug cannot expose cross-workspace data.

File storage is partitioned by workspace into prefix-based key spaces on DO Spaces, with bucket policies that enforce the prefix at the object-store layer. Signed URLs include a workspace claim and expire on a tight schedule.

Background jobs are queued per workspace; a noisy workspace cannot starve another of compute. Rate limits are enforced per workspace at the edge.

11Backups and disaster recovery

We back up customer data continuously:

• Postgres point-in-time recovery (PITR) with a 30-day window, plus hourly full-cluster snapshots retained for 30 days.
• Object storage is versioned with a 30-day retention window for soft-deleted versions.
• Backups are encrypted with the same KMS-managed keys as production data, stored in the same region as the source workspace.

We perform a monthly restore drill in a clean environment to verify that backups are actually restorable. The restore time objective (RTO) for a single-region full disaster is 4 hours; the restore point objective (RPO) is 15 minutes.

12Compliance posture

Current and in-flight attestations:

• SOC 2 Type II: in-progress. First Type I report is expected Q3 2026, Type II coverage period begins immediately after. Available under NDA.
• ISO 27001: target certification Q4 2026.
• GDPR: data processing addendum at /legal/dpa; sub-processor list at /legal/sub-processors.
• CCPA / CPRA: privacy disclosures in the Privacy Policy; rights requests at the privacy email address.
• HIPAA: BAAs available for Enterprise customers on a configuration that disables AI features and third-party LLM fallback.
• PCI DSS: not applicable; payment card data is processed exclusively by Stripe under their PCI DSS Level 1 attestation.

Attestation reports are available under NDA. Email [email protected] or [email protected].

13Responsible disclosure

We invite security researchers to test Message for vulnerabilities under the program at /security. Coordinated disclosure terms apply:

• Stay within scope (production message.com and app.message.com; no social engineering of staff).
• Do not access, modify, or destroy customer data.
• Give us 90 days to remediate before publicizing details.

Reports come to [email protected]. We respond within two business days, triage within five, and credit you publicly if you wish.