SOC 2 Common Criteria (CC1 to CC9), explained

By Sam Rivera, Founder, SentinelPanda · February 27, 2026 · 3 min read · SOC 2

Every SOC 2 report covers the same nine Common Criteria categories. Knowing what each one expects is how you stop a friendly Type I conversation from turning into a list of management responses.

CC1 — Control Environment

Tone at the top, the existence of a board or equivalent, integrity and ethics commitments, organisational structure, and accountability. Auditors here are checking that someone owns the program: a security policy with a real owner, a code of conduct, an org chart that survives a question, and disciplinary actions that have actually been used. Light on technical evidence, heavy on documentation and HR records.

CC2 — Communication and Information

Internal and external communication of security and control matters. Examples: a security policy that has been distributed, an internal channel where incidents are reported, customer-facing commitments published in the right place, and a way for outsiders to report a vulnerability or a privacy concern. A responsible disclosure page and an internal incident channel cover most of it.

CC3 — Risk Assessment

A periodic risk assessment process — not a one-time spreadsheet — that identifies threats, evaluates likelihood and impact, considers fraud risk, and considers significant changes (new product line, new region, M&A). Auditors want to see the methodology, the run history, and what the assessment changed downstream. Tying a risk register to control coverage is the cleanest evidence.

CC4 — Monitoring Activities

The controls that watch the other controls. Internal audit reviews, control self-assessments, vulnerability scanning, log monitoring with alerting, and the process for resolving deficiencies. The standard expects monitoring to be ongoing, not annual, and the corrective-action records are what auditors test.

CC5 — Control Activities

A general category about selecting and developing controls and the policies that put them into action. In practice this is mostly evidenced through the other categories — the controls you have already designed for access, change, and operations show up here. Auditors will want to see the policies that document those controls and the technology that enforces them.

CC6 — Logical and Physical Access

Where the bulk of evidence sits. Identity provisioning and deprovisioning, multi-factor authentication, privileged access controls, periodic access reviews, network segmentation, encryption in transit and at rest, key management, and physical security of the office and data centre estate. If your subservice organisations provide some of these (cloud provider for physical security, identity provider for MFA), the carve-out method lets you rely on their SOC 2 with complementary user-entity controls.

CC7 — System Operations

Detecting incidents and recovering from them. Vulnerability management, log monitoring and alerting, the incident response programme, disaster recovery testing, and backup procedures. Auditors will read the incident response runbook, look at the post-incident reviews from the period, and test that backups are actually restorable.

CC8 — Change Management

How changes to systems, infrastructure, and applications get authorised, tested, and deployed without breaking things. Expect to evidence a development lifecycle, code review, separation of environments, automated testing where used, change approvals, and the rollback plan. Pull requests with required approvers and a CI/CD pipeline with stage gates cover most of this for a modern engineering team.

CC9 — Risk Mitigation

How the entity identifies, selects, and develops risk mitigation activities, including business continuity, insurance, and the management of vendor risk. Vendor due diligence, the vendor inventory, contractual security commitments, cyber insurance, and the business continuity plan all sit here. The vendor register is the single most useful artifact for this category.

Where new programs stumble

CC6, CC7, and CC8 are where most evidence and most findings concentrate. CC1 through CC5 are usually achievable with documentation and a working risk programme. The mistake first-timers make is over-investing in policy writing for CC1 and under-investing in the actual technical evidence that CC6 through CC8 demand. Reverse that order and the Type II observation period will go much smoother.