.svg)
If you are preparing for a SOC 2 audit and trying to understand what CC1.1, CC1.4, or CC6.2 actually mean, you are not alone. The AICPA's Trust Services Criteria document runs 39 pages of formal language rooted in the COSO internal control framework, and translating that into practical security controls takes experience that most teams do not have in-house.
This guide provides the official AICPA definitions for every Common Criteria series (CC1 through CC9), explains what each one means in practice, and covers how the five Trust Services Categories determine your audit scope. It is designed as a reference you can return to during audit prep, control mapping, and evidence collection.
How the Trust Services Criteria Are Organized
The SOC 2 Trust Services Criteria are built on two layers:
Common Criteria (CC1-CC9) apply to every SOC 2 engagement. They are derived from the 17 principles of the COSO Internal Control - Integrated Framework (2013), with supplemental criteria added by the AICPA for technology-specific areas like logical access, system operations, and change management. The nine CC series cover:
- CC1: Control Environment
- CC2: Communication and Information
- CC3: Risk Assessment
- CC4: Monitoring Activities
- CC5: Control Activities
- CC6: Logical and Physical Access Controls
- CC7: System Operations
- CC8: Change Management
- CC9: Risk Mitigation
Category-Specific Criteria apply only when you include additional Trust Services Categories beyond Security. These are the A series (Availability), PI series (Processing Integrity), C series (Confidentiality), and P series (Privacy).
The Security category consists solely of the Common Criteria. For any other category you include, your audit covers both the Common Criteria and that category's specific criteria.
For a deeper dive into choosing which categories to include, see our SOC 2 scoping guide and our breakdown of the five Trust Services Categories.
Control Environment
COSO Principles 1-5 · The foundation: integrity, oversight, accountability, competence, and enforcement.
Commitment to Integrity and Ethical Values
The entity demonstrates a commitment to integrity and ethical values. This covers tone at the top, establishing standards of conduct, evaluating adherence, and addressing deviations. Your auditor is looking for a code of conduct or acceptable use policy, evidence that employees acknowledge it (typically during onboarding), and a mechanism for reporting violations. For companies with contractors and vendor staff, those individuals need to be covered by the same standards.
Typical Evidence
Board Independence and Oversight
The board demonstrates independence from management and exercises oversight of internal controls. This includes establishing oversight responsibilities, applying relevant expertise, and operating independently. For companies without a traditional board, this is where auditors look at advisory board meeting minutes, investor board updates, or documented oversight structures. The key is demonstrating that someone independent from day-to-day operations reviews security and compliance posture periodically.
Typical Evidence
Management Structures and Reporting Lines
Management establishes structures, reporting lines, and appropriate authorities in the pursuit of objectives. This covers organizational design, delegation of authority, and segregation of duties. The AICPA supplemental criteria add that management must consider external parties and security-specific requirements when defining these structures.
Typical Evidence
Commitment to Competence
The entity demonstrates a commitment to attract, develop, and retain competent individuals. This covers hiring practices, competency evaluation, training, and succession planning. Background checks, job descriptions with security responsibilities, security awareness training programs (with completion records), and evidence that technical competency is evaluated. The supplemental points of focus specifically call out considering the technical competency and background of contractors and vendor employees.
Typical Evidence
Accountability for Internal Control
The entity holds individuals accountable for their internal control responsibilities. This covers performance measures, incentive structures, and corrective actions. Documented accountability mechanisms, such as security responsibilities in job descriptions, performance reviews that include security duties, and a process for addressing non-compliance.
Typical Evidence
Communication and Information
COSO Principles 13-15 · How the organization obtains, generates, and communicates information to support internal controls.
Information Quality
The entity obtains or generates relevant, quality information to support internal controls. In practice: evidence that you capture the data needed for security decisions (logs, vulnerability data, threat intelligence). This is where security logging and monitoring architecture becomes directly relevant to SOC 2 evidence.
Typical Evidence
Internal Communication
The entity communicates objectives and responsibilities for internal control to personnel. In practice: security awareness training, documented system boundaries, and a process for employees to report security incidents.
Typical Evidence
External Communication
The entity communicates with external parties regarding matters affecting internal controls. In practice: trust centers, external incident notification procedures, and communicating security objectives to vendors and partners.
Typical Evidence
Risk Assessment
COSO Principles 6-9 · Where the organization identifies and analyzes risks.
Objective Clarity
The entity specifies objectives with sufficient clarity to enable risk identification. In practice: documented security objectives and risk appetite, with sub-objectives for each TSC category in scope.
Typical Evidence
Risk Identification and Analysis
The entity identifies and analyzes risks to determine how they should be managed. The supplemental criteria require inventorying information assets, assessing threats and vulnerabilities (including from vendors), and determining risk treatment. This is not a one-time exercise.
Typical Evidence
Fraud Risk Assessment
The entity considers fraud potential, including insider threats, unauthorized data access, and manipulation of systems. The supplemental criteria add IT-specific fraud risks like privileged access abuse and unauthorized code changes.
Typical Evidence
Change Assessment
The entity assesses changes that could impact internal controls, including changes in technology, vendors, leadership, and regulatory environment.
Typical Evidence
Monitoring Activities
COSO Principles 16-17 · How the organization evaluates whether controls are working.
Ongoing and Separate Evaluations
The entity performs continuous monitoring and periodic evaluations. The AICPA supplemental criteria explicitly list penetration testing, ISO certifications, and internal audits as examples.
Typical Evidence
Deficiency Communication
The entity communicates control deficiencies to responsible parties and tracks corrective action. This connects directly to your ticketing, SLA, and incident response processes.
Typical Evidence
Control Activities
COSO Principles 10-12 · Where the organization selects and deploys controls.
Control Selection and Development
The entity selects controls that mitigate risks identified in CC3. The AICPA expects a mix of manual and automated controls, preventive and detective, with explicit attention to segregation of duties. Controls should be risk-based, not framework-mandated.
Typical Evidence
Technology General Controls
The entity develops controls over technology infrastructure, security management, and technology acquisition and maintenance.
Typical Evidence
Policy Deployment
The entity deploys controls through policies and procedures. Auditors look for policy documents, acknowledgments, and evidence of policy-driven activity (access reviews on schedule, incidents responded to per procedure, changes following the documented process).
Typical Evidence
Logical and Physical Access Controls
AICPA Supplemental · Often the most evidence-intensive area of a SOC 2 audit.
Security Software, Infrastructure, and Architectures
The entity implements logical access security software, infrastructure, and architectures to protect information assets. Points of focus include asset inventory, restricting logical access, authentication, network segmentation, encryption, and key management. SSO/IdP configuration, MFA enforcement, network segmentation, encryption at rest and in transit, firewall rules, and an inventory of information assets. This is the broadest CC6 criterion and typically maps to the largest number of controls.
Typical Evidence
User Registration and Authorization
The entity registers and authorizes new users before issuing system credentials, and removes access when no longer authorized. Points of focus include credential management, access removal, and periodic access reviews. Onboarding and offboarding procedures with evidence (tickets, automated provisioning logs), and periodic access reviews. SOC 2 CC6.2 expects access reviews to happen on a defined cadence, not just when someone remembers. This is one of the criteria where teams consistently struggle because the process exists but the evidence trail does not.
Typical Evidence
Role-Based Access and Least Privilege
The entity authorizes, modifies, or removes access based on roles, responsibilities, and the concepts of least privilege and segregation of duties. RBAC implementation, documented role definitions, periodic reviews of access roles and rules, and evidence that access changes follow an authorization process. When someone changes teams or responsibilities, their access should be reviewed and adjusted.
Typical Evidence
Physical Access Restrictions
The entity restricts physical access to facilities, data center facilities, backup media storage, and other sensitive locations. For cloud-native companies, this often maps to cloud provider SOC 2 reports (CSOCs) covering data center physical security. For companies with on-premises infrastructure, this requires visitor logs, badge access systems, security cameras, and documented access authorization processes.
Typical Evidence
Asset Disposal
The entity discontinues logical and physical protections over assets only after the ability to read or recover data has been diminished and is no longer required. Data sanitization procedures for decommissioned hardware and storage media. Documented processes for identifying assets for disposal and rendering data unreadable before release.
Typical Evidence
Boundary Protection
The entity implements logical access security measures to protect against threats from sources outside its system boundaries. Points of focus include restricting access channels, protecting credentials in transit, MFA for external access, and boundary protection systems (firewalls, IDS). Firewall configurations, intrusion detection/prevention systems, VPN or zero-trust access for remote connections, and MFA for external-facing systems. This is the perimeter defense criterion.
Typical Evidence
Data Transmission Controls
The entity restricts the transmission, movement, and removal of information. Points of focus include DLP, encryption in transit, removable media controls, and mobile device management. TLS/encryption for data in transit, DLP policies (if applicable), controls over USB devices and removable media, and MDM for company devices. The scope of this criterion depends heavily on your data flows and what your customers have committed to in their agreements.
Typical Evidence
Malware Prevention
The entity implements controls to prevent, detect, and act upon unauthorized or malicious software. Points of focus include restricting software installation, change detection, antivirus/anti-malware, and scanning external assets. Endpoint protection (EDR/antivirus), application whitelisting or installation restrictions, software change detection, and procedures for scanning assets received from external sources.
Typical Evidence
System Operations
AICPA Supplemental · Vulnerability management, security monitoring, incident detection, incident response, and recovery.
Vulnerability and Configuration Management
The entity uses detection and monitoring procedures to identify configuration changes that introduce vulnerabilities and susceptibilities to newly discovered vulnerabilities. Points of focus include configuration standards, infrastructure monitoring, change detection, vulnerability scanning, and detection of unauthorized components. Regular vulnerability scans, defined configuration baselines, file integrity monitoring, and a process for detecting unauthorized changes. This is where your vulnerability management program lives within the SOC 2 framework.
Typical Evidence
Security Event Monitoring
The entity monitors system components for anomalies indicative of malicious acts, natural disasters, and errors. Points of focus include detection policies and tools, anomaly analysis filters, and monitoring detection tool effectiveness. SIEM or log aggregation, alerting rules, and a process for analyzing anomalies to determine whether they represent security events. The AICPA expects detection measures designed to identify compromise attempts, unauthorized access, credential misuse, and unauthorized hardware or software.
Typical Evidence
Security Event Evaluation
The entity evaluates security events to determine whether they could or have resulted in a failure to meet objectives (security incidents). A triage process for evaluating detected events: classifying severity, determining impact, and deciding response actions. For Privacy-scoped audits, this includes assessing the impact on personal information and determining whether personal data was disclosed.
Typical Evidence
Incident Response
The entity responds to identified security incidents by executing a defined incident-response program. Points of focus include assigned roles, containment, threat elimination, restoration, communication protocols, vulnerability remediation, and evaluating response effectiveness. A documented incident response plan with defined roles, containment procedures, communication templates, and post-incident review processes. Auditors want evidence that the plan has been tested (tabletop exercises count) and that real incidents were handled according to the plan.
Typical Evidence
Incident Recovery
The entity identifies, develops, and implements activities to recover from security incidents. Points of focus include environment restoration, root cause analysis, implementing preventive changes, improving response procedures, and recovery plan testing. Business continuity and disaster recovery procedures, tested periodically. Root cause analysis for incidents with documented corrective actions. The AICPA specifically expects testing scenarios that consider key personnel unavailability and multiple system component failures.
Typical Evidence
Change Management
Single criterion · Often the most evidence-intensive area for technology companies.
Change Management Process
The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures. This is often the most evidence-intensive criterion for technology companies. For most software teams, it maps directly to the CI/CD pipeline, code review process, and deployment procedures. The AICPA also expects baseline configuration management and a defined process for emergency changes.
Typical Evidence
Risk Mitigation
Single criterion · Business disruption planning, vendor risk, and insurance.
Business Disruption Risk Mitigation
The entity identifies and develops risk mitigation activities for potential business disruptions. This covers BCP/DR planning, vendor risk management, and insurance (cyber liability, E&O). The AICPA expects documented procedures for responding to and recovering from security events that disrupt operations.
Typical Evidence
The Five Trust Services Categories
Every SOC 2 report includes Security (the Common Criteria). The other four categories are included based on your commitments to customers:
| Category | Criteria Series | When to Include |
| Security | CC1-CC9 (Common Criteria) | Always included |
| Availability | A series | Contractual SLAs or public uptime commitments |
| Processing Integrity | PI series | Your product processes data customers rely on for business decisions |
| Confidentiality | C series | Commitments around data classification, retention, or proprietary data handling |
| Privacy | P series | Your organization directly collects personal information from data subjects |
For companies pursuing their first SOC 2, Security-only is often the right starting scope. For detailed scoping guidance, see our SOC 2 scoping guide and Trust Services Categories breakdown.
What Auditors Actually Look For
Understanding the criteria definitions is necessary, but it is not sufficient. The gap between knowing what CC6.2 says and producing evidence that satisfies your auditor is where preparation either works or unravels.
Across engagements, the areas where evidence gaps surface repeatedly are:
CC1 and CC5 (policies and procedures)
Policies exist, but they are generic templates that do not reflect how the organization actually operates. A policy that does not match reality is just paperwork. Auditors compare policy language against observed controls and will flag disconnects.
CC6.2 and CC6.3 (access management)
Access reviews are the single most common evidence gap. The review happens informally, but there is no dated artifact, no record of who approved continued access, and no documentation of what changed as a result. Wire evidence capture into your existing access review process on a defined cadence.
CC7 (incident response and monitoring)
The incident response plan exists but has never been tested. Or it was tested, but the tabletop exercise results were not documented. Monitoring architecture is in place, but alerting rules have never been tuned, so the team is either drowning in noise or missing real signals.
CC8.1 (change management)
The CI/CD pipeline is sophisticated, but there is no documented approval process for changes, or emergency changes bypass all controls with no after-the-fact review. Auditors expect evidence that changes are authorized before deployment and that emergency changes are reviewed retroactively.
The pattern across all of these: teams are often doing real security work but cannot prove it. The evidence trail was never designed. Building that evidence architecture, wiring capture into existing workflows rather than creating parallel compliance processes, is what separates programs that stay continuously audit-ready from those that scramble before every cycle.
Implementation Resources
For a full implementation timeline and roadmap, see our automated roadmap to SOC 2 compliance. For automation strategies, see our SOC 2 compliance automation guide.
Build an Effective Security Program That Makes SOC 2 a Byproduct
Find out where your controls stand today.
Frequently Asked Questions
What are SOC 2 CC1.1, CC1.2, and CC1.4?
CC1.1, CC1.2, and CC1.4 are criteria within the Control Environment series of the SOC 2 Trust Services Criteria. CC1.1 addresses organizational commitment to integrity and ethical values, including codes of conduct and standards for employees and contractors. CC1.2 covers board independence and oversight of internal controls. CC1.4 addresses the organization's commitment to attracting, developing, and retaining competent individuals, including hiring practices, background checks, security training programs, and succession planning.
What are the SOC 2 Trust Services Criteria?
The SOC 2 Trust Services Criteria are control criteria established by the AICPA for evaluating the design and operating effectiveness of controls at service organizations. They consist of nine Common Criteria series (CC1 through CC9) that apply to every SOC 2 audit, plus additional criteria specific to each of the five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. The Common Criteria are aligned with the 17 principles of the COSO Internal Control framework, with supplemental criteria for technology-specific areas.
What is the difference between Common Criteria and Trust Services Categories?
Common Criteria (CC1-CC9) are the baseline criteria that apply to every SOC 2 engagement. They cover control environment, communication, risk assessment, monitoring, control activities, access controls, operations, change management, and risk mitigation. Trust Services Categories (Security, Availability, Processing Integrity, Confidentiality, Privacy) determine the scope of your audit. Security consists solely of the Common Criteria. Each additional category adds its own category-specific criteria on top of the Common Criteria.
What does CC6.2 require for access reviews?
CC6.2 requires that the entity registers and authorizes new users before issuing system credentials, and removes access when users are no longer authorized. The AICPA points of focus include controlling access credentials based on authorization, removing access when appropriate, and reviewing the appropriateness of access credentials on a periodic basis. In practice, this means documented onboarding and offboarding procedures, timely access revocation, and periodic access reviews with dated evidence showing who was reviewed, who approved continued access, and what changes were made.
How many criteria are in each CC series?
CC1 has 5 criteria (CC1.1-CC1.5), CC2 has 3 criteria (CC2.1-CC2.3), CC3 has 4 criteria (CC3.1-CC3.4), CC4 has 2 criteria (CC4.1-CC4.2), CC5 has 3 criteria (CC5.1-CC5.3), CC6 has 8 criteria (CC6.1-CC6.8), CC7 has 5 criteria (CC7.1-CC7.5), CC8 has 1 criterion (CC8.1), and CC9 has 1 criterion (CC9.1). This totals 32 Common Criteria across the nine series. Additional category-specific criteria apply when Availability, Processing Integrity, Confidentiality, or Privacy are included in scope.
What is CC1.4 commitment to competence?
CC1.4 maps to COSO Principle 4: the entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. In a SOC 2 context, this means establishing policies and practices around competency expectations, evaluating competence across the organization and outsourced service providers, providing security training programs, considering the background and technical competency of personnel and contractors, and planning for succession of key roles. Auditors look for evidence of background checks, training completion records, job descriptions with security responsibilities, and competency evaluation processes.
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
About the Author
Ali Aleali, CISSP, CCSP
Co-Founder & Principal Consultant, Truvo Cyber
Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.