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, 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 |
| GOV-02 |
Security roles and owners are named and documented |
CC1.3 CC1.4 |
SO |
Annual, and on change |
Owners table in 00, dated |
10 |
| 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 |
| 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 |
| GOV-05 |
Personnel and contractors sign confidentiality agreements before access |
CC1.1 C1.1 |
PO |
At hire |
Signed NDA or contract clause |
12 |
| 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 |
| GOV-07 |
Job responsibilities for security-relevant roles are written down |
CC1.3 CC1.4 |
PO |
At hire, on change |
Role description |
12 |
| 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 |
| 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 |
| 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, dated |
10 |
| COM-02 |
Policies are published internally; changes are announced to personnel |
CC2.2 |
SO |
On change |
Change log and announcement |
10 |
| 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 |
| 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 |
| COM-05 |
Material changes to the system or to commitments are communicated to customers |
CC2.3 |
SO |
On change |
Customer notice records, changelog |
16 |
| COM-06 |
Personnel have an anonymous or out-of-line channel to report concerns |
CC2.2 |
PO |
Continuous |
Documented channel |
11 |
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 |
| 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 |
| 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 |
| RSK-04 |
Cyber insurance coverage is evaluated |
CC9.1 |
SO |
Annual |
Quote or policy, or documented decision |
23 |
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 |
| 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 |
| MON-03 |
Control deficiencies are tracked to remediation with owner and due date |
CC4.2 |
SO |
Continuous |
Tickets labelled soc2-exception |
10 |
| MON-04 |
The trust-surface probe (audit/probe.py) runs against every in-scope host |
CC4.1 |
SO |
Monthly |
Probe output and scoreboard |
18 |
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 |
| 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 |
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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| ACC-14 |
Keys and credentials are rotated on schedule and on any exposure |
CC6.1 |
IO |
Annual, and on event |
Rotation log |
15 |
| 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 |
| ACC-16 |
Media and hardware holding customer data are wiped or destroyed on disposal |
CC6.5 C1.2 |
IO |
On event |
Disposal record |
14 |
| 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 |
| 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 |
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 |
| 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 |
| 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 |
| OPS-04 |
OS and runtime patches applied on a schedule; security patches automatic |
CC7.1 |
IO |
Monthly |
Patch log |
18 |
| 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 |
| OPS-06 |
Security incidents are detected, triaged, contained, and recorded per the incident policy |
CC7.3 CC7.4 |
IL |
On event |
Incident records |
20 |
| 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 |
| OPS-08 |
The incident response plan is tested by a tabletop exercise |
CC7.4 |
SO |
Annual |
Exercise notes |
20 |
| OPS-09 |
Malware protection and file scanning on uploads in in-scope products |
CC6.8 |
CA |
Continuous |
Scanner config; detection log |
18 |
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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
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 |
22 |
| 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 |
| 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 |
| 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 |
| 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 |
21 |
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 |
| AVL-02 |
External uptime monitoring checks every in-scope public endpoint |
A1.1 |
IO |
Continuous |
Uptime history |
18 |
| 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 |
| 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 |
| 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 |
| AVL-06 |
Production infrastructure has redundant power and network (provided by the carved-out host) |
A1.2 |
VO |
Annual |
Vendor report review |
24 |
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 |
| 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 |
| 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 |
| 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 |