Security & compliance posture.

§1 · Encryption in transit and at rest.

Every API call sits behind TLS 1.3; no plaintext ingress or egress is supported on the write path. The TLS configuration is pinned to modern cipher suites only — no fallback to TLS 1.0 / 1.1, no RC4 / 3DES. HSTS is set on the public surface and the API origin with subdomains, so a downgrade attempt does not silently succeed. Internal services talk to each other over mTLS on a private overlay; nothing crosses the trust boundary in cleartext.

Evaluation records at rest are protected by AES-256 in the ledger substrate. The signing key that binds records into the tamper-evident chain is anchored to the buyer's KMS rather than to the production write path: every evaluation record is authenticated with HMAC-SHA-256using a per-workspace key derived from the deployment's signing secret (folded to its first-16-hex-char fingerprint at verify time). The HMAC is computed over the canonical-JSON view of the record — input digest, scorer output, model id / version, timestamps — so any post-hoc edit invalidates the row and the chain link it joins.

Tamper-evident audit PDFs (the export bundle from /dashboard/audit-export and the workspace export from /api/audit-export-workspace) carry a SHA-256 footer on the cover, plus the matching X-PDF-SHA256 response header on the download. The footer is the deterministic hash of the canonical-JSON payload (start, end, runs, sign-off state); the header is the SHA-256 of the PDF bytes themselves — one covers the contents, the other covers the file. An auditor can verify both with sha256sum on the downloaded file plus a one-line canonicalization script on the contents.

Keys are rotated on a published cadence; rotation events are themselves records in the chain, so a re-key never breaks continuity of the evidence trail. Bytea-level redaction is applied to PHI fields before chain linkage, so the auditor sees provenance without ever reading the underlying payload.

§2 · Access controls on evaluation traces.

Role-based access control applies at both write and read. The write path enforces a schema-level RBAC check on every record; the read path enforces an attribute-based filter on top of the chain role. Auditor-only fields (raw inputs, annotations, incident comments) ship default-deny — they are present in the record but invisible until a role explicitly grants visibility.

The examiner-read-onlyrole is what PI-grade teams use: it can walk the chain from any signed record back to its inputs and scorer output, but cannot write, delete, or re-tag. PI tagging happens at write time, scoped by access role, so PHI never lands in a record a non-PI reader can open. Admin actions — sub-processor changes, retention-window edits, key rotation — are themselves signed records on the same chain as the action they affect.

§3 · Retention defaults.

Retention is configured at write time, scoped to the regulatory window the record falls under. The defaults below come straight from tier-catalog.ts — the same source of truth the buyer sees on the pricing and access-control pages — so the table on this page cannot drift from the runtime config.

The 7-year row covers both the SOX-aligned change-record window and the HIPAA-adjacent clinical-evidence window, by design — a single retention horizon that survives the union of buyers' typical audit windows without a per-model override. Enterprise tiers can negotiate a buyer-specific window against the DPA; the entitlement is surfaced on the tier card under customRetention.

The retention policy itself is a record in the chain. When the auditor asks “how long was this scorekeeper set to keep these records,” the policy under which the answer is true sits in the same hash chain as the records it captures.

§4 · Return and deletion of data on cancellation.

At cancellation we hand off an export bundle in the format the buyer's DPA names (raw records plus the chain, plus a signed verification manifest). Production-side hard-deletion runs on a published schedule after handoff; backup-side deletion runs on the backup rotation schedule after that, with both events written into the same chain the records lived on.

The deletion timeline, the handoff format, and the verification manifest are all written into the DPA at signature, so the auditor can read the answer there without having to ask. Cancellation is a record, not a silent event.

§5 · Sub-processor categories.

We use four categories of sub-processor: managed-hosting providers, transactional email, payment processing, and observability tooling. The current vendor list under each category is published in full at /sub-processors (with residency per processor), and a signed sub-processor disclosure is delivered under NDA on request when procurement needs the named-vendor view ahead of contract.

Sub-processor changes are announced in writing on a published notice window before taking effect, so the buyer has time to object before a new vendor sees their chain data. The full list, the data each category handles, and the residency of each are in the DPA.

§6 · Certification & readiness status.

SOC 2 Type II:in progress. Evidence collection against the 2024 Trust Services Criteria (Security, Availability, Confidentiality) is mid-buildout; the readiness assessment is scheduled to close before the formal observation window opens. We will share the bridge letter on request once the observation window closes; the auditor's name and the report type are listed in the DPA at signature. Read this as a roadmap line, not a “we are certified” claim — the program ends when the report issues, and we will say so on this page when it does.

HIPAA: posture delivered via a signed Business Associate Agreement on the Enterprise tier (see features.baa in tier-catalog.ts). The BAA's PHI provisions map onto §2 (RBAC) and §3 (retention) above; PI-tagging is enforced at write time, so PHI never lands in a record a non-PI reader can open. The BAA is available on request at the procurement stage.

GDPR: posture delivered via a Data Processing Agreement, an EU-representative path, and the region-pinning option in §7 below. Data-subject access requests hit a documented response window; the DPA names the EU representative the controller can serve notice on. The buy-side record of all three (SOC 2, HIPAA, GDPR) is the DPA itself.

§7 · Data residency.

By default, evaluation records are stored in the buyer's nearest primary region. Enterprise buyers can pin records to a specific region via workspace.region during onboarding, and switch regions with a documented cutover: the cutover writes a new chain head in the destination region before any record moves, so a partial migration is never observable on the buyer's side.

Region-pinned residency is an Enterprise conversation (see complianceAddOns.residency in tier-catalog.ts) ); the Evidence Pilot and Regulated Team ship US-resident by default. Cross-region replication is opt-in and disclosed in the buyer's DPA; the default is single-region storage.

§8 · SSO / SAML availability per tier.

SAML 2.0 single sign-on and SCIM 2.0 provisioning are gated by tier. The matrix below comes straight from features.ssoSaml on the tier record — the same source of truth the comparison matrix on /pricing reads — so a tier change at the catalog level is reflected here on the next deploy. SSO is enforced on Enterprise; Regulated Team can discuss optional SAML, while the Evidence Pilot stays intentionally focused.

Supported identity providers on Enterprise: Okta, Microsoft Entra ID, Google Workspace, JumpCloud, and any SAML 2.0-compliant IdP. Just-in-time provisioning via SCIM is required on Enterprise; Enterprise can also discuss federation with buyer-managed IdP groups so role assignments flow from the buyer's HR system rather than from inside Plumbline.

§9 · Incident response.

We run a 24×7 on-call rotation with paged escalation paths. Customers are notified through the channels listed in the DPA (email to the listed security contact, plus the in-app status page), and buyer-side incident briefings are scheduled within the SLA window regardless of root cause. Incident timelines, postmortems, and the chain records that anchor them are published to the buyer's security contact on completion; SEV-1 and SEV-2 incidents also write a chain event capturing the scope and the response window, so an auditor can read the incident history on the same chain as the records it touched.

The on-call rota, the runbooks, and the escalation matrix are reviewed quarterly. The page-tier SLA for the chain write path is tracked on /status — the same surface the auditor's Service Organizationquestion typically refers to — and 90-day uptime is published there for buyers under SLA obligations.