SOC 2 Common Criteria: What They Are and Why They Matter

Every SOC 2 engagement — regardless of which Trust Services Criteria are in scope — is built on the Common Criteria. They are the non-negotiable foundation. Before CertPro CPA LLC tests Availability, Confidentiality, Processing Integrity, or Privacy controls, the Common Criteria are tested. Every time. Without exception.

The SOC 2 Common Criteria are the nine control categories within the Security Trust Services Criterion that address the organizational governance, risk management, access control, monitoring, change management, and vendor oversight disciplines that underpin every other SOC 2 control requirement. They are published by the AICPA and designed to be comprehensive enough to constitute a complete security control framework on their own — while also serving as the shared foundation for the additional Trust Services Criteria.

This guide from CertPro CPA LLC explains each of the nine Common Criteria categories in detail — what they require, what controls organizations must implement, and how CertPro CPA LLC tests them during the SOC 2 examination.

Tl; DR:

Concern: With every SOC 2 controls implementation requiring a clear starting point, service organizations find it hard to understand what the Common Criteria specifically require — and how they differ from the additional Trust Services Criteria that may also be in scope.
Overview: The SOC 2 Common Criteria are the nine control categories within the Security Trust Services Criterion that form the mandatory foundation of every SOC 2 engagement — published by the AICPA and tested by CertPro CPA LLC in every examination regardless of which additional criteria are in scope.
Solution: Service organizations should understand what each of the nine Common Criteria categories requires, how controls within each category must be documented and operated, and how the Common Criteria interact with the additional Trust Services Criteria to form a complete SOC 2 control environment.

SOC 2 Common Criteria: What They Are and Why They Matter

The Common Criteria are the control requirements that appear in every SOC 2 attestation engagement. They are not optional and they are not a subset of the Security criterion — they are the Security criterion, organized into nine categories that together cover the full landscape of security governance, operational security, and risk management. The full Common Criteria framework is published by the AICPA in the Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Why the Common Criteria Are the Foundation of Every SOC 2 Engagement

When a service organization implements controls for Availability, Confidentiality, Processing Integrity, or Privacy, those controls do not exist independently of the Common Criteria — they extend them. An Availability control that monitors uptime relies on the CC7 monitoring infrastructure. A Privacy control that manages personal data access relies on the CC6 access management framework. A Processing Integrity control that validates transactions relies on the CC8 change management discipline that prevents unauthorized modifications to processing logic.

The Common Criteria are foundational because without them, the additional criteria have no structural support. A service organization that implements Privacy controls but has inadequate access management (CC6) or no monitoring (CC7) does not have a functioning privacy programme — it has a policy document with no operational backing.

Understanding the Common Criteria in depth is therefore the most efficient path to a well-designed SOC 2 control environment — because strengthening the Common Criteria strengthens every other criterion simultaneously.

CC1 — Control Environment

The control environment criterion addresses the organizational culture, governance structures, and human capital practices that create the conditions under which effective security controls can operate. It is sometimes described as the “tone at the top” criterion — because it evaluates whether leadership genuinely prioritizes security, not just whether security policies exist on paper.

CC1.1 — Commitment to integrity and ethical values
The organization demonstrates through its actions that it values integrity and ethical conduct. Security policies are enforced, not just documented. Personnel who violate security requirements face real consequences.
Required controls: Code of conduct policy, evidence of acknowledgment by all personnel, disciplinary procedure documentation, and evidence of enforcement actions taken during the observation period.

CC1.2 — Board independence and oversight
The board or equivalent governance body exercises independent oversight of the control environment — reviewing security performance, challenging management on control gaps, and holding leadership accountable for the organization’s security posture.
Required controls: Board charter or equivalent governance documentation, meeting minutes evidencing security oversight discussions, and management reporting to the board on security matters.

CC1.3 — Organizational structure
Reporting lines, authority levels, and accountability for security functions are clearly defined and communicated. Personnel know who is responsible for security decisions and have the authority and resources to fulfill their responsibilities.
Required controls: Organizational chart, job descriptions with explicit security responsibilities, and documented escalation paths for security issues.

CC1.4 — Commitment to competence
The organization hires, trains, and retains personnel with the skills needed to perform security-relevant functions — including pre-employment screening and ongoing security training.
Required controls: Background check records, training completion logs, and security awareness training programme documentation. Training exceptions are among the most common SOC 2 findings — see Common SOC 2 Audit Exceptions.

CC1.5 — Accountability
Personnel are held accountable for their security responsibilities through performance management, access rights tied to role, and consequences for non-compliance with security policies.
Required controls: Performance review process documentation, access rights mapping to roles, and policy violation records.

