# Compliance Matrix ## Purpose & Audience This document maps compliance standards to specific implementation controls, evidence locations, and known gaps in the platform service. It is intended for auditors, compliance officers, and engineers preparing for compliance engagements. For the security architecture, see [security.md](security.md). For operational procedures, see the [platform runbooks](../operations/runbooks/). **Last reviewed:** 2026-04-10 **Phase:** 1 (Core Authorization) **Scope:** Platform service (`apps/platform`), main server (`apps/server`), database (`packages/db`) --- ## How to Read This Document Each standard below is broken into specific controls. Each control has: - **Control ID** — the standard's own identifier - **Requirement** — what the standard requires - **Implementation** — what the platform does to satisfy it - **Evidence** — code paths, test files, or config that demonstrate the control - **Phase** — when the implementation ships (1 = current, 2/3 = planned) - **Status** — Implemented, Partial, Planned, or N/A Controls marked **Partial** have known gaps documented in the Notes column. Controls marked **Planned** have no implementation yet but have data models designed. --- ## SOC 2 Type II (Trust Service Criteria) ### CC6 — Logical and Physical Access Controls | Control | Requirement | Implementation | Evidence | Phase | Status | Notes | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----- | ----------- | ---------------------------------------------------------------------------------------------------------- | | CC6.1 | Logical access security software, infrastructure, and architectures | 16-step RBAC+ABAC permission pipeline with fail-closed enforcement. Every API request checks permissions before proceeding. | `apps/platform/src/domains/access/service/permission-resolver.ts`, `inv-fail-closed.test.ts` (7 tests), `inv-deny-wins.test.ts` (4 tests) | 1 | Implemented | | | CC6.2 | Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users | User provisioning via `TenantUser` creation with `invited` → `active` lifecycle. Role assignment with SoD validation. | `TenantUser` model (`schema.prisma:569`), `sod-validator.ts`, `sod-validator.test.ts` | 1 | Partial | SCIM automated provisioning is Phase 2. Manual provisioning only in Phase 1. | | CC6.3 | The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets | Role assignment/revocation via `UserRole`. Direct overrides via `UserPermission` with expiry. Deny overrides for emergency revocation. | `UserRole` model (`schema.prisma:775`), `UserPermission` model (`schema.prisma:797`), `permission-resolver.ts` steps 8-11 | 1 | Implemented | | | CC6.5 | The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished | Audit log crypto-shredding — deleting `AuditEncryptionKey` renders PII unreadable while preserving structural data. | `AuditEncryptionKey` model (`schema.prisma:968`), crypto-shredding write/erasure paths in `security.md:99-131` | 1 | Implemented | | | CC6.6 | Logical access security measures protect against threats from sources outside its system boundaries | Auth0 JWT validation with JWKS endpoint verification. Rate limiting (100 req/min API, 10 req/min streaming). CSP with per-request nonces. HSTS enforcement. | `apps/server/src/middleware/auth.ts`, `rate-limit.ts`, `security-headers.ts` | 1 | Implemented | | | CC6.7 | The entity restricts the transmission, movement, and removal of information to authorized internal and external users | TLS 1.2+ for all connections. AES-256-GCM encryption for identity data, OAuth tokens, and audit PII. No plaintext PII in Redis audit buffer. | `packages/db/src/crypto.ts`, `security.md:222-230` (encryption table) | 1 | Partial | Conversation cache keys contain raw `identityId` (not HMAC-hashed). See data-processing.md §9 for details. | | CC6.8 | The entity implements controls to prevent or detect and act on the introduction of unauthorized or malicious software | SAST scanning in CI pipeline. pnpm overrides for 18 known CVEs. Datadog AppSec native addons. | `Jenkinsfile` SAST stage, `package.json` overrides section, Dockerfile `@datadog/native-appsec` | 1 | Partial | No container image scanning (Trivy/Snyk). No SBOM generation. | ### CC7 — System Operations | Control | Requirement | Implementation | Evidence | Phase | Status | Notes | | ------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ----- | ------- | ------------------------------------------------------------------------------------------------------------------------------------- | | CC7.1 | Detection of unauthorized changes to configurations and new vulnerabilities | Audit logging on every permission check (grant and denial). `PermissionChangeLog` tracks all role/permission modifications. | `AuditLog` model (`schema.prisma:996`), `PermissionChangeLog` model (`schema.prisma:1040`) | 1 | Partial | No automated anomaly detection on audit events (e.g., spike in denials). | | CC7.2 | The entity monitors system components for anomalies | Sentry error tracking, Datadog APM with AppSec, structured logging. | `apps/server/src/instrument.ts`, `dd-trace` initialization in Dockerfile | 1 | Partial | No documented alerting rules for security-specific anomalies. | | CC7.3 | The entity evaluates, develops, and implements responses to identified vulnerabilities | pnpm overrides patch known CVEs. Pre-push hooks run audit + lint + typecheck + tests. | `package.json` overrides, `.husky/pre-push` | 1 | Partial | No formal incident response playbook. See [platform incident response runbook](../operations/runbooks/platform-incident-response.md). | | CC7.4 | The entity responds to identified security incidents | Kill switch for permission enforcement (shadow mode revert in <30s). Tenant-scoped suspension. | `migration-cutover.md:97-99`, `TenantStatus` enum | 1 | Partial | Needs incident response playbook with escalation procedures. | ### CC8 — Change Management | Control | Requirement | Implementation | Evidence | Phase | Status | Notes | | ------- | -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | ----- | ----------- | ------------------------------------------------------------ | | CC8.1 | The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes | Git branching workflow with PR reviews. Pre-push hooks enforce lint + typecheck + tests. Jenkins CI pipeline with SAST. | `CONTRIBUTING.md`, `Jenkinsfile`, `.husky/pre-push` | 1 | Implemented | No formal CAB process — PR review serves as change approval. | ### A1 — Availability | Control | Requirement | Implementation | Evidence | Phase | Status | Notes | | ------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ----- | ------- | ------------------------------------------------------------ | | A1.2 | Environmental protections, software, data backup processes, and recovery infrastructure | Aurora MySQL with automated backups. Redis with TLS for remote connections. Docker healthchecks. Blue/green deployment with canary. | `infrastructure.md`, Dockerfile HEALTHCHECK, `docker-compose.yml` healthcheck configs | 1 | Partial | No documented RTO/RPO targets. No disaster recovery runbook. | --- ## SOX (Sarbanes-Oxley) SOX compliance applies to the extent that the platform handles financial data (royalties). These controls map to COSO Internal Control Framework components relevant to IT general controls (ITGCs). | Control Area | Requirement | Implementation | Evidence | Phase | Status | Notes | | ------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | ----- | ----------- | ------------------------------------------------------------------------------------------------------------------------- | | **Segregation of Duties** | Conflicting duties are separated to prevent unauthorized transactions | `RoleExclusion` model with bidirectional SoD constraints. `SodValidator` checks at role assignment time. | `RoleExclusion` model (`schema.prisma:729`), `sod-validator.ts`, `sod-validator.test.ts` | 1 | Partial | Transitive SoD via role inheritance NOT checked (Phase 2). Doc comment in `sod-validator.ts:12` incorrectly claims it is. | | **Access Controls** | Access to financial systems and data is restricted to authorized personnel | 16-step permission pipeline. Fail-closed on errors. Deny-wins over all users including super admins. | `permission-resolver.ts`, `inv-fail-closed.test.ts`, `inv-deny-wins.test.ts` | 1 | Implemented | | | **Audit Trail** | All changes to financial data are logged with who/what/when | `AuditLog` (append-only, no `updatedAt`) with `onDelete: Restrict`. `PermissionChangeLog` tracks permission/role changes. `revokeSuperAdmin` persists `revokedBy`. | `AuditLog` model (`schema.prisma:996`), `PermissionChangeLog` model (`schema.prisma:1040`), `identity.ts:334-337` | 1 | Implemented | | | **Change Authorization** | Changes require appropriate authorization before implementation | `PermissionChangeLog` records `changedBy` for all modifications. `UserRole.grantedBy` and `UserPermission.grantedBy` track attribution. | `PermissionChangeLog.changedBy`, `UserRole.grantedBy` (`schema.prisma:785`) | 1 | Partial | No maker-checker (dual approval) for sensitive operations. Single-actor changes are logged but not gated. | | **Immutable Records** | Financial records cannot be altered or deleted | Audit log uses `onDelete: Restrict` — cannot be deleted even if tenant is deleted. No `updatedAt` field. Redis buffer never contains plaintext PII. | `schema.prisma:1028` (`onDelete: Restrict`), no `updatedAt` on AuditLog | 1 | Implemented | | **SOX Gap Summary:** Maker-checker workflows and transitive SoD are the primary gaps. Phase 2 should add approval workflows for: role creation/deletion, permission changes, super admin grants, and tenant configuration changes. --- ## GDPR (General Data Protection Regulation) | Article | Requirement | Implementation | Evidence | Phase | Status | Notes | | ---------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----- | ----------- | --------------------------------------------------------------------------------------------------------------------- | | **Art. 5(1)(a)** | Lawfulness, fairness, transparency | Consent tracking via `ConsentRecord` model. | `ConsentRecord` model designed in data model spec | 2C | Planned | No lawful basis recording in Phase 1. | | **Art. 5(1)(b)** | Purpose limitation | Data used only for stated purposes (royalties platform). Audit logs used only for security/compliance. | Architectural separation of concerns | 1 | Implemented | No formal purpose registry. | | **Art. 5(1)(c)** | Data minimization | Identity stored as HMAC hash + encrypted copy. Raw ID never stored in plaintext. Only necessary PII collected. | `packages/db/src/crypto.ts` (`hashIdentity`, `encryptIdentity`), `User` model (`schema.prisma:20-57`) | 1 | Implemented | | | **Art. 5(1)(e)** | Storage limitation | Soft deletion for chats. Crypto-shredding for audit PII. | `Chat.deleted_at`, `AuditEncryptionKey` model | 1 | Partial | No automated retention enforcement. No per-table TTL policies. See [data-retention.md](data-retention.md). | | **Art. 5(1)(f)** | Integrity and confidentiality | AES-256-GCM encryption. TLS 1.2+. Rate limiting. CSP. HSTS. | `crypto.ts`, `security-headers.ts`, `rate-limit.ts`, `auth.ts` | 1 | Implemented | | | **Art. 6** | Lawful basis for processing | `ConsentRecord` model with `legalBasis` enum (consent, contract, legal_obligation, vital_interest, public_interest, legitimate_interest). | Data model spec (Phase 2C) | 2C | Planned | **Not implemented in Phase 1.** | | **Art. 7** | Conditions for consent | `ConsentRecord` with `consentedAt`, `withdrawnAt`, `purpose`. Opt-in model for non-contractual processing. | Data model spec (Phase 2C) | 2C | Planned | | | **Art. 13/14** | Information to data subjects | N/A — responsibility of the frontend/legal team. Platform provides data for privacy notices. | — | — | N/A | Platform should expose an API for privacy notice data (Phase 2C). | | **Art. 15** | Right of access (data export) | `PrivacyRequest` model with `type: export`. Exports all user data in structured format. | Data model spec (Phase 2C) | 2C | Planned | **Not implemented in Phase 1.** | | **Art. 17** | Right to erasure | Crypto-shredding: delete `AuditEncryptionKey` → all audit PII unreadable. User record deletion cascades through `TenantUser`, `UserRole`, `UserPermission`. | `AuditEncryptionKey` model (`schema.prisma:968`), `security.md:93-131`, cascade delete rules in schema | 1 | Implemented | Strongest GDPR control in Phase 1. Verified by `inv-audit-crypto-shred` invariant test. | | **Art. 20** | Right to data portability | `PrivacyRequest` model with `type: portability`. | Data model spec (Phase 2C) | 2C | Planned | | | **Art. 25** | Data protection by design and by default | Per-user encryption keys (envelope encryption via KMS). PII never stored in plaintext in Redis. Permission pipeline defaults to DENIED. | `security.md` design principles, `AuditEncryptionKey` model, `permission-resolver.ts` fail-closed outer catch | 1 | Implemented | | | **Art. 28** | Processor obligations | N/A — Coda is the processor. AWS is a sub-processor (covered by AWS DPA). | AWS compliance documentation | — | N/A | Tenant-facing DPA is Phase 2C (`ConsentRecord` + `ExternalReference`). | | **Art. 30** | Records of processing activities | See [data-processing.md](data-processing.md). | Separate document | 1 | Partial | Document exists but automated ROPA generation is Phase 2. | | **Art. 32** | Security of processing | AES-256-GCM, HMAC-SHA256, TLS, access controls, audit logging, fail-closed enforcement. | All middleware and crypto files listed in `security.md` | 1 | Implemented | | | **Art. 33** | Notification of data breach to supervisory authority | No automated breach detection or 72-hour notification workflow. | — | 2C | Planned | See [platform incident response runbook](../operations/runbooks/platform-incident-response.md) for manual procedures. | | **Art. 34** | Communication of data breach to data subjects | No automated breach notification to affected users. | — | 2C | Planned | | | **Art. 35** | Data Protection Impact Assessment | No DPIA template or tooling. | — | 2C | Planned | DPIA should be conducted before enabling consent tracking. | | **Art. 3(2)** | Territorial scope | `Tenant.primaryJurisdiction` (ISO country code). `TenantUser.userJurisdiction` overrides per user. `Tenant.dataResidency` (AWS region). | `Tenant` model (`schema.prisma:530-532`), `TenantUser` model (`schema.prisma:581`) | 1 | Partial | Jurisdiction data is modeled. `JurisdictionConfig` enforcement is Phase 2C. | **GDPR Gap Summary:** Art. 17 (erasure) is production-ready via crypto-shredding. Art. 25 and 32 (security by design) are strong. Art. 6 (lawful basis), Art. 15 (data export), and Art. 33/34 (breach notification) are Phase 2C. **Do not claim GDPR compliance until Phase 2C is complete.** --- ## CCPA/CPRA (California Consumer Privacy Act) | Section | Right | Implementation | Evidence | Phase | Status | Notes | | --------- | ------------------------------------------ | ------------------------------------------------------------- | -------------------------------------------- | ----- | ------- | -------------------------------------------------------------------------------------------------- | | §1798.100 | Right to know (categories of PI collected) | `PrivacyRequest` model with `type: export`. | Data model spec (Phase 2C) | 2C | Planned | | | §1798.105 | Right to delete | Crypto-shredding for audit PII. User record cascade deletion. | `AuditEncryptionKey` deletion, cascade rules | 1 | Partial | Full data deletion (chats, OAuth, data sources) needs verification that cascade covers all tables. | | §1798.106 | Right to correct | No correction mechanism. | — | 2C | Planned | | | §1798.110 | Right to know (specific pieces of PI) | `PrivacyRequest` model with structured export. | Data model spec (Phase 2C) | 2C | Planned | | | §1798.115 | Right to know (sale/sharing) | N/A — platform does not sell or share personal information. | — | — | N/A | | | §1798.120 | Right to opt-out of sale/sharing | N/A — no sale or sharing. | — | — | N/A | | | §1798.121 | Right to limit use of sensitive PI | `ConsentRecord` model with purpose-specific consent. | Data model spec (Phase 2C) | 2C | Planned | | | §1798.125 | Non-discrimination | N/A — business process, not technical control. | — | — | N/A | | | §1798.130 | 45-day response SLA | `PrivacyRequest.deadline` field with SLA tracking. | Data model spec (Phase 2C) | 2C | Planned | | **CCPA Gap Summary:** The right to delete is partially implemented via crypto-shredding. All other rights require Phase 2C `PrivacyRequest` infrastructure. **Do not claim CCPA compliance until Phase 2C is complete.** --- ## NIST RBAC (INCITS 359-2004) | Level | Component | Requirement | Implementation | Evidence | Phase | Status | | ----- | ----------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ----- | ----------- | -------------------------------------------------------------------------------------- | | 1 | Core RBAC | Users, roles, permissions, user-role assignment, user-session association | `User`, `Role`, `Permission`, `UserRole` models. Permission resolver steps 10-11. | `schema.prisma:665-793`, `permission-resolver.ts` | 1 | Implemented | | 1 | Core RBAC | Role-permission assignment | `RolePermission` join table. | `schema.prisma:698-709` | 1 | Implemented | | 1 | Core RBAC | Permission activation within sessions | Session model with `tokenHash`, `expiresAt`, `revokedAt`. Permissions resolved per-request. | `Session` model (`schema.prisma:881`) | 1 | Implemented | | 2 | Hierarchical RBAC | Role hierarchy (general/limited) | `RoleInheritance` with BFS traversal. Cycle detection prevents infinite loops. | `RoleInheritance` model (`schema.prisma:713`), `role-hierarchy.ts`, `inv-role-cycle.test.ts` | 1 | Implemented | | 2 | Static SoD | Mutually exclusive roles | `RoleExclusion` model. `SodValidator` checks at assignment time. Bidirectional enforcement. | `RoleExclusion` model (`schema.prisma:729`), `sod-validator.ts`, `sod-validator.test.ts` | 1 | Partial | Transitive SoD (conflicts inherited through role hierarchy) not checked until Phase 2. | | 3 | Dynamic SoD | Session-level mutual exclusion | Not claimed. | — | — | N/A | Would require session-aware permission activation tracking. | **NIST RBAC Summary:** The platform implements INCITS 359 Level 2 (Core + Hierarchical + Static SoD) with one documented gap (transitive SoD). This is the strongest compliance claim the platform can make in Phase 1. --- ## OWASP Top 10 (2021) | Risk | Mitigation | Evidence | Status | Notes | | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **A01** Broken Access Control | 16-step pipeline, fail-closed, deny-wins, tenant isolation (composite keys, cache namespacing). Every API route protected. | `permission-resolver.ts`, 5 invariant test suites, `security.md` | Mitigated | Core strength of the platform. | | **A02** Cryptographic Failures | AES-256-GCM with random IVs. HMAC-SHA256 for hashing. No hardcoded secrets. Zod validation of key material at startup. `AUDIT_MASTER_KEY` validated as 64-char hex. | `crypto.ts`, `load-config.ts:48-54`, `apps/platform/src/server.ts:128-136` | Mitigated | Master key properly implemented as env var with Zod regex validation (`/^[0-9a-f]{64}$/i`). Random fallback in dev logs a warning. | | **A03** Injection | Prisma ORM (parameterized queries). Snowflake read-only wrapper with keyword allowlist + comment rejection + multi-statement block. Permission name regex validation. | `packages/db` (Prisma), Snowflake `SecureConnection` wrapper, `permission-resolver.ts` regex | Mitigated | | | **A04** Insecure Design | Invariant tests for security constraints. Fail-closed principle. Sandbox 5-tier defense model with threat model. | `inv-*.test.ts`, `docs/sandbox/security.md` | Partial | No formal threat model for the platform service itself. See [threat-model.md](threat-model.md). | | **A05** Security Misconfiguration | CSP with per-request nonces. HSTS (2-year max-age). Frame-ancestors 'none'. X-Content-Type-Options nosniff. | `security-headers.ts` | Mitigated | `style-src 'unsafe-inline'` required for React — documented trade-off. | | **A06** Vulnerable and Outdated Components | 18 pnpm overrides for known CVEs. Pre-push audit check. SAST in CI. | `package.json` overrides, `Jenkinsfile` SAST stage | Partial | No container image scanning. No automated dependency update workflow. | | **A07** Identification and Authentication Failures | Auth0 JWKS validation. SHA-256 hashed session tokens. API keys shown once, only hash stored. Rate limiting on all endpoints. | `auth.ts`, `Session.tokenHash`, `rate-limit.ts` | Mitigated | Rate limit relies on `trust proxy` configuration for IP accuracy. | | **A08** Software and Data Integrity Failures | Signed JWTs (Auth0 RS256). `pnpm install --frozen-lockfile` in CI. Append-only audit logs with `onDelete: Restrict`. | `Jenkinsfile`, `AuditLog` model | Partial | No SBOM. No artifact signing (sigstore). No supply chain verification beyond lockfile. | | **A09** Security Logging and Monitoring Failures | Structured logging (pino). Sentry with PII filtering. Audit trail on every permission check. | `instrument.ts`, `AuditLog`, pino setup | Partial | Audit drainer failure could silently drop events. No alerting on repeated denials. | | **A10** Server-Side Request Forgery (SSRF) | Snowflake read-only with keyword allowlist. No user-controlled URL fetching in platform service. | Snowflake `SecureConnection` wrapper | Mitigated | Webhook delivery (Phase 3) will need SSRF protection (URL allowlisting, private IP rejection). | --- ## Phase Readiness Summary | Standard | Phase 1 Readiness | Can Claim? | Blocking Gaps | | --------------------- | ----------------- | -------------------------------- | ------------------------------------------------------------------------------------------ | | **NIST RBAC Level 2** | ~85% | Yes (with transitive SoD caveat) | Transitive SoD only | | **OWASP Top 10** | ~80% | Yes (with known gaps documented) | Threat model (now exists), image scanning, integration route hardening | | **SOC 2 Type II** | ~75% | No | Anomaly alerting, key rotation procedure, automated deprovisioning, conversation cache PII | | **SOX** | ~60% | No | Maker-checker workflows, transitive SoD | | **GDPR** | ~40% | No | Consent, export, lawful basis, retention policy, breach notification | | **CCPA/CPRA** | ~25% | No | Privacy requests, correction, 45-day SLA tracking | --- ## Maintaining This Document - **Review cadence:** Update after each phase ships and before any compliance engagement. - **Evidence verification:** Before an audit, verify all listed test files still exist and pass by running `pnpm test`. - **Gap tracking:** When a Planned control is implemented, update its status and add evidence references. - **Owner:** Platform team lead.