SOC 2 common criteria: What each CC control actually requires

Most organizations that stumble on their first SOC 2 do not fail because documentation is missing. They fail because the CC-series controls were misunderstood or only partially implemented. 

This guide walks through all nine common criteria, shows where exceptions cluster, and covers how the CC series maps to ISO 27001 and GDPR.

Key takeaways

• The SOC 2 common criteria (CC1–CC9) form the Security Trust Services Criteria and are mandatory in every SOC 2 audit, no matter which additional categories you select.

• CC6 (logical and physical access controls) and CC7 (system operations) generate the most audit exceptions and deserve the most implementation attention.

• CC1–CC3 and CC9 are largely governance controls; CC4–CC8 hold the technical controls auditors test most rigorously.

• Automating evidence collection across the CC series significantly reduces the risk of a qualified opinion.

• Teams pursuing ISO 27001 alongside SOC 2 can reuse roughly 70–90% of their existing controls, based on practitioners' experience working across both frameworks.

What is the SOC 2 common criteria list?

The SOC 2 common criteria, also called the CC series, form the backbone of the Security Trust Services Criteria. These nine criteria evaluate whether an organization has the governance, risk management, access controls, and operational safeguards to protect systems and data.

The CC series is mandatory in every SOC 2 audit, regardless of which optional categories (availability, confidentiality, processing integrity, privacy) you add. Security is always in the audit scope; the CC series is how it gets tested.

The series divides into two groups worth keeping distinct. CC1–CC3 and CC9 are primarily governance and process controls. CC4–CC8 contain the technical controls auditors test with the most rigor and the largest evidence samples.

Within the technical group, CC6.1 stands out: it is the longest and most complex criterion in the entire series, carrying the largest number of individual control points.

Here is a closer look at each criterion.

CC1 — Control environment

CC1 looks at whether leadership has made security accountability explicit: who owns what, how policies get approved, and whether onboarding and offboarding include security roles. The tone-at-the-top framing is real. Auditors check whether named leaders actually signed off on policies, not just whether policies exist.

CC1 is a governance control. Exceptions here are relatively rare and usually reflect missing documentation rather than missing practices. Auditors typically sample board or leadership meeting minutes, the organizational chart, written role-and-responsibility assignments, and evidence that security policies were formally approved by named leadership.

CC2 — Communication and information

This criterion evaluates how effectively the organization communicates its security policies, expectations, and responsibilities, and how relevant information moves internally and externally.

Key aspects:

• Security policies and procedures communicated across departments

• Incident response plans shared and understood

• Reporting mechanisms for employees and third parties

• Communication flowing upward, downward, and across the organization

Auditors confirm policies were formally distributed and that employees acknowledged them, usually through signed acknowledgment logs or LMS completion records. This criterion overlaps heavily with security awareness training requirements, and automated LMS tracking makes evidence collection straightforward.

CC3 — Risk assessment

Organisations must regularly identify, assess, and manage risks that could affect their objectives, including internal and external threats and the risks introduced by technological, operational, or regulatory change.

Key aspects:

• Periodic and event-driven risk assessments

• Identification of relevant threats and vulnerabilities

• Impact and likelihood ratings for each risk

• Documented risk treatment decisions

Auditors pull the risk register first, and they check the scope before they check ratings. They want a register that covers the full scope of the system (cloud, on-prem, software, people, processes), probability and impact ratings for each risk, and evidence of treatment decisions. 

A common miss: a product company runs a thorough risk assessment across its local data center and software development activity, then forgets to cover the cloud where the product is actually hosted. The assessment must cover the full length and breadth of the scoped system, or the gap becomes a finding.

CC4 — Monitoring controls

CC4 assesses how the organization monitors control effectiveness and addresses deficiencies, through both ongoing monitoring (automated alerts, dashboards) and periodic evaluations.

Key aspects:

• Automated tools tracking compliance and control performance

• Internal audits or independent reviews

• Corrective actions for identified control failures

• Escalation procedures for critical issues

Auditors look for evidence of ongoing monitoring and for documentation of corrective actions triggered by identified deficiencies. This is one area where automation changes the audit conversation. Before automated monitoring, auditors often asked for screen recordings of quarterly access reviews to build confidence that a control operated all year. 

Automated monitoring platforms maintain timestamped evidence logs across the observation period, which gives auditors confidence that controls operated continuously rather than only at a point in time.

CC5 — Control activities

CC5 covers the specific actions and mechanisms that mitigate risk: approval workflows, segregation of duties, and audit trails, whether automated or manual. Auditors sample both preventive controls (firewall rules, data validation) and detective controls, and they look for documented evidence that each was actually executed, not just described in a policy.

