Security Practices

A third-party attestation means an external auditor has verified our controls. Architectural alignment means the controls exist and operate as designed. We always disclose which level a given framework is at. We never claim a certification we do not hold.

• In transit. TLS 1.2+ everywhere. HSTS enforced on all public surfaces with a one-year max-age.
• At rest (infrastructure). Disk-level AES-256 on PostgreSQL, Redis, and Qdrant volumes by way of our managed providers.
• At rest (application-layer ciphertext for sensitive fields). AES-256-GCM at the application layer for webhook secrets and Bring-Your-Own-Key (BYOK) credentials. Plaintext is returned exactly once on create or rotate; subsequent reads return a redacted preview only.
• Backups. Encrypted with provider-managed keys; rotated on a thirty-day cycle. Deletions propagate from primary stores within twenty-four hours and from backups within thirty days at the latest.

Every table in the application database has PostgreSQL Row-Level Security ENABLE ROW LEVEL SECURITY and FORCE ROW LEVEL SECURITY turned on from day one. Every query runs under a session role bound to the requesting organisation’s identifier; cross-tenant queries return zero rows.

The contract is verified continuously by an automated regression test suite under tests/regression/security/test_*_isolation.py that attempts to access another tenant’s data on every release branch. A failing isolation test blocks release.

• Email + magic link, OAuth (Google, Apple), and SAML 2.0 / OIDC SSO on the Enterprise tier.
• RFC 6238 TOTP two-factor authentication built in-house, no third-party dependency. Backup codes stored as one-way SHA-256 hashes with a partial unique index that prevents re-use. Enforceable per organisation.
• Per-organisation IP allowlist with bare-IP → CIDR canonicalisation backed by the native Postgres CIDR type.
• Per-user role-based access control with granular permissions on every settings surface (USER + PLATFORM tabs).
• Configurable session timeout (Settings → Session timeout); idle sessions are invalidated server-side.

The audit log is an append-only PostgreSQL table protected by RULES that silently swallow UPDATE and DELETE statements. The forensic record survives organisation or user deletion by design, consistent with EU AI Act Article 13 transparency obligations and PHIPA s.10 audit-trail expectations for health information custodians. Customers can stream the audit log to their own SIEM on the Enterprise tier.

Every AI decision is accompanied by a structured trajectory entry (input, plan, tools used, output, confidence, frameworks applied, latency). The trajectory is queryable per decision via /v1/decisions/{id}/explain and exportable as a SOC 2 / HIPAA / GDPR / ISO 27001 evidence pack.

• Zone 6 (Collective cohort math). A three-layer privacy floor enforces a minimum cohort size of five before any aggregate is written: an algorithmic skip when cohort < 5, a PrivacyFloorViolation raised inside the INSERT loop, and a database CHECK (cohort_size >= 5) constraint. All three must agree.
• Zone 7 (Identity synthesis). Every row carries a populated source_zone_versions JSONB envelope with nine required keys. A write that lacks any of the nine keys, or that has zero evidence rows in any of the three input arrays, is fail-closed before the INSERT — no portrait synthesised against zero evidence.

Customers on the Growth tier and above can supply their own OpenAI, Anthropic, or Mistral API key. Prompts and responses are routed directly to the provider whose key was supplied, so regulated data does not leave the customer’s elected LLM tier. Keys are stored as AES-256-GCM ciphertext at the application layer (separate from the database’s disk-level encryption). Multi-key rotation, revoke, and structural test-fire are supported. Real provider-API test-fire with cost guards lands in v1.9.0; AWS Bedrock and Azure OpenAI providers ship in v1.10.0.

• Continuous dependency scanning on every pull request; security advisories are triaged within one business day for High and Critical severities.
• Internal pre-release security audits run by the security-analyst agent before every tag.
• Annual third-party penetration test planned in alignment with the SOC 2 Type 1 audit window (Q3 2026).

We welcome reports from security researchers. Send the details to security@simplification.io with reproduction steps, affected URLs, and (if you have it) a proof of concept. We commit to acknowledge within two business days, confirm or refute within seven business days, and remediate confirmed High/Critical issues within thirty days. We do not pursue legal action against good-faith researchers who comply with the guidelines below:

• do not access, modify, or destroy data that is not your own;
• stop and report on first sight of personal data; do not exfiltrate;
• do not run scanners that produce noticeable load on the public surfaces; rate-limit your tests;
• give us a reasonable disclosure window (default ninety days) before public disclosure.

If an incident affects your data, we will notify the primary administrator email address on the affected accounts without undue delay and, where required by law, within seventy-two (72) hours of becoming aware (GDPR Article 33). The notice will include the nature of the incident, the categories and approximate number of data subjects and records affected, the contact point for further information, the likely consequences, and the measures we have taken or propose to take.

A complete post-incident report is produced within thirty days of containment and shared with affected customers under NDA where appropriate.

Primary and replica PostgreSQL instances run in separate availability zones; daily snapshots are taken and retained for thirty days. Recovery point objective (RPO): twenty-four hours. Recovery time objective (RTO): four hours for the customer SPA and public surfaces; eight hours for full historical analytics. Real uptime SLA is published at trust.simplification.io/uptime-sla.

• Background checks for personnel with production access, where permitted by local law.
• Annual security and privacy training; specialised training on PHIPA / HIPAA for personnel touching healthcare deployments.
• Production access is limited to a named set of engineers under a two-person review for any change touching the audit trail or multi-tenancy enforcement.

The complete procurement-pack — model cards for every LLM tier, the subprocessor list, the uptime SLA, the DSAR self-serve form, and the Article 13 evidence pack — lives on the public Trust Center at trust.simplification.io. Procurement teams can pre-qualify ARIA there before booking a call.

Customers needing the SOC 2 in-progress control matrix, the BAA template (HIPAA), or the standard Data Processing Agreement can request them at trust@simplification.io.

Security incidents: security@simplification.io
Procurement and trust: trust@simplification.io
Coordinated disclosure: security@simplification.io (please use this address even for privacy-adjacent reports so they reach the on-call rota).