The Security criteria is the mandatory core of every SOC 2 audit. It is organized into 33 individual criteria grouped into nine clusters — CC1 through CC9 — each cluster addressing a distinct domain of security control. Together, these 33 criteria define what an auditor tests when they assess whether a service organization’s security controls are suitably designed and — in a Type II audit — operating effectively.
Understanding the Common Criteria at this level of detail matters for two reasons. First, it allows organizations to map their existing controls to specific criteria before the readiness assessment — identifying gaps early and avoiding surprises. Second, it tells you where auditors will concentrate their effort: CC6 (logical access) and CC7 (system operations) consistently account for the majority of audit time and the most common exception findings.
The COSO Foundation
The Common Criteria are built on the COSO 2013 Internal Control — Integrated Framework. COSO is the Committee of Sponsoring Organizations of the Treadway Commission, and their internal control framework is the foundation of US financial reporting controls. The AICPA deliberately anchored SOC 2’s Security criteria to COSO because SOC 2 auditors are CPAs who already work with COSO in financial audits.
| KEY IDEA | COSO identifies five components of internal control: Control Environment, Risk Assessment, Control Activities, Information and Communication, and Monitoring. These map directly to the CC1–CC5 clusters in SOC 2’s Common Criteria. CC6–CC9 extend the framework to cover technology-specific domains: logical access, system operations, change management, and risk mitigation. |
CC1 — Control Environment
CC1 establishes the organizational foundation from which all other controls operate. Auditors testing CC1 are asking whether leadership has set an appropriate “tone at the top” for security. The five COSO principles addressed in CC1 cover commitment to integrity and ethical values, board oversight of internal controls, organizational structure and reporting lines, commitment to competence, and accountability mechanisms.
Evidence for CC1 includes: a code of conduct signed by all employees, board meeting minutes showing security oversight discussions, an organizational chart, job descriptions for security-relevant roles, and performance management records showing accountability for security responsibilities. CC1 is foundational — if the control environment is weak, auditors will question the reliability of all other controls.
CC2 — Communication and Information
CC2 addresses how security-relevant information is communicated internally and externally. Internally, this means: do employees understand their security responsibilities? Are policies accessible? Is there a mechanism for reporting security issues? Externally, it means: are clients and other external parties appropriately informed about your security commitments and any security events that affect them?
Evidence for CC2 typically includes: the security awareness training program and completion records, the employee handbook or security policy acknowledgment log, the mechanism for reporting security incidents (e.g., an internal reporting channel), and the client communication templates used for security notifications.
CC3 — Risk Assessment
CC3 requires organizations to have a defined, documented process for identifying and analyzing risks to the achievement of their system security objectives. This is not a one-time exercise — auditors expect to see evidence of an ongoing risk assessment process, including periodic risk register reviews, risk reassessment triggered by organizational changes, and consideration of fraud risk.
| IMPORTANT | CC3 requires explicit consideration of fraud risk — a requirement that surprises many technology organizations accustomed to thinking about security risk purely in terms of external threats. Insider fraud, misuse of privileged access, and collusion must be explicitly considered and addressed in the risk assessment. |
CC4 — Monitoring Activities
CC4 covers the ongoing monitoring of whether the system of internal controls is operating effectively. This includes both continuous monitoring (automated alerting, system health dashboards, log monitoring) and discrete evaluations (internal audits, penetration tests, vulnerability scans, management reviews). The key requirement is that deficiencies identified through monitoring are communicated and addressed.
CC5 — Control Activities
CC5 addresses the specific control activities selected to mitigate risks identified through the CC3 risk assessment. These include policies, procedures, and technology controls. CC5 is where the risk assessment becomes operational: having identified a risk, what specific control has the organization deployed? Is that control documented? Is it consistently applied across the scope of the system?
CC6 — Logical and Physical Access (The Highest-Scrutiny Cluster)
CC6 is the most extensively tested cluster in a SOC 2 audit. It covers: logical access security software (firewalls, network segmentation, endpoint protection), authentication mechanisms including multi-factor authentication (MFA), authorization and access control (RBAC, least privilege), access provisioning and deprovisioning, access review processes, and physical access controls to facilities and data centers.
| CC6 Sub-Area | What Auditors Test | Common Findings |
|---|---|---|
| Multi-Factor Authentication (MFA) | Whether MFA is enforced for all users accessing systems in scope — including cloud infrastructure consoles, VPN, and administrative accounts | MFA enforced for standard users but not enforced for service accounts or contractors |
| Access Provisioning | Whether new user access follows an approved workflow with appropriate business justification and segregation of duties | Informal provisioning via chat or email without documented approval trail |
| Access Reviews | Whether periodic (typically quarterly) reviews of who has access to what are conducted and documented | Reviews performed but not documented; stale access not revoked following the review |
| Access Deprovisioning | Whether terminated employee access is revoked within a defined timeframe (typically same-day or 24 hours) | Access revoked for corporate SSO but residual access remains in individual SaaS tools |
| Privileged Access Management | Whether privileged and administrative accounts are separately managed, monitored, and time-limited | Shared admin accounts with no individual accountability |
| Physical Access | Whether access to offices and data centers is controlled and logged | Tailgating controls absent; visitor logs incomplete |
CC7 — System Operations
CC7 covers the operational controls that detect and address deviations from expected system behavior. This includes vulnerability management (scanning, classification, remediation SLAs), security monitoring and SIEM alerting, malware protection, environmental controls (data center physical conditions), and — critically — incident management from detection through post-incident review.
| BITLION INSIGHT | CC7 is where the “running the controls” requirement becomes most visible in a Type II audit. Auditors will sample your incident register, pull individual incident tickets, and trace from alert through response through resolution. If your incidents are not documented, classified, and closed with evidence, CC7 will generate exceptions. |
CC8 — Change Management
CC8 covers the controls over infrastructure and software changes. The key requirement is that changes are authorized, tested, and deployed through a defined process that prevents unauthorized or untested changes from reaching production systems. Evidence includes change request tickets, test results or test sign-offs, deployment approvals, and rollback procedures.
CC9 — Risk Mitigation
CC9 is the broadest cluster, covering the risk mitigation strategies deployed to address risks that cannot be fully controlled through internal controls alone. This primarily covers vendor and third-party risk management (are your critical vendors assessed? do they have their own SOC 2 reports?) and business continuity (do you have documented recovery procedures? have you tested them?).
| CC Cluster | Primary Focus | Typical Evidence Requested | Audit Intensity |
|---|---|---|---|
| CC1 | Control environment & governance | Code of conduct, org chart, board minutes, job descriptions | Moderate |
| CC2 | Communication & information | Training records, policy acknowledgments, notification procedures | Low-Moderate |
| CC3 | Risk assessment | Risk register, risk methodology, fraud risk assessment | Moderate |
| CC4 | Monitoring | Internal audit reports, pentest results, management review minutes | Moderate |
| CC5 | Control activities | Policies, procedures, control matrix | Moderate |
| CC6 | Logical & physical access | MFA enforcement, access reviews, provisioning/deprovisioning tickets, access logs | High — most scrutinized |
| CC7 | System operations | Incident register, vulnerability scan results, SIEM alerts, change tickets | High |
| CC8 | Change management | Change request records, approval workflows, test evidence, deployment logs | High |
| CC9 | Risk mitigation / vendor / BCP | Vendor assessments, vendor SOC 2 reports, BCP/DR plan, tabletop exercise records | Moderate-High |