SOC 2 control summary
Production deployments are designed for SOC 2 diligence with controls across identity, segregation, secrets, audit, supply chain, and availability. Use this page as a questionnaire index (control matrix and Trust Service Criteria map). For question-and-answer copy you can paste into vendor forms, see Vendor diligence FAQ. Detailed narratives and evidence exports are available on Security and governance and under NDA from Fontana.
Control matrix
Section titled “Control matrix”| Topic | Approach | Deep dive |
|---|---|---|
| Authentication | Self-hosted Zitadel per workspace: OIDC, SSO federation, MFA (TOTP + WebAuthn) | Identity providers |
| Provisioning | Inbound SCIM v2 through workspace Zitadel; role assignment via Zitadel project roles | Identity providers, Roles and RBAC |
| Authorization | Application RBAC in Convex with team scoping and permission registry | Roles and RBAC |
| Service authentication | Dedicated OAuth clients for workflow-engine and observability-api; RFC 7662 token introspection | Network and hardening |
| Secrets | Per-workspace in-cluster Vault (KV fontana); BYOK for AI; connector secrets via Vault at runtime | Secrets and encryption |
| Encryption in transit | TLS at public edge; documented transmission boundary; in-cluster HTTP with NetworkPolicy compensating controls | Network and hardening |
| Encryption at rest | Encrypted data volume backing all workspace PVCs | Secrets and encryption |
| Workspace isolation | Cluster-per-tenant control plane, data, secrets, and identity | Workspace isolation |
| Network | Host security group: 80 + 443 only (shell via SSM Session Manager); k8s API localhost-only; NetworkPolicy default-deny | Network and hardening |
| Cloud account perimeter | Organization CloudTrail, AWS Config rules, GuardDuty + Security Hub with findings routing, SSO-only operator identity | Network and hardening |
| Pod and workload hardening | Per-workload ServiceAccounts; Pod Security baseline; limits; Vault Agent sidecars | Network and hardening |
| Audit (identity and cluster) | WORM ImmuDB: Zitadel identity events and Kubernetes API audit (automated ingest) | Immutable audit trail |
| Security alerting | Bundled HyperDX alert rules on Kubernetes audit events (auth failures, secret access, destructive verbs, ClusterRoleBinding changes) with WORM evidence per alert | Operational telemetry |
| Audit (application admin) | WORM via Convex audit_log log stream (ingest shipped; mutation producers rolling out by release) | Immutable audit trail |
| Audit (workflow, WORM target) | Privileged runs and security-tagged connector access → Convex audit_log (target path) | Immutable audit trail |
| Audit (workflow lineage) | Lineage sidecars and port audit items on workflow file store only; answers calculation provenance, not platform WORM | Data lineage, Compliance evidence |
| Operational telemetry | HyperDX search and dashboards; mirror only for audit events; ImmuDB is WORM system of record; collector-side redaction of credentials in log bodies | Operational telemetry, Data retention |
| Backup and recovery | Automatic snapshot before tenant upgrade; fontana rollback; daily volume snapshots on managed cloud; Vault Raft for secrets DR | Backup and restore |
| Supply chain | Immutable GHCR sha-<git> tags, bundle SHA256SUMS, Trivy CRITICAL gate, dependency audit + CodeQL gates in CI | Supply chain |
| Change control | Release artifacts built from the protected release branch only; manual pinned releases; Terraform for host provisioning; SSM read/debug only on prod | Supply chain, Fontana CLI |
| Availability monitoring | In-cluster Gatus probes for platform and tenant services; status page behind HTTP basic auth with Vault-stored credentials | Operational telemetry |
| AI governance | BYOK, approved gateways/models, ZDR where supported, tool-call audit | BYOK, Zero Data Retention |
| Data retention | Separate retention for workflow file store, HyperDX operational logs, and ImmuDB WORM ledger | Data retention |
| Deployment environments | Production-class hosts in SOC 2 scope; integration/local for engineering only | Deployment environments |
| Operator access | Narrow host perimeter; localhost-bound cluster API; CLI-driven durable changes; Kubernetes operator roles versioned in git and applied at bootstrap; authenticated operator dashboards (Gatus, HyperDX, Convex) | Network and hardening |
| Secret rotation | Vault-backed rotation for BYOK, connectors, SCIM tokens, and service credentials | Secrets and encryption |
Trust Service Criteria mapping (high level)
Section titled “Trust Service Criteria mapping (high level)”Auditors often map evidence to AICPA Trust Service Criteria. Fontana’s deployment model supports review across common areas:
| TSC area | How Fontana addresses it |
|---|---|
| Security (CC) | Identity, RBAC, network segmentation, secrets, vulnerability scanning |
| Availability (A) | Gatus health checks, snapshots, rollback, durable PVCs |
| Processing integrity (PI) | Deterministic workflow execution, lineage, validation audit items |
| Confidentiality (C) | Tenant isolation, encryption, write-only secrets, BYOK |
| Privacy (P) | Customer-controlled retention and egress; separate workflow, HyperDX, and WORM stores. See Data retention. |
Your auditor may require operating effectiveness testing on your deployment instance, not only design documentation.
Audit operating status
Section titled “Audit operating status”The control matrix uses separate rows because not every audit path is at the same maturity. Questionnaires often ask whether controls operate in production, not only whether the architecture supports them.
| Evidence type | WORM ledger? | Status |
|---|---|---|
| Zitadel identity (sign-in, MFA, role changes, SCIM lifecycle) | Yes | Automated - observability-api polls Zitadel Events API |
| Kubernetes API (auth failures, secret access, destructive verbs) | Yes | Automated - cluster audit log → audit-ingest |
| Convex admin mutations (RBAC, BYOK, team membership, deployment settings) | Yes | Ingest shipped; individual mutation producers roll out by release |
| Workflow engine (privileged runs, sensitive connector access) | Target | Target path - engine → Convex audit_log (not direct ImmuDB) |
| Workflow lineage and port audit items | No (workflow file store) | Not WORM - .lineage.json / .audit.json sidecars and canvas port audit items; calculation provenance only |
| HyperDX (including audit mirror) | No (search plane) | Not system of record - operational search and shorter TTL; ImmuDB holds compliance evidence |
| Audit logs → Chat (LLM debug in Flow) | No | Product feature; RBAC-gated, not compliance ledger |
Full producer map: Immutable audit trail.
Environment scope
Section titled “Environment scope”SOC 2 evidence collection targets production-class hosts only. Integration and local developer environments are out of scope for regulated customer data and formal change control.
See Deployment environments for environment classes, what production-class means, and why integration/local boxes must not host regulated tenants.
Requesting evidence
Section titled “Requesting evidence”For architecture diagrams, subprocessors, DPA terms, penetration test summaries, and exported control snapshots, use Security and governance or contact Fontana for the diligence pack under NDA.
Fontana maintains a structured auditor evidence index that maps each control row above to dated artifacts: control snapshots (fontana soc2 snapshot), committed operator RBAC manifests, Kubernetes audit dashboards and alert history, WORM integrity-scan records, and backup drill results. Auditors receive this index with the diligence pack.
Related documentation
Section titled “Related documentation”- Vendor diligence FAQ - recurring procurement and audit Q&A
- Security overview - topics index and three evidence planes
- Compliance evidence - workflow lineage and immutable audit trail narrative
- Deployment - where Fontana runs and upgrade mechanics