Compliance & SOC 2 readiness
Audience: Compliance officers, security architects, DevOps leads
Time: ~20 min
Prerequisites: Security overview, Shared responsibility matrix
Control Core ships with the engineering controls that a regulated enterprise needs to enter a SOC 2 Type II observation window. This page explains what the product provides, what you — the operator — are responsible for, and how to use the evidence artifacts.
What "audit-ready" means
Control Core is audit-ready: the technical controls are implemented in the product, generate verifiable evidence, and are covered by automated tests. It is not yet audit-attested: attestation requires an independent CPA firm, a 3–12 month observation window, and operator-owned governance items that no software vendor can produce on your behalf.
Terminology guardrail: No vendor documentation, marketing material, or sales communication claims a completed SOC 2 Type II attestation, a passed third-party penetration test, or measured disaster-recovery RTO/RPO figures. When you see "audit-ready" it means the engineering controls are in place; when you need the attestation, that is your observation window plus your CPA engagement.
Engineering controls the product ships
| TSC area | What is implemented |
|---|---|
| Access control (CC6) | Role-based API protection, MFA at login, SAML 2.0 and OIDC+PKCE enterprise SSO, RS256/EdDSA session tokens, JWKS rotation, Rego enforcement at the Bouncer |
| Encryption in transit (CC6.7) | TLS-default ingress at the Bouncer, production connection guards for the data store and cache, Helm TLS wiring templates |
| Supply chain (CC6.8) | Optional image signing with cosign, SLSA provenance, SBOM generation |
| Audit integrity (PI1) | Hash-chained audit log, optional WORM checkpoint to object storage |
| Recovery (CC7.5) | Optional database backup CronJob in the deployment chart |
| SOC 2 Rego controls | Three enforceable controls shipped as templates: access-control, change-management, monitoring-logging |
For step-by-step configuration, see the guides below.
Shared responsibility — what you operate
Control Core is deployed in your environment. SOC 2 attestation for your service requires:
| You operate | Notes |
|---|---|
| Identity provider (IdP) configuration | Connect your SAML/OIDC IdP and assign roles |
| Enable and manage TLS certificates | Mount certs in the deployment chart; enforce sslmode=verify-full and rediss:// for your data stores |
| SIEM forwarding and log retention | Forward audit events to your SIEM; set retention policy |
| Mandate signed image tags for production | Run cosign verify as a deployment gate |
| Database encryption at rest | Enable TDE / disk encryption at the infrastructure layer |
| Backup enablement and DR drills | Enable the backup CronJob; run restoration exercises |
| 24/7 incident monitoring and runbooks | Not provided by Control Core |
| Governance: board oversight, risk register, HR controls | CC1–CC5 COSO-layer items — process controls, not product code |
| Penetration test engagement | Third-party independent security firm |
| CPA observation window | 3–12 months of documented control operation |
For a complete breakdown, see the Shared responsibility matrix.
Audit-attested vs audit-ready (Tier 1 / Tier 2)
The readiness gate has two explicit tiers:
Tier 1 — engineering-delivered (complete)
All controls have a description, an implementing code path, an evidence artifact, and a passing automated test. A pilot deployment may begin.
Tier 2 — operator/business-delivered (your responsibility)
- Third-party penetration test and remediation ledger
- Load and capacity re-baseline on a production-representative cluster
- Disaster-recovery drill with documented RTO and RPO
- SOC 2 Type II observation window (3–12 months) and CPA engagement
- Internal go/no-go review by your engineering, product, and security leads
- CC1–CC5 governance controls (organizational policies, ethics, board oversight)
The SOC 2 Type II report requires Tier 2 completion. Entering a pilot or beginning the observation window requires only Tier 1.
Troubleshooting: If your compliance team asks for a vendor SOC 2 report, explain that Control Core is deployed in your environment (not as a managed SaaS); the vendor provides evidence artifacts, not a vendor attestation. Your CPA will assess the controls operating in your deployment. Contact your account team for a trust-center one-pager.
Evidence artifacts your CPA can use
| Need | Where to find it |
|---|---|
| System description and service boundary | Request from your account team (based on your deployment configuration) |
| Vulnerability scan for your release tag | Your CI/CD pipeline reports |
| Signed image verification | cosign verify output archived with your change record |
| Audit log integrity check | Audit export API on your Control Plane |
| SOC 2 Rego control templates | Download from Controls → Templates in your Control Plane |
Enabling the controls
| Control | Guide |
|---|---|
| Image signing and SBOM | Supply chain verification |
| Postgres and cache TLS | Data plane hardening |
| Audit hash chain and SIEM | Audit tamper evidence |
Troubleshooting: If the Control Plane reports that TLS connection guards are inactive, check that
sslmode=verify-fullandrediss://endpoints are set in your deployment chart values and that the CA certificate is mounted. See Data plane hardening → Troubleshooting.
Next steps
- Shared responsibility matrix — full TSC ownership breakdown
- Supply chain verification — image signing, cosign verify, SBOM
- Data plane hardening — Postgres and cache TLS configuration
- Audit tamper evidence — hash chain and WORM checkpoint