A CPA firm's SOC 2 guide updated on 14 October 2026 breaks the Security category into nine groups of common criteria, CC1 through CC9, and describes what auditors look for in each. Read as a CTO, five of the nine groups land mostly on engineering. At a company of 20 to 60 people, that usually means one person's calendar.
This post maps those groups to systems, owners and evidence so you can delegate before the observation period starts.
What's affected
Using that firm's plain-language summary of each group:
| Group | What the auditor is checking | Typical engineering system |
|---|---|---|
| CC4 Monitoring | Controls are checked and failures are fixed. Vulnerability scans, penetration tests, findings tracked to resolution | Scanner output, ticket tracker |
| CC6 Logical access | Provisioning and removal, access reviews, MFA, encryption | Identity provider, cloud IAM, code host |
| CC7 System operations | Logging and alerting, incident response plan, evidence it was tested or used | Log platform, pager, incident tickets |
| CC8 Change management | Changes are authorized, tested and approved before production | Pull requests, CI, deploy logs |
| CC9 Risk mitigation | Vendor due diligence, business continuity | Vendor register, backup restore tests |
CC1 through CC3 and CC5 (control environment, communication, risk assessment, control activities) are mostly leadership, HR and policy work, though you will likely sign the risk assessment.
How to check if you're exposed
For each row, answer three questions in writing: who owns it, where is the system of record, and what would an auditor open to see it operated last month.
A fast self test for the five rows:
- CC4: pick any scanner finding from last quarter. Can you show who triaged it and when it closed?
- CC6: list everyone with admin on production. Is each one a current employee with a reason?
- CC7: when did you last exercise the incident plan, even as a tabletop?
- CC8: pick five production changes at random. Does each link to an approved pull request?
- CC9: can you list every vendor that touches customer data?
Verizon's 2026 Data Breach Investigations Report page says software vulnerabilities now start more breaches than stolen passwords as the top way attackers get in. That is a reason to take the CC4 row seriously on its own merits, apart from the audit.
What to do now
- Create one page per row with owner, system of record, cadence and the evidence location.
- Make CC8 evidence a by-product of work: branch protection that requires review, CI required to pass, deploys tied to a merged pull request.
- Make CC6 evidence a calendar item: a quarterly access review with a named reviewer, results saved, and removals confirmed by re-pulling the list.
- Put scanner and penetration test findings into the same tracker as product bugs, with severity and due dates.
- Run a 45 minute incident tabletop and keep the notes.
- Hand the vendor register to someone who is not you. It does not need an engineer.
How to avoid this trap
- Do not let one person be the owner and the only reviewer of the same control. The CPA firm's access review guidance says reviews should include managers and system owners, not just IT.
- Do not keep evidence in your head or in chat threads.
- Do not build bespoke tooling for evidence before you know what the auditor samples.
- Do not forget contractors and secondary systems, which are where exceptions tend to appear.
Why it matters
The first six months of a Type 2 are mostly engineering habits proving themselves. A CTO who maps ownership early can spread the work across managers. One who does not usually becomes the bottleneck the CPA firm warns about, where remediation falls on one or two engineers who also have product deadlines.
Quick check
Which common criteria group covers pull request approvals and separation of development from production?
CC8, change management.
Which group would a quarterly access review sit under?
CC6, logical and physical access.