CC6 — Logical and physical access controls

CC6 is the most complex criterion in the CC series. It contains the largest number of individual control points and is the most common source of audit exceptions and findings. This criterion covers how you manage access to systems, data, and infrastructure, spanning both logical access (passwords, roles, encryption) and physical access (badges, locks, CCTV).

The sub-controls that generate the most findings:

• Hardening standards documentation

• MFA on all privileged accounts

• Named-user policies, with no generic or shared accounts on critical systems

• Access provisioning and deprovisioning with documented approval trails

• Quarterly access reviews

Auditors sample access provisioning and deprovisioning records, verify MFA is actually configured (not just documented in a policy), check that no generic or shared accounts exist on critical systems, and review physical access logs for server rooms or data centers. 

CC6.1 alone carries enough control points that a single gap, missing hardening standards, for example, can generate an exception even when every other control point is satisfied. Role-based access controls and least-privilege principles run through the whole criterion.

The exception-versus-qualification distinction matters here. If one control point within CC6 fails, that surfaces as an exception, not a qualification. Only when every control inside the criterion carries an exception does the whole criterion fail and become a qualification. 

An exception appears in the findings section; a qualification lands on the audit opinion page. That distinction changes how the report reads to your customers. The mechanics mirror ISO 27001’s nonconformance model: a control failing on some samples but passing on others is a minor nonconformance, while a control that fails entirely is a major one.

Quarterly access reviews sit inside CC6 and are the hardest continuous obligation to maintain across a full SOC 2 Type II period. You can manage the entire logical and physical access control surface with scheduled workflows and captured logs.

CC7 — System operations

CC7 ensures systems operate as intended and that deviations, incidents, and failures are detected, reported, and resolved quickly.

Key aspects:

• Monitoring of system health, logs, and performance

• Defined procedures for incident detection and resolution

• Disaster recovery and failover mechanisms

• Patch and vulnerability management programs

Auditors look for evidence that monitoring was active throughout the observation period (not just configured), that incidents were detected and documented, and that vulnerability scans ran on schedule. CC7.1 (configuration and vulnerability management) is heavily sampled, with vulnerability assessment and patch management records among the most-requested items. 

If quarterly scans are required, auditors will expect all four quarters’ results across a 12-month Type II period, and a single missed scan creates an exception. Documented incident response supports the detection-and-resolution side of this criterion.

CC8 — Change management

CC8 evaluates how you manage changes to systems, infrastructure, and applications so that untested or unauthorised changes do not introduce vulnerabilities.

Key aspects:

• Formal change request and approval process

• Impact analysis, testing, and rollback planning

• Segregation of duties between development and deployment

• Emergency change procedures

‍

Auditors look for change tickets, documented approval before deployment, segregation of duties between the person who wrote the code and the person who approved the release to production, and evidence of testing and rollback planning. 

CC8.1 (change management and SDLC) is one of the most exception-prone technical controls for early-stage companies that have not yet formalized their change management and software development lifecycle. The frequent failure: a developer approving their own release to production.

CC9 — Risk mitigation

CC9 requires controls and practices to mitigate identified risks, including vendor risk management, business continuity planning, and ongoing program review.

CC9 covers risk treatment plans with assigned ownership, vendor risk management, and business continuity planning. 

Auditors check vendor risk assessments, vendor contracts with security clauses, and evidence that BCP/DR testing was completed within the required frequency, at a minimum annually, and semi-annually for many organizations. BCP testing (CC9.1) is one of the most commonly missed continuous controls between audit cycles. 

Before automation, it was often evidenced by a single document assertion; auditors now expect scheduled test records with results. CC9.2 (vendor selection) requires a documented vendor risk assessment process, not just a list of vendors.

CC-series quick reference

SOC 2 common criteria mapping

Rigorous CC-series implementation transfers directly to ISO 27001. In practitioners’ experience working across both frameworks, roughly 70–90% of the underlying controls carry over. The main gaps are ISO’s additional management system requirements in clauses 4–10, including communication procedures, performance metrics, and document control with versioning.

What does not transfer automatically: the Statement of Applicability (SOA), the clause 9.3 performance metrics ISO expects you to define and review, and the clause 10 improvement documentation. A team that has completed SOC 2 and wants ISO 27001 certification typically needs to add the SOA and a few ISO-specific process artifacts, not re-implement from scratch. The reverse also holds: an organization that has done ISO 27001 rigorously will generally pass SOC 2.

