# 02 Control matrix: every control, mapped to the Trust Services Criteria

These are the controls the auditor will test. Each has an ID, the criteria it addresses (TSC 2017, revised points of focus 2022), an owner role from [00](/soc2/#owners), a frequency, the evidence it leaves behind, and the policy it rests on. Control status is tracked in the internal gap assessment, not here.

Rules for this table:

- **One control, one artifact.** If the evidence column cannot name a file, a log, a ticket or a signed record, the control is not testable.
- **Frequency is a promise.** A Type II auditor samples across the period. A monthly control missed in one month is an exception in the report.
- **Change a control here first**, then the policy, then the tooling. Never let them disagree.

Owner abbreviations: **SO** Security Owner, **IO** Infrastructure Owner, **CA** Change Approver, **PO** People Owner, **VO** Vendor Owner, **IL** Incident Lead.

## CC1 Control environment

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| GOV-01 | The information security policy set is approved by the director(s) and published to all personnel | CC1.1, CC1.2, CC2.2, CC5.3 | SO | Annual | Signed approval page with version and date | [10](/soc2/10-information-security) |
| GOV-02 | Security roles and owners are named and documented | CC1.3, CC1.4 | SO | Annual, and on change | Owners table in [00](/soc2/#owners), dated | [10](/soc2/10-information-security) |
| GOV-03 | Directors review the security program: risks, incidents, control exceptions, roadmap | CC1.2, CC4.2 | SO | Quarterly | Meeting minutes with attendees and decisions | [10](/soc2/10-information-security) |
| GOV-04 | Personnel acknowledge the code of conduct and acceptable use policy | CC1.1, CC1.5 | PO | At hire, then annual | Signed or clicked acknowledgement with date | [11](/soc2/11-conduct-acceptable-use) |
| GOV-05 | Personnel and contractors sign confidentiality agreements before access | CC1.1, C1.1 | PO | At hire | Signed NDA or contract clause | [12](/soc2/12-people-security) |
| GOV-06 | Background verification is performed for personnel with production access, as permitted by local law | CC1.4 | PO | At hire | Verification record (kept outside the evidence store) | [12](/soc2/12-people-security) |
| GOV-07 | Job responsibilities for security-relevant roles are written down | CC1.3, CC1.4 | PO | At hire, on change | Role description | [12](/soc2/12-people-security) |
| GOV-08 | Personnel complete security awareness training, including phishing and data handling | CC1.4, CC2.2 | PO | At hire, then annual | Completion record per person | [12](/soc2/12-people-security) |
| GOV-09 | Personnel performance includes adherence to security responsibilities; policy violations follow a disciplinary process | CC1.5 | PO | As needed | Process documented; case records if any | [11](/soc2/11-conduct-acceptable-use) |

## CC2 Communication and information

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| COM-01 | A system description and architecture diagram for the in-scope system is maintained | CC2.1, CC2.3 | SO | Annual, and on major change | [06 System description](/soc2/06-system-description), dated | [10](/soc2/10-information-security) |
| COM-02 | Policies are published internally; changes are announced to personnel | CC2.2 | SO | On change | Change log and announcement | [10](/soc2/10-information-security) |
| COM-03 | Customers can report security issues and incidents through a published channel (security.txt and a security page) | CC2.3 | SO | Continuous | Live security.txt and page; test message log | [20](/soc2/20-incident-response) |
| COM-04 | Customer commitments (terms, DPA, SLA, security page) are documented and match the controls | CC2.3 | SO | Annual | Current versions of each document | [10](/soc2/10-information-security) |
| COM-05 | Material changes to the system or to commitments are communicated to customers | CC2.3 | SO | On change | Customer notice records, changelog | [16](/soc2/16-secure-development-change) |
| COM-06 | Personnel have an anonymous or out-of-line channel to report concerns | CC2.2 | PO | Continuous | Documented channel | [11](/soc2/11-conduct-acceptable-use) |

## CC3 Risk assessment

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| RSK-01 | A risk assessment identifies threats, vulnerabilities, likelihood and impact for the in-scope system, including fraud risk | CC3.1, CC3.2, CC3.3 | SO | Annual, and on major change | Risk register with dated review | [23](/soc2/23-risk-management) |
| RSK-02 | Each risk above tolerance has an owner and a treatment (mitigate, transfer, accept, avoid) | CC3.2, CC9.1 | SO | Annual | Treatment column in the register; signed acceptances | [23](/soc2/23-risk-management) |
| RSK-03 | Significant changes (new product, new vendor, new region, new data class) trigger a risk review | CC3.4 | SO | On change | Register entry dated at the change | [23](/soc2/23-risk-management) |
| RSK-04 | Cyber insurance coverage is evaluated | CC9.1 | SO | Annual | Quote or policy, or documented decision | [23](/soc2/23-risk-management) |

## CC4 Monitoring activities

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| MON-01 | Control owners self-assess their controls and record exceptions | CC4.1 | SO | Quarterly | Control self-assessment sheet | [10](/soc2/10-information-security) |
| MON-02 | An independent penetration test of in-scope external surfaces is performed and findings tracked to closure | CC4.1, CC7.1 | SO | Annual | Pentest report; remediation tickets | [18](/soc2/18-operations-security) |
| MON-03 | Control deficiencies are tracked to remediation with owner and due date | CC4.2 | SO | Continuous | Tickets labelled `soc2-exception` | [10](/soc2/10-information-security) |
| MON-04 | The trust-surface probe (`audit/probe.py`) runs against every in-scope host | CC4.1 | SO | Monthly | Probe output and scoreboard | [18](/soc2/18-operations-security) |

## CC5 Control activities

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| CTL-01 | Controls are selected against the risk register and mapped to criteria in this matrix | CC5.1, CC5.2 | SO | Annual | This page, dated | [10](/soc2/10-information-security) |
| CTL-02 | Technology general controls (access, change, operations) are deployed through policy and tooling, not by habit | CC5.2, CC5.3 | SO | Annual | Policies 13, 16, 18 approved | [10](/soc2/10-information-security) |

## CC6 Logical and physical access

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| ACC-01 | An inventory of in-scope assets (hosts, databases, storage, domains, repositories, SaaS) is maintained with an owner per asset | CC6.1 | IO | Quarterly | Asset inventory export | [14](/soc2/14-asset-data-management) |
| ACC-02 | Staff access to production, source, cloud consoles and SaaS uses unique named accounts. No shared accounts | CC6.1, CC6.2 | IO | Continuous | Account lists per system | [13](/soc2/13-access-control) |
| ACC-03 | MFA is enforced on workforce identity, cloud console, source host, DNS/Cloudflare, domain registrar, email, and production access | CC6.1 | IO | Continuous; checked monthly | MFA enforcement settings, screenshots or exports | [13](/soc2/13-access-control) |
| ACC-04 | Access is granted on request, approved by the system owner, least privilege | CC6.2, CC6.3 | IO | On request | Access request ticket with approval | [13](/soc2/13-access-control) |
| ACC-05 | Access is removed within 1 business day of departure or role change | CC6.2, CC6.3 | PO | On event | Offboarding checklist with timestamps | [13](/soc2/13-access-control) |
| ACC-06 | User and privileged access to all in-scope systems is reviewed and corrections made | CC6.2, CC6.3 | SO | Quarterly | Signed access review with diffs | [13](/soc2/13-access-control) |
| ACC-07 | Privileged (root, sudo, database superuser, cloud admin) access is limited to named individuals and logged | CC6.1, CC6.3 | IO | Continuous | Privileged account list; audit log | [13](/soc2/13-access-control) |
| ACC-08 | Production administration is reachable only through an authenticated, MFA-protected path; no password SSH; no direct database ports on the internet | CC6.1, CC6.6 | IO | Continuous | SSH config, firewall rules, external port scan | [19](/soc2/19-network-security) |
| ACC-09 | Customer authentication follows the playbook baseline: argon2id or bcrypt, breached-password check, MFA available, admin MFA enforced, rate-limited auth | CC6.1 | CA | Continuous | Gate config and tests | [13](/soc2/13-access-control) |
| ACC-10 | Tenant isolation is enforced server-side and covered by cross-tenant negative tests | CC6.1, C1.1 | CA | Every change | Test names and CI runs | [16](/soc2/16-secure-development-change) |
| ACC-11 | Data at rest in production databases, disks, object storage and backups is encrypted | CC6.1, CC6.7, C1.1 | IO | Continuous | Provider encryption settings; disk encryption status | [15](/soc2/15-cryptography) |
| ACC-12 | Data in transit uses TLS 1.2 or higher on every external and cross-host connection | CC6.7 | IO | Continuous | TLS scan output | [15](/soc2/15-cryptography) |
| ACC-13 | Secrets live in a secrets manager or mode-600 environment files outside git; secret scanning blocks commits | CC6.1 | IO | Continuous | Secret-scanning config and alerts | [15](/soc2/15-cryptography) |
| ACC-14 | Keys and credentials are rotated on schedule and on any exposure | CC6.1 | IO | Annual, and on event | Rotation log | [15](/soc2/15-cryptography) |
| ACC-15 | Physical access to production hardware is restricted (carved out to the cloud or colocation provider; their report reviewed) | CC6.4 | VO | Annual | Vendor SOC 2 review record | [24](/soc2/24-physical-security) |
| ACC-16 | Media and hardware holding customer data are wiped or destroyed on disposal | CC6.5, C1.2 | IO | On event | Disposal record | [14](/soc2/14-asset-data-management) |
| ACC-17 | Endpoints used for production access have disk encryption, screen lock, supported OS, automatic updates, and malware protection | CC6.8 | IO | Quarterly | Endpoint checklist per device | [11](/soc2/11-conduct-acceptable-use) |
| ACC-18 | Coding agents operate under a named human's account, with their production actions logged and attributable | CC6.1, CC6.2, CC8.1 | SO | Continuous | Agent session logs tied to a person | [17](/soc2/17-ai-agents) |

## CC7 System operations

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| OPS-01 | Infrastructure and application logs from in-scope systems are centralised, retained 1 year (180 days minimum for CERT-In, in India), and protected from alteration | CC7.2 | IO | Continuous | Log platform retention settings | [18](/soc2/18-operations-security) |
| OPS-02 | Alerts fire on security and availability events (auth anomalies, 5xx rate, health check failure, disk, backup failure) and reach a human | CC7.2, A1.1 | IO | Continuous | Alert rules; alert history | [18](/soc2/18-operations-security) |
| OPS-03 | Vulnerability scanning of hosts, containers and dependencies; critical findings fixed in 7 days, high in 30 | CC7.1 | IO | Weekly scan | Scan reports; fix tickets with dates | [18](/soc2/18-operations-security) |
| OPS-04 | OS and runtime patches applied on a schedule; security patches automatic | CC7.1 | IO | Monthly | Patch log | [18](/soc2/18-operations-security) |
| OPS-05 | Hosts are configured from a hardened baseline (firewall default deny, unneeded services off, audit logging on) | CC7.1, CC6.6 | IO | Quarterly check | Baseline document; configuration check output | [19](/soc2/19-network-security) |
| OPS-06 | Security incidents are detected, triaged, contained, and recorded per the incident policy | CC7.3, CC7.4 | IL | On event | Incident records | [20](/soc2/20-incident-response) |
| OPS-07 | Every incident gets a post-incident review with corrective actions tracked to closure | CC7.4, CC7.5 | IL | On event | Postmortem document; tickets | [20](/soc2/20-incident-response) |
| OPS-08 | The incident response plan is tested by a tabletop exercise | CC7.4 | SO | Annual | Exercise notes | [20](/soc2/20-incident-response) |
| OPS-09 | Malware protection and file scanning on uploads in in-scope products | CC6.8 | CA | Continuous | Scanner config; detection log | [18](/soc2/18-operations-security) |

## CC8 Change management

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| CHG-01 | Every production change to an in-scope system is made through a pull request to a protected default branch | CC8.1 | CA | Every change | Branch protection settings; PR history | [16](/soc2/16-secure-development-change) |
| CHG-02 | Each PR is reviewed and approved by someone other than its author before merge | CC8.1 | CA | Every change | PR approval record | [16](/soc2/16-secure-development-change) |
| CHG-03 | Automated tests and security checks (SAST, dependency scan, secret scan) pass before merge | CC8.1, CC7.1 | CA | Every change | CI run linked from the PR | [16](/soc2/16-secure-development-change) |
| CHG-04 | Deploys happen only from the merged default branch by the pipeline, and record what, who and when | CC8.1 | IO | Every deploy | Deploy log entries | [16](/soc2/16-secure-development-change) |
| CHG-05 | Emergency changes are allowed, labelled, and reviewed within 2 business days | CC8.1 | CA | On event | PRs labelled `emergency` with retro review | [16](/soc2/16-secure-development-change) |
| CHG-06 | Development, staging and production are separate; production data is not used in development without masking | CC8.1, C1.1 | IO | Continuous | Environment inventory | [16](/soc2/16-secure-development-change) |
| CHG-07 | Infrastructure changes (firewall, DNS, tunnel, cloud config) follow the same review rule, preferably as code | CC8.1 | IO | Every change | Config repo PRs or change tickets | [16](/soc2/16-secure-development-change) |
| CHG-08 | Database schema migrations are reviewed and are reversible or have a tested backup taken first | CC8.1, A1.2 | CA | Every migration | Migration PR; pre-migration backup log | [16](/soc2/16-secure-development-change) |

## CC9 Risk mitigation

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| VND-01 | Every vendor touching in-scope data is in the vendor register with data, purpose, location and risk tier | CC9.2 | VO | Continuous | [07 Vendor register](/soc2/07-vendors) | [22](/soc2/22-vendor-management) |
| VND-02 | High-risk vendors are reviewed before onboarding and yearly: SOC 2 or ISO 27001 report, exceptions, CUECs | CC9.2 | VO | Annual | Review record per vendor | [22](/soc2/22-vendor-management) |
| VND-03 | Contracts with vendors that process customer data include confidentiality, security and breach notice terms (DPA) | CC9.2, C1.1 | VO | At onboarding | Signed DPA or accepted terms on file | [22](/soc2/22-vendor-management) |
| VND-04 | Customers get notice before a new sub-processor handles their data | CC9.2, CC2.3 | VO | On change | Sub-processor page history; notice emails | [22](/soc2/22-vendor-management) |
| BCP-01 | Business continuity and disaster recovery plans exist with RTO and RPO per in-scope service | CC9.1, A1.2 | IO | Annual | Approved [21](/soc2/21-continuity-recovery) | [21](/soc2/21-continuity-recovery) |

## A1 Availability

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| AVL-01 | Capacity (CPU, memory, disk, database connections) is monitored with alert thresholds | A1.1 | IO | Continuous | Dashboards; alert rules | [18](/soc2/18-operations-security) |
| AVL-02 | External uptime monitoring checks every in-scope public endpoint | A1.1 | IO | Continuous | Uptime history | [18](/soc2/18-operations-security) |
| AVL-03 | Production databases are backed up daily, encrypted, to a separate account and region from production | A1.2 | IO | Daily | Backup job logs; storage listing | [21](/soc2/21-continuity-recovery) |
| AVL-04 | A backup is restored into a scratch environment and verified (row counts, app boots) | A1.3 | IO | Monthly per database | Restore test record | [21](/soc2/21-continuity-recovery) |
| AVL-05 | The disaster recovery plan is exercised end to end (rebuild a service from code and backup) | A1.3 | IO | Annual | DR exercise notes with measured RTO and RPO | [21](/soc2/21-continuity-recovery) |
| AVL-06 | Production infrastructure has redundant power and network (provided by the carved-out host) | A1.2 | VO | Annual | Vendor report review | [24](/soc2/24-physical-security) |

## C1 Confidentiality

| ID | Control | TSC | Owner | Frequency | Evidence | Policy |
| --- | --- | --- | --- | --- | --- | --- |
| CNF-01 | Confidential information is identified and classified (P0, P1, P2 per the playbook) in each in-scope app's data map | C1.1 | SO | Annual, and on change | Data maps | [14](/soc2/14-asset-data-management) |
| CNF-02 | Confidential data is not sent to systems or vendors not approved for it (including cloud AI providers not in the app register) | C1.1 | CA | Every change | Vendor register; SOC 2 gate records | [14](/soc2/14-asset-data-management) |
| CNF-03 | Customer data is deleted at the end of retention or on verified request, including propagation to backups within the stated window | C1.2 | IO | Monthly reaper; on request | Deletion logs; request log | [25](/soc2/25-retention-disposal) |
| CNF-04 | On contract termination, customer data is returned or deleted and the customer is told when | C1.2 | SO | On event | Termination record | [25](/soc2/25-retention-disposal) |