> ## Documentation Index
> Fetch the complete documentation index at: https://docs.emergence.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# SOC 2 Controls
> SOC 2 Trust Service Criteria mapping for CRAFT, covering security, availability, processing integrity, confidentiality, and privacy.
# SOC 2 Controls Mapping
This page maps CRAFT's security controls to the **SOC 2 Trust Service Criteria (TSC) 2017** (revised 2022) defined by the AICPA. CRAFT is the core platform powering the Emergence product suite. The mapping covers all five trust service categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
This mapping documents the platform's built-in controls. Organizations pursuing SOC 2 Type II certification must also implement organizational controls (policies, procedures, training) and engage a qualified auditor.
## Security (Common Criteria)
Security controls form the foundation of all SOC 2 categories.
### CC6: Logical and Physical Access Controls
| Criteria | Control | Platform Implementation |
| -------- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| CC6.1 | Logical access security | Keycloak multi-realm JWT authentication with OIDC/PKCE |
| CC6.2 | User registration and authorization | OpenFGA ReBAC with role-based permissions (owner, admin, member, developer, operator, viewer) |
| CC6.3 | Access removal | Keycloak user deactivation + OpenFGA relation cleanup; SCIM 2.0 deprovisioning from IdP |
| CC6.6 | Boundary protection | Kubernetes NetworkPolicies, ingress TLS termination, SSRF protection |
| CC6.7 | Data transmission protection | TLS 1.3 for external traffic, TLS 1.2 minimum for internal (due to managed service compatibility -- Cloud SQL, Redis, Keycloak). mTLS available via service mesh (Istio, Linkerd) |
| CC6.8 | Unauthorized software prevention | Container-based deployment, immutable images, no SSH access to pods |
### CC7: System Operations
| Criteria | Control | Platform Implementation |
| -------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| CC7.1 | Detection of vulnerabilities | Container image scanning in CI/CD, dependency pinning with `==` |
| CC7.2 | Anomaly detection | OpenTelemetry traces/metrics/logs with Grafana LGTM alerting |
| CC7.3 | Security incident evaluation | Immutable audit logs with SIEM integration via OpenTelemetry Collector (customer-configurable exporters) |
| CC7.4 | Incident response | Audit trail with trace\_id correlation for investigation; configurable alerting thresholds for detection. Organizations must maintain a documented IR plan with roles and escalation paths |
### CC8: Change Management
| Criteria | Control | Platform Implementation |
| -------- | ------------------------ | ---------------------------------------------------------------------- |
| CC8.1 | Change authorization | GitHub PR reviews, changeset-based versioning, CI/CD gates |
| CC8.2 | Infrastructure changes | Terraform IaC with plan/apply workflow, ArgoCD GitOps |
| CC8.3 | Configuration management | Helm values files, immutable Alembic migrations, version-driven builds |
## Availability
| Criteria | Control | Platform Implementation |
| -------- | ------------------------- | ----------------------------------------------------------------------------------- |
| A1.1 | Processing capacity | Kubernetes autoscaling (GKE Autopilot, HPA), Redis connection pooling |
| A1.2 | Recovery from disruptions | Multi-database backup strategy, point-in-time recovery, disaster recovery checklist |
| A1.3 | Environmental protections | Cloud provider infrastructure (GKE, EKS, AKS) with multi-zone availability |
### Backup and Recovery Controls
| Control | Implementation |
| ---------------------- | ----------------------------------------------------------------------------------------------- |
| Automated backups | Cloud-managed daily backups with configurable retention (30 days default) |
| Point-in-time recovery | WAL archiving for PostgreSQL PITR |
| Backup testing | Regular restore validation as part of DR procedures (frequency defined in organization DR plan) |
| Startup order | Documented service dependency DAG for orderly recovery |
## Processing Integrity
| Criteria | Control | Platform Implementation |
| -------- | --------------------- | ---------------------------------------------------------------------------- |
| PI1.1 | Processing accuracy | SQLAlchemy ORM with strict typing, Pydantic request/response validation |
| PI1.2 | Input validation | FastAPI automatic request validation, search query injection prevention |
| PI1.3 | Processing monitoring | Prefect workflow orchestration with status tracking, health check monitoring |
| PI1.4 | Output completeness | Auto-generated SDKs ensure API contract compliance, E2E test coverage |
### Data Integrity Controls
| Control | Implementation |
| -------------------- | -------------------------------------------------------------------------------------- |
| Schema enforcement | SQLAlchemy 2.0+ with strict type annotations, Alembic migration validation |
| API contract testing | Auto-generated Python/TypeScript SDKs from OpenAPI specs, E2E tests via generated SDKs |
| Query safety | `plainto_tsquery()` for user input, parameterized queries, no string interpolation |
| Webhook integrity | HMAC-SHA256 signed payloads with unique delivery IDs (planned -- not yet released) |
## Confidentiality
| Criteria | Control | Platform Implementation |
| -------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C1.1 | Confidential information identification | Four-level data classification (Public, Internal, Confidential, Restricted). Query result sensitivity inherits from the underlying data source; organizations must classify their data connections appropriately |
| C1.2 | Confidential information disposal | Crypto-shredding for RTBF, configurable retention policies, backup rotation |
Query result sensitivity inherits from the underlying data source. Healthcare data may be Restricted, while business analytics may be Confidential. Organizations must classify their data connections appropriately. See [Data Classification](/security/data-classification) for the full taxonomy.
### Encryption Controls
| Control | Implementation |
| --------------------- | -------------------------------------------------------------------------------------------- |
| Encryption at rest | AES-256 via cloud-managed encryption, CMEK support |
| Encryption in transit | TLS 1.3 (external), TLS 1.2 minimum (internal). mTLS available via service mesh |
| Key management | Cloud KMS or provider-managed keys, per-principal keys for audit PII |
| Secrets management | Platform Secrets API (Infisical or ESO + GCP Secret Manager), never stored in code or config |
## Privacy
| Criteria | Control | Platform Implementation |
| -------- | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| P1.1 | Privacy notice | Data processing purposes documented per data connection |
| P2.1 | Choice and consent | Configurable per-tenant data processing settings |
| P3.1 | Personal information collection | Minimal PII collection (email, IP for audit); data minimization applied |
| P4.1 | Use, retention, and disposal | Configurable retention per data type, automated cleanup |
| P5.1 | Access to personal information | Audit log export, data portability APIs (JSON/CSV) |
| P6.1 | Disclosure to third parties | No user data shared by default. LLM-powered features (when enabled) send user queries and schema context to the configured LLM provider; DPA/BAA required. Cloud provider DPAs for managed services. Self-hosted LLM option eliminates third-party data transfer |
| P7.1 | Quality of personal information | User profile sync via SCIM, Keycloak-managed identity |
| P8.1 | Complaints handling | Admin audit trail for RTBF request tracking |
## Access Review Controls
The platform supports periodic access reviews for SOC 2 compliance:
Administrators can review all RBAC grants per tenant using the Governance API. The review includes role assignments, last login timestamps, and permission inheritance paths.
Automated detection of agent registrations whose publisher account has been deactivated. Orphaned resources are flagged for review or ownership transfer.
Entities with no updates and consecutive failing health checks for a configurable number of days are flagged for review. Stale entities may indicate abandoned resources or decommissioned services.
When users are deactivated in the enterprise IdP, SCIM 2.0 sync automatically removes their Keycloak realm access and cleans up OpenFGA relations.
## Evidence Collection
For SOC 2 audit evidence, the platform provides:
| Evidence | Source | Export Format |
| ------------------- | -------------------------------- | ----------------- |
| Access logs | Audit log API | JSON, CSV |
| Change history | Git commits, ArgoCD sync history | Git log, API |
| Configuration state | Helm values, Terraform state | YAML, JSON |
| Vulnerability scans | CI/CD pipeline artifacts | SARIF, JSON |
| Backup verification | Cloud provider backup logs | Provider-specific |
| Incident records | Alert history, trace correlation | JSON |
## Next Steps
Learn about GDPR-specific controls and Right to Be Forgotten.
Review HIPAA compliance considerations for healthcare deployments.
Deep dive into the authentication architecture.
Review data classification levels and encryption standards.