GDPR is a different case. It is a regulation, not a certification, and completing SOC 2 does not make you GDPR compliant. The overlap sits in the data protection controls, not the legal obligations: data subject rights, consent mechanisms, and breach notification remain separate duties GDPR imposes on you directly. 

SOC 2 common criteria alignment with ISO 27001 and GDPR

Benefits of SOC 2 common criteria mapping

Organizations pursuing both SOC 2 and ISO 27001 run one compliance program, not two. They extend the evidence set rather than rebuild it, which reduces duplicated work and the resource drain of maintaining parallel systems.

That directly affects compliance cost. An organization already holding SOC 2 Type II that then pursues ISO 27001 typically finds the incremental effort is documenting the SOA and adding a few management system artifacts, not a full re-implementation. You pay for the delta, not the whole program again.

On regulatory alignment, the CC-series controls give you a strong foundation for GDPR Article 32 (technical security measures), and that is a genuine benefit. What they do not do is substitute for the legal obligations GDPR imposes. Data subject access requests, consent management, and 72-hour breach notification remain separate duties that a completed CC series does not close out.

How the CC series strengthens your security posture

The value of the CC series is not that it produces a report. Implementing the series forces a security program to become explicit and repeatable, top to bottom. Governance controls (CC1–CC3, CC9) make accountability, risk decisions, and vendor oversight visible and owned. 

Technical controls (CC4–CC8) turn that governance into enforced practice: access is provisioned and revoked on approval, changes are reviewed before they ship, vulnerabilities are scanned and patched on a schedule, and monitoring runs continuously.

For a leadership team, that structure means fewer surprises. When access reviews happen every quarter and change approvals are captured automatically, you are not scrambling to reconstruct a year of evidence the week before an audit. You have a defensible security posture you can demonstrate on demand, which is increasingly what enterprise customers ask for. 

The CC series, implemented well, is less a compliance exercise than an operating discipline that keeps the organization audit-ready and genuinely more secure between cycles.

Business use cases for the common criteria

Which CC controls trip up first-timers (and which are easier than they look)

Exception risk varies significantly across the CC series. Some controls generate findings in nearly every first audit; others look complex on paper but are straightforward to evidence.

The series splits roughly into governance controls, which carry lower exception risk and are easier to evidence, and technical controls, which carry higher exception risk and require ongoing operational evidence.

Governance-level, lower exception risk: CC1 (control environment), CC2 (communication and information), and CC9.2 (vendor selection) are policy and process-heavy. A well-documented program passes them with relatively straightforward evidence. These are the criteria that look intimidating in the standard’s language but are manageable once your policies and role assignments are in order.

Technical controls that generate the most exceptions:

• CC6.1 is the longest criterion, with control points spanning IAM configuration, hardening standards, MFA, physical access, and access reviews. A gap in any single control point generates an exception. The most commonly missed items are hardening standards documentation and quarterly access review records.

• CC7.1 covers configuration and vulnerability management. Missed quarterly scans are the most common finding, and not because teams do not know scans are required. Scheduling usually falls to whoever owns infrastructure, and between audit cycles it slips. If a 12-month Type II period requires four quarters of scan results and one quarter is missing, the auditor notes an exception regardless of how clean the other three are.

• CC8.1 is change management and SDLC. Segregation-of-duties gaps, most often a developer approving their own release to production, are a frequent exception for early-stage companies that have not yet formalized their release process.

Controls that look intimidating but are manageable with automation:

• CC4 (monitoring controls) is hard to evidence manually but straightforward with a GRC platform. Automated tools generate timestamped monitoring logs across the observation period, which directly satisfies the evidence requirement.

• CC3 (risk assessment) looks complex, but a well-structured risk register covering the full system scope is sufficient. Over-engineering it with heavy quantitative models is not required for a first SOC 2.

One reassurance for first-timers: a SOC 2 audit is not pass/fail. An exception in a single control does not fail the audit. Most first-time audits include some exceptions. A qualification in which an entire criterion fails affects the opinion page. The goal is to minimize exceptions and keep the opinion unqualified. For more on preparing, see our 5 best practices for a successful SOC 2 audit.

Maintaining CC-series controls between audit cycles

Passing a SOC 2 Type II audit is a point-in-time outcome tied to an observation period. Compliance drift between cycles is common, and it gets detected during the next Type II observation window. Staying compliant is a continuous exercise, not a once-a-year push.

The CC controls most prone to drift:

• CC6 access reviews: Quarterly access reviews must be completed on schedule every quarter across the observation period. A single missed quarter creates an exception. Automated reminders and access review workflows prevent this.

• CC7 vulnerability management: Quarterly scans must be scheduled and completed. If patch cadence lapses between cycles, the next audit shows gaps.

• CC9.1 BCP testing: Annual or semi-annual BCP/DR testing requires scheduling and evidence preservation. Without a tracking system, it is one of the most frequently missed controls.

• CC2 policy reviews: Policies must be reviewed and re-approved on the schedule stated in the policy itself, typically annual. Lapsed reviews generate CC2 exceptions.

The most effective operational control against drift is a GRC platform with automated scheduling and alert escalation that flags controls approaching expiry or already lapsed. Think of it as the ADAS system on a highway: you may be driving correctly, but the sensors flag a problem before it becomes one. 

A continuous compliance platform works the same way, flagging approaching expiry before a control lapses rather than surfacing the gap at audit time. Teams using automated evidence collection and compliance monitoring get this early warning built in.

The goal is to be audit-ready at any point in time, not just at the end of an observation period. Enterprise customers increasingly run their own on-demand assessments of vendor compliance posture, and you want to be ready when they do.

How Scrut helps automate SOC 2 compliance

Manually chasing evidence across Slack threads and spreadsheets can turn SOC 2 prep into a multi-week fire drill. A compliance automation platform addresses this directly, and it addresses the highest-exception-risk CC controls specifically:

• CC6 access reviews through automated scheduling and log capture, so every quarterly review is completed and evidenced on time.

• CC7 vulnerability management through automated scan scheduling and results archiving, so no quarter goes missing.

• CC4 monitoring through timestamped continuous evidence logs that auditors can sample across the full observation period, not just at a single point in time.

• CC8 change management through ticketing system integrations that capture the approval trail: who approved, when, and what was deployed.

That is the operational difference practitioners describe most often between manual and automated programs. Contentstack moved off spreadsheets and, in the words of Matt Black, their Director of Information Security, “has been able to stay on top of our SOC 2 controls in a way that’s reducing that timeline by about 2 months,” with their ISO 27001 audit timeline cut by about four weeks. 

Sounding Board replaced a consultant-and-spreadsheet model with real-time visibility into policies and evidence that Ron Buell, their CTO, described as a level of detail the consultant model never provided.

See how Scrut maps to every CC control.

FAQs

1. What are the SOC 2 common criteria?

The SOC 2 common criteria are the nine subcategories (CC1–CC9) within the Security Trust Services Criteria that evaluate an organization's internal controls, covering control environment, communication, risk assessment, monitoring, control activities, access, system operations, change management, and risk mitigation. They are mandatory in every SOC 2 audit, regardless of which additional TSC categories you select, and they map specifically to the Security Trust Services Criteria.

2. Why is the Security Trust Services Criteria required for every SOC 2 audit?

The Security TSC, tested through the CC series, is mandatory because it establishes the baseline governance, risk, and access control requirements that all other TSC categories build on. It ensures systems are protected against unauthorized access, vulnerabilities, and security risks before any optional category is even considered.

3. How do the SOC 2 common criteria relate to other frameworks like ISO 27001 and GDPR?

The CC series maps closely to ISO 27001. In practitioners' experience working across both, roughly 70–90% of the underlying controls carry over, with ISO's management system clauses (4–10), the SOA, and performance metrics being the main additions. GDPR is different: it is a regulation, not a certification. The CC series supports GDPR Article 32 technical measures but does not satisfy GDPR's legal obligations like data subject rights or breach notification.

4. Where do companies most often get SOC 2 exceptions?

Most exceptions cluster in the technical controls: CC6 (logical and physical access), CC7 (system operations), and CC8 (change management). Common triggers are missing hardening standards, a skipped quarterly access review, a missed vulnerability scan, and developers approving their own releases to production.

5. What is the difference between an exception and a qualification?

Most first-time audits include some exceptions, and that is not a failure. An exception means one or a few control points within a criterion failed. It shows up in the findings section, not the opinion. A qualification is different: it means an entire criterion failed, and it lands on the opinion page, which is what your customers read first. The goal is to keep the opinion unqualified.

6. How can organizations prepare for a SOC 2 audit using the common criteria?

Start by implementing the governance controls (CC1–CC3, CC9) with clear policies, role assignments, and a full-scope risk register. Then focus on the technical controls auditors test hardest (CC6, CC7, CC8), making sure MFA, hardening standards, access reviews, vulnerability scans, and change approvals are not just documented but actually operating and evidenced across the observation period.

‍