Introduction
SOC 2 is built on five Trust Services Criteria (TSC), but only one is mandatory for every report: Security — formally called the Common Criteria. Whether your organization elects one additional category or all four, CC1 through CC9 form the non-negotiable baseline every auditor will examine.
Because those criteria form the floor of every SOC 2 audit, this guide focuses specifically on the CC series: what each subcategory requires, how it connects to frameworks like ISO 27001 and CMMC, and how to scope your report so auditors don't find gaps you missed.
Who should read this:
- SaaS companies and cloud service providers preparing for their first or renewal SOC 2
- Defense contractors navigating both SOC 2 and CMMC requirements simultaneously
- Service organizations storing or processing customer data
- Compliance officers determining which TSC categories to include
Key Takeaways
- All nine Common Criteria (CC1–CC9) are mandatory for every SOC 2 report, regardless of scope
- CC1–CC5 are derived directly from the COSO 2013 Internal Control Framework's 17 principles
- Points of Focus are guidance, not requirements — use them to design controls, not tick a checklist
- Defense contractors can satisfy both CMMC Level 2 and SOC 2 through shared control intent — CC3, CC6, CC7, and CC8 are the primary overlap zones
- Official AICPA mapping documents exist for both ISO 27001 and GDPR — use them to avoid duplicating control work across frameworks
What Are SOC 2 Common Criteria?
The Common Criteria are the nine subcategories within the Security Trust Services Category that every SOC 2 report must address. They're labeled CC1 through CC9 in the AICPA's 2017 Trust Services Criteria (with Revised Points of Focus — 2022), the governing document for all SOC 2 engagements.
The COSO Lineage
CC1 through CC5 map directly to all 17 principles of the COSO Internal Control – Integrated Framework (2013). CC6 through CC9 are additional Security-specific criteria that extend beyond that foundation. The CC series follows a deliberate progression:
- CC1–CC2: Culture, governance, and communication
- CC3–CC5: Risk identification and control selection
- CC6–CC9: Technical and operational execution
Understanding that progression helps organizations sequence their compliance work — you can't design effective access controls (CC6) without first understanding your risk profile (CC3).
Type I vs. Type II: A Critical Distinction
| Attribute | Type I | Type II |
|---|---|---|
| Time basis | "As of" a single date | Defined period |
| Control design | Evaluated | Evaluated |
| Operating effectiveness | Not tested | Tested over the period |
A Type I report confirms controls are suitably designed. A Type II report goes further: it tests whether those same controls actually operated as designed throughout the period. This distinction shapes how you document and gather evidence for each CC subcategory. Design evidence alone won't satisfy a Type II engagement.
Points of Focus: Guidance, Not Mandates
Points of Focus are AICPA guidance notes that describe important characteristics of each criterion. The TSC is explicit: they are not requirements, and "use of the trust services criteria does not require an assessment of whether each point of focus is addressed."
In practice, that means:
- Auditors use Points of Focus to assess whether your controls meet the intent of the criterion
- Your team should use them to build controls that hold up under that assessment — not as a mandatory checklist to tick off line by line
Breaking Down All 9 Common Criteria Subcategories
All nine subcategories apply to every organization in scope for SOC 2 — regardless of which additional Trust Services Criteria categories are elected. Understanding what each one requires (and where auditors commonly find gaps) is the fastest way to know where your program stands.
CC1 — Control Environment
CC1 addresses whether the organization operates with integrity and a security-conscious culture. Auditors examine:
- Documented organizational structures and reporting lines
- Board-level or executive oversight of security responsibilities
- Written conduct and ethics policies
- Evidence that accountability for internal controls is defined and enforced
Weak governance at CC1 tends to surface as deficiencies throughout the rest of the audit — it's the control environment every other subcategory builds on.
CC2 — Communication and Information
CC2 requires that security-relevant information reaches the people who need it — internally and externally. Key evidence includes:
- Whether policies are accessible, current, and formally acknowledged by employees
- Whether customers and partners receive adequate disclosures about the system
- Communication channels for reporting security concerns
A common gap here: policies exist but haven't been updated in years, or employees can't demonstrate they've read them.
CC3 — Risk Assessment
CC3 requires a formal, recurring process for identifying and responding to risks. This means more than a one-time exercise. Auditors look for:
- A documented risk register with defined risk tolerance
- Evidence that the process captures changes in technology, business environment, or threat landscape
- Consideration of fraud risk (mapped to COSO Principle 8)
The word "recurring" matters. A risk assessment done once before the audit window opens won't satisfy a Type II examiner.
CC4 — Monitoring Activities
CC4 requires active monitoring of whether controls are working — not just a policy stating that monitoring occurs. Expect scrutiny of actual evidence:
- Internal control assessments and their results
- Vulnerability scan outputs and remediation tracking
- Penetration testing results
- Documented follow-up on identified deficiencies
The AICPA points of focus specify that evaluations occur "on a periodic basis." No specific frequency is mandated, but gaps in cadence will draw scrutiny.
CC5 — Control Activities
CC5 covers the specific policies, technologies, and processes selected to address identified risks. Common requirements include:
- Segregation of duties configurations
- Endpoint security and hardening standards
- Change authorization procedures
- Technology controls supporting general IT operations
CC5 is the bridge between risk assessment (CC3) and technical implementation (CC6–CC9). If CC3 identifies a risk and CC5 doesn't document a corresponding control, that's a gap auditors will flag.
CC6 — Logical and Physical Access Controls
CC6 covers who can access systems (logical) and who can enter physical environments (physical). The audit trail covers:
- Access provisioning and deprovisioning logs, particularly for employee terminations
- Multi-factor authentication enforcement
- Encryption practices for data at rest and in transit
- Physical access records for data centers or server rooms
Access control is one of the most evidence-intensive subcategories. Organizations that rely on manual processes often struggle to produce clean provisioning logs on demand.
CC7 — System Operations
CC7 governs how systems are monitored during normal operations and how incidents are detected and managed. Auditors look for:
- Defined incident response plans with documented roles
- Logging and alerting configurations — and evidence that alerts were actually reviewed
- Vulnerability management processes
- Recovery procedures tested periodically (the TSC specifies "periodic basis," not a fixed annual interval)
The distinction between having an incident response plan and having evidence it was exercised is where many organizations fall short.
CC8 — Change Management
CC8 requires that changes to in-scope systems — code deployments, infrastructure changes, configuration updates — go through a controlled process before implementation. Reviewers examine:
- Change records with approval sign-offs
- Testing documentation prior to deployment
- Rollback procedures
- Evidence that unauthorized changes don't occur outside the approved process
CC9 — Risk Mitigation
CC9 addresses risks that originate from outside the organization itself — business disruptions and third-party vendors. Auditors look for:
- A vendor risk management program with documented security reviews
- Business continuity plans addressing operational disruptions
- Evidence that vendor reviews are conducted, not just that a program exists on paper
The 4 Additional Trust Services Criteria
Beyond CC1–CC9, organizations can elect up to four additional categories based on their services and customer commitments. These add to the CC foundation — they don't replace it.
| Category | Code | When It Applies |
|---|---|---|
| Availability | A | Cloud and SaaS providers with uptime commitments |
| Processing Integrity | PI | Organizations processing data on customers' behalf |
| Confidentiality | C | Organizations handling trade secrets or sensitive client data |
| Privacy | P | Organizations collecting PII or PHI |
One nuance worth understanding across all five TSC categories: the AICPA confirms that logical-access criteria apply to each of them. A single well-documented control can satisfy requirements in multiple categories — but only if that coverage is explicitly stated in your system description. Assumed overlap won't hold up under audit.
Scoping Your SOC 2 Report: Which Criteria Apply?
The Scoping Decision
Organizations select TSC categories based on service commitments, customer expectations, and regulatory requirements. Every selected category — including any additional TSC — includes all nine Common Criteria as its baseline.
The sequence:
- Determine which TSC categories reflect what your system actually does
- For each selected category, assess which individual criteria apply
- Document the scope clearly in your system description
Handling Non-Applicable Criteria
If a specific criterion doesn't apply — for example, because an activity is fully outsourced to a sub-service organization — you must use the carve-out method and provide documented justification. The carve-out identifies the outsourced services and the controls the sub-service organization is responsible for.
What you cannot do is simply omit a criterion without explanation. Unsubstantiated exclusions are a recognized source of SOC engagement deficiencies, documented in AICPA peer review findings.
That documentation discipline carries directly into dual-framework environments, where control mapping between SOC 2 and CMMC can eliminate significant redundant work — if the scoping is done deliberately.
CMMC and SOC 2: Building Dual-Framework Capability
Defense contractors increasingly face both SOC 2 and CMMC requirements simultaneously. The control intent overlaps substantially across several subcategories:
| SOC 2 Subcategory | CMMC Level 2 / NIST 800-171 Parallel Areas |
|---|---|
| CC3 Risk Assessment | RA.L2-3.11.x (risk assessments, vulnerability scanning, remediation) |
| CC6 Logical & Physical Access | AC 3.1.x (access controls), IA 3.5.x (authentication), PE 3.10.x (physical protection) |
| CC7 System Operations | AU 3.3.x (audit/logging), IR 3.6.x (incident handling), SI 3.14.x (monitoring) |
| CC8 Change Management | CM 3.4.x (configuration management, change control, least functionality) |
Organizations that treat these as two separate compliance programs typically duplicate significant effort. Addressing both frameworks under a single structured program lets teams build shared capability rather than running parallel tracks. QMS Learning's Defense Cybersecurity Readiness pathway covers CMMC, NIST 800-171, ISO 27001, and SOC 2 in a single program — so teams develop the cross-framework judgment to map controls once rather than building two separate compliance stacks.
How SOC 2 Common Criteria Map to Other Frameworks
ISO 27001
The AICPA publishes an official mapping between the 2017 Trust Services Criteria and ISO/IEC 27001:2013. Both frameworks take a risk-based approach to information security controls, making them natural complements for organizations pursuing dual compliance.
Organizations serving enterprise customers in regulated industries often find that ISO 27001 certification and SOC 2 Type II together satisfy a wider range of customer due diligence requests than either report alone.
GDPR
The AICPA also publishes a mapping between the 2017 TSC and GDPR, updated October 2020. Organizations serving EU customers frequently pursue both together. The most direct overlap is between the Privacy TSC and CC2 (Communication and Information), which governs how information is disclosed to external parties — a core GDPR requirement.
SOC 1 and SOC 3
Two adjacent reports often create confusion:
- SOC 1 addresses Internal Control over Financial Reporting (ICFR) — a different subject matter entirely. A SOC 1 report is not evidence that Trust Services Criteria were examined.
- SOC 3 covers the same five TSC areas as SOC 2 but with far less detail. It's a separate examination designed as a freely distributable public credential — not a condensed version of an existing SOC 2 report.
Neither report substitutes for the other. If your goal is a public-facing security credential, a SOC 3 requires its own examination — plan and scope it accordingly.
Frequently Asked Questions
What are the criteria for SOC 2 compliance?
SOC 2 compliance requires all nine Common Criteria (CC1–CC9) under the Security Trust Services Category, plus any additional TSC categories the organization elects based on its services. No SOC 2 report can exclude the CC series: it is the mandatory baseline for every engagement.
What is SOC 1, SOC 2, and SOC 3?
SOC 1 reports on controls relevant to financial reporting (ICFR). SOC 2 reports on controls relevant to security and related Trust Services Criteria. SOC 3 covers the same TSC subject matter as SOC 2 but provides less detail and is designed as a publicly distributable general-use report.
What is the difference between SOC 2 Common Criteria and Trust Services Criteria?
Trust Services Criteria is the broader five-category framework (Security, Availability, Processing Integrity, Confidentiality, Privacy). Common Criteria specifically refers to the nine CC-series subcategories within the mandatory Security category. All five TSC categories include the Common Criteria as their foundation.
Are all 9 Common Criteria required for every SOC 2 report?
Yes — all nine CC subcategories are mandatory for any SOC 2 engagement. Individual criteria within a subcategory may be excluded through a documented carve-out, but only in limited circumstances where the criterion is genuinely not applicable to the system under examination.
What is the difference between SOC 2 Type I and Type II?
Type I evaluates whether controls are suitably designed at a single point in time. Type II evaluates both design and operating effectiveness over a defined observation period (no AICPA-mandated minimum, but long enough to demonstrate consistent operation), making it the more rigorous and broadly recognized report.
How do SOC 2 Common Criteria relate to ISO 27001 or CMMC?
The AICPA publishes official mapping documents between SOC 2 and ISO 27001, with meaningful overlap in risk assessment and access control. CMMC Level 2 shares control intent with CC3, CC6, CC7, and CC8, so defense contractors can satisfy both frameworks through shared evidence and documentation.