CC2 — Communication and Information

The communication and information criterion evaluates whether the organization obtains and communicates the security-relevant information needed to support the design and operation of its controls.

CC2.1 — Relevant information
The organization identifies and uses information from external sources — threat intelligence, vulnerability databases, regulatory updates, industry security advisories — to maintain the relevance of its controls in a changing threat environment.
Required controls: Threat intelligence sources documentation, vulnerability management programme records, and evidence of regulatory monitoring activities.

CC2.2 — Internal communication
Security policies, procedures, and changes are communicated internally to the personnel responsible for implementing and operating controls — in a timely manner and in a form they can act on.
Required controls: Policy communication records, security awareness communications log, and evidence of policy update notifications during the observation period.

CC2.3 — External communication
The organization communicates with external stakeholders — customers, vendors, regulators — about security commitments, incidents, and changes that affect those parties’ reliance on the service organization’s controls.
Required controls: Customer-facing security documentation, incident notification procedures, and evidence of external communications related to security matters during the observation period.

CC3 — Risk Assessment

The risk assessment criterion evaluates whether the organization systematically identifies, analyzes, and responds to risks that could prevent it from achieving its security objectives.

CC3.1 — Risk identification process
The organization has a documented, repeatable process for identifying risks to the in-scope system — covering threats, vulnerabilities, and the circumstances that could allow a threat to exploit a vulnerability.
Required controls: Risk assessment methodology documentation, risk register with identified threats and vulnerabilities, and evidence of risk assessment updates during the observation period. A risk register not reviewed or updated during the observation period is a consistent finding in SOC 2 examinations.

CC3.2 — Risk analysis
Identified risks are analyzed to determine their likelihood and potential impact — providing the basis for prioritizing control investments and making risk treatment decisions.
Required controls: Risk scoring documentation, risk ranking records, and evidence of risk treatment decisions.

CC3.3 — Fraud risk assessment
The organization explicitly considers the risk of fraud in its risk assessment — including misappropriation of assets, financial statement fraud, and unauthorized system access for fraudulent purposes.
Required controls: Fraud risk section of the risk assessment, segregation of duties controls for high-risk functions, and evidence of fraud awareness in the control environment.

CC3.4 — Change impact assessment
When significant changes occur — new products, infrastructure migrations, personnel changes, regulatory developments — the organization assesses the impact on the risk profile and updates controls accordingly.
Required controls: Change impact assessment documentation, evidence of risk register updates following significant changes, and security review records for new product launches or infrastructure changes.

CC4 — Monitoring Activities

The monitoring criterion evaluates whether the organization continuously evaluates the effectiveness of its controls — identifying deficiencies, communicating them to responsible parties, and taking corrective action.

CC4.1 — Ongoing monitoring
The organization performs ongoing monitoring activities — internal control reviews, automated monitoring, management oversight — to assess whether controls are operating effectively throughout the observation period.
Required controls: Internal audit or self-assessment records, management review documentation, and evidence of ongoing control monitoring activities.

CC4.2 — Evaluating and communicating deficiencies
Control deficiencies identified through monitoring are evaluated, communicated to responsible parties, and remediated within defined timeframes.
Required controls: Deficiency tracking records, management communication records for identified deficiencies, and evidence of remediation actions.

CC5 — Control Activities

The control activities criterion evaluates whether the organization has implemented the policies and procedures needed to address identified risks — and whether those policies and procedures are designed to operate effectively at the appropriate level of detail.

CC5.1 — Controls to address risks
The organization has selected and developed control activities that address the risks identified through the CC3 risk assessment process — ensuring that every significant risk has a corresponding control designed to mitigate it.
Required controls: Risk-to-control mapping documentation, evidence that controls have been designed to address specific identified risks, and periodic review of the adequacy of the control portfolio.

CC5.2 — Technology controls
The organization has implemented technology-based controls — automated access controls, logging, monitoring systems, configuration management tools — that support the reliability and consistency of control operation.
Required controls: Technology control inventory, configuration documentation, and evidence of automated control operation during the observation period.

CC5.3 — Policies and procedures
The organization has documented policies and procedures for all significant control activities — reviewed and updated to reflect changes in the control environment. See SOC 2 Policies and Procedures for a full breakdown of required documentation.
Required controls: Policy inventory, last review and approval dates, evidence of periodic policy reviews, and version control records.

CC6 — Logical and Physical Access Controls

CC6 is the most operationally intensive Common Criteria category and the most common source of SOC 2 exceptions. It governs every aspect of how access to systems and data is managed — from provisioning through review through removal.

CC6.1 — Least privilege and need-to-know access
Access to systems and data is provisioned based on the principle of least privilege — users receive only the access necessary for their job functions, and access requests require formal approval before provisioning occurs.

CC6.2 — Timely deprovisioning
Access is removed promptly when personnel leave the organization or change roles — within the timeframe defined in the access management policy.

CC6.3 — Periodic access review
All user access is reviewed periodically to identify and remove accounts that are no longer authorized — including accounts belonging to personnel who have changed roles, accounts with excessive privileges, and inactive accounts.

CC6.6 — Physical access restrictions
Physical access to systems and data is restricted to authorized personnel through badge access systems, visitor management procedures, and physical security monitoring.

CC6.7 — Transmission security
Data transmitted externally is protected through encryption — with encryption standards documented and enforced consistently across all external transmission channels.

CC6.8 — Malware prevention
Controls are in place to prevent or detect malware on systems that process in-scope data — including endpoint protection, email security filtering, and network security controls.

For the full breakdown of CC6 control testing and common exceptions, see SOC 2 Controls and Common SOC 2 Audit Exceptions.

CC7 — System Operations

CC7 addresses the ongoing operational security disciplines that keep the in-scope system secure and resilient throughout the observation period.

CC7.1 — System monitoring
The organization monitors the in-scope system continuously for security events, performance issues, and anomalous activity — with alerts configured to notify responsible personnel when defined thresholds are exceeded.

CC7.2 — Security event evaluation
Security events detected through monitoring are evaluated promptly to determine whether they constitute incidents requiring a formal response.

CC7.3 — Incident response
Identified incidents are handled according to a documented incident response procedure — with defined steps for containment, eradication, recovery, and post-incident review.

CC7.4 — Problem management
Identified problems affecting the in-scope system are tracked, investigated, and resolved — with root cause analysis conducted for significant problems to prevent recurrence.

CC7.5 — Breach disclosure
The organization has procedures for disclosing security breaches to affected parties within the timeframes required by applicable legal and contractual obligations.

CC8 — Change Management

CC8.1 — Change management process
All changes to the in-scope system are managed through a documented change management process that requires approval before deployment, testing in a non-production environment, and documentation in the change management system. Emergency changes are subject to expedited approval and retroactive documentation within a defined timeframe.
Required controls: Change management policy, change request and approval records for all production changes during the observation period, test evidence, and post-implementation review records.

CC9 — Risk Mitigation

CC9.1 — Vendor risk management
Third-party providers that perform functions relevant to the in-scope system are assessed for security risk — at onboarding and periodically thereafter — with security requirements embedded in vendor contracts and evidence of ongoing vendor oversight maintained.

CC9.2 — Business continuity
The organization has documented business continuity and disaster recovery plans that address the resumption of in-scope services following significant disruptions — tested periodically to verify that they would function as designed.

How the Common Criteria Support Additional Trust Services Criteria

Availability relies on CC7 (monitoring, incident response) and CC9 (business continuity) as its operational backbone. The Availability-specific controls (A1 series) extend these foundations to address uptime commitments, capacity management, and recovery testing specifically.

Confidentiality relies on CC6 (access controls, transmission security) and CC5 (policies governing confidential data handling) as its foundation. The Confidentiality-specific controls (C1 series) extend these to address data classification, confidentiality agreements, and secure disposal.

Processing Integrity relies on CC8 (change management, preventing unauthorized modifications to processing logic) and CC7 (monitoring for processing errors and anomalies). The Processing Integrity-specific controls (PI1 series) extend these to input validation, output reconciliation, and error correction.

Privacy relies on CC6 (access controls for personal data systems), CC7 (monitoring for unauthorized personal data access), and CC5 (policies governing personal data handling). The Privacy-specific controls (P1–P8 series) extend these to consent management, data subject rights, and privacy-specific security controls.

For the full breakdown of all five criteria, see SOC 2 Trust Services Criteria.

Begin Your SOC 2 Engagement with CertPro CPA LLC

CertPro CPA LLC is a licensed CPA firm that conducts SOC 2 examinations under AICPA AT-C Section 205. Our readiness assessment process maps your existing controls against the full Common Criteria framework — identifying gaps and building a remediation plan that positions your organization for a clean examination outcome.

Explore the full SOC 2 hub for detailed guidance on every aspect of the SOC 2 process.

Ready to begin? Contact CertPro CPA LLC to scope your SOC 2 engagement.

FAQ