SOC 2 Controls List: Complete Reference to Trust Service Criteria and Common Criteria

SOC 2 is built on the AICPA's Trust Service Criteria, a framework that defines the requirements your control environment must satisfy. Unlike prescriptive standards that hand you a checklist of specific technical controls, SOC 2 defines criteria and leaves the design of specific controls to your organization. This reference guide enumerates every criteria category, explains what auditors expect to see in each area, and provides practical guidance on scoping decisions. Bookmark this page as a working reference for your compliance program.

Understanding the Framework Structure

Before diving into the control categories, it is important to understand how SOC 2 is structured. The framework is organized into five Trust Service Criteria categories:

1. Security (required for all SOC 2 engagements)
2. Availability (optional)
3. Processing Integrity (optional)
4. Confidentiality (optional)
5. Privacy (optional)

Security is implemented through the Common Criteria, labeled CC1 through CC9. These nine groups form the backbone of every SOC 2 audit. The additional four categories have their own supplementary criteria that build on top of the Common Criteria foundation.

Each criterion defines a requirement. Your organization designs and implements controls to meet that requirement. A single criterion might be addressed by multiple controls, and a single control might satisfy multiple criteria. The auditor evaluates whether your controls, taken together, adequately address each applicable criterion.

For a conceptual overview of what each Trust Service Category covers and why it exists, see our Trust Service Criteria explainer. This article focuses on providing an enumerated reference you can use during scoping, gap analysis, and audit preparation.

CC1: Control Environment

The control environment establishes the organizational foundation for your entire compliance program. CC1 criteria address governance, accountability, and the tone set by leadership. Auditors evaluate whether your organization has created the structural conditions necessary for controls to operate effectively.

CC1.1 — COSO Principle 1: Commitment to Integrity and Ethical Values

The organization demonstrates a commitment to integrity and ethical values.

What auditors look for:

• Code of conduct or ethics policy distributed to all employees
• Acknowledgment records confirming employees have read and accepted the code
• Evidence that ethical standards are enforced (disciplinary actions for violations)
• Background check procedures for new hires
• Whistleblower or anonymous reporting mechanisms

CC1.2 — COSO Principle 2: Board Independence and Oversight

The board of directors or equivalent oversight body demonstrates independence from management and exercises oversight of internal controls.

What auditors look for:

• Board or advisory board meeting minutes reflecting security oversight
• Defined reporting lines for security and compliance matters
• Evidence of regular briefings to leadership on compliance status
• Independence of oversight function from day-to-day operations

CC1.3 — COSO Principle 3: Management Authority and Accountability

Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in pursuit of objectives.

What auditors look for:

• Organizational chart reflecting security and compliance roles
• Defined responsibilities for control owners
• Job descriptions for security-relevant positions
• Clear escalation paths for security incidents

CC1.4 — COSO Principle 4: Competence and Accountability

The organization demonstrates commitment to attract, develop, and retain competent individuals aligned with objectives.

What auditors look for:

• Security awareness training program with completion records
• Role-specific training for security-critical positions
• Performance evaluation criteria that include security responsibilities
• Onboarding procedures that address security expectations
• Defined consequences for policy violations

CC1.5 — COSO Principle 5: Accountability for Internal Controls

The organization holds individuals accountable for their internal control responsibilities in pursuit of objectives.

What auditors look for:

• Documented control ownership assignments
• Regular control effectiveness reviews by management
• Accountability mechanisms for control failures
• Performance metrics tied to control operation

CC2: Communication and Information

CC2 criteria address how your organization generates, uses, and communicates information necessary for internal controls to function. This includes both internal communication with employees and external communication with customers, vendors, and regulators.

CC2.1 — COSO Principle 13: Quality Information

The organization obtains or generates and uses relevant, quality information to support the functioning of internal controls.

What auditors look for:

• Logging and monitoring systems that capture relevant security events
• Defined data quality standards for compliance-relevant information
• Automated evidence collection from source systems
• Dashboards or reports that surface control status to management

CC2.2 — COSO Principle 14: Internal Communication

The organization internally communicates information, including objectives and responsibilities for internal controls, necessary to support the functioning of internal controls.

What auditors look for:

• Policy distribution and acknowledgment processes
• Regular security communications to staff (newsletters, updates, all-hands)
• Incident communication procedures
• Change management notifications
• New employee security orientation materials

CC2.3 — COSO Principle 15: External Communication

The organization communicates with external parties regarding matters affecting the functioning of internal controls.

What auditors look for:

• Customer-facing security documentation (trust center, security pages)
• Incident notification procedures for customers
• Regulatory reporting mechanisms
• Vendor communication channels for security issues
• System status and availability communications

CC3: Risk Assessment

CC3 criteria require your organization to identify and assess risks that could prevent you from achieving your service commitments and system requirements.

CC3.1 — COSO Principle 6: Specify Objectives

The organization specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.

What auditors look for:

• Documented service commitments and system requirements
• Defined security objectives aligned with Trust Service Criteria
• Measurable performance targets for security controls

CC3.2 — COSO Principle 7: Identify and Analyze Risks

The organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.

What auditors look for:

• Formal risk assessment process conducted at least annually
• Risk register documenting identified risks, likelihood, and impact
• Consideration of internal and external risk factors
• Assessment of risks related to technology changes, personnel, and vendors
• Risk assessment covering all in-scope Trust Service Criteria

CC3.3 — COSO Principle 8: Assess Fraud Risk

The organization considers the potential for fraud in assessing risks to the achievement of objectives.

What auditors look for:

• Fraud risk considerations within the risk assessment process
• Assessment of incentives and pressures that could lead to fraudulent activity
• Evaluation of opportunities for unauthorized access or manipulation
• Segregation of duties analysis

CC3.4 — COSO Principle 9: Identify and Assess Changes

The organization identifies and assesses changes that could significantly impact the system of internal controls.

What auditors look for:

• Change assessment procedures for significant business, technology, and regulatory changes
• Evaluation of control impact when systems or processes change
• Monitoring of external environment for relevant changes
• Documented assessment of how mergers, acquisitions, or reorganizations affect controls

CC4: Monitoring Activities

CC4 criteria require ongoing evaluation of your control environment to ensure controls continue to function as designed.

CC4.1 — COSO Principle 16: Select and Develop Monitoring Activities

The organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal controls are present and functioning.

What auditors look for:

• Continuous monitoring tools and dashboards
• Regular internal control assessments
• Automated alerting for control deviations
• Compliance platform health monitoring
• Management review of control effectiveness metrics

CC4.2 — COSO Principle 17: Evaluate and Communicate Deficiencies

The organization evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors.

What auditors look for:

• Defined process for reporting control deficiencies
• Escalation procedures based on deficiency severity
• Tracking and remediation of identified issues
• Regular reporting to management and the board on control status
• Root cause analysis for significant deficiencies

CC5: Control Activities

CC5 criteria address the selection and development of control activities that mitigate identified risks. This category bridges risk assessment and specific technical and operational controls.

CC5.1 — COSO Principle 10: Select Control Activities

The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.

What auditors look for:

• Controls mapped to identified risks
• Mix of preventive and detective controls
• Technology-specific controls for in-scope systems
• Documentation of control design rationale

CC5.2 — COSO Principle 11: Technology General Controls

The organization selects and develops general control activities over technology to support the achievement of objectives.

What auditors look for:

• Infrastructure security configurations
• Application security controls
• Database access controls
• Network segmentation and firewall rules
• Encryption standards for data at rest and in transit

CC5.3 — COSO Principle 12: Control Activities Through Policies

The organization deploys control activities through policies that establish what is expected and procedures that put policies into action.

What auditors look for:

• Written policies covering all relevant control domains
• Procedures that operationalize policy requirements
• Policy review and update cadence (typically annual)
• Policy exception process with documented approvals
• Evidence that policies are followed in practice

CC6: Logical and Physical Access Controls

CC6 is one of the most testing-intensive areas in a SOC 2 audit. It covers how your organization manages access to systems, data, and physical facilities. For a focused discussion of password and authentication requirements under CC6.1, see our SOC 2 password requirements guide.

CC6.1 — Logical Access Security

The organization implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.

What auditors look for:

• Centralized identity and access management (IdP, SSO)
• Multi-factor authentication on all production and administrative systems
• Password or passphrase policies meeting current standards
• Role-based access control (RBAC) implementation
• Network access controls and segmentation
• Encryption of data in transit (TLS 1.2+) and at rest (AES-256)
• Firewall and security group configurations
• Intrusion detection or prevention systems

CC6.2 — User Registration and Authorization

Prior to issuing system credentials and granting system access, the organization registers and authorizes new internal and external users.

What auditors look for:

• Formal access request and approval workflows
• Documented authorization for access grants
• Principle of least privilege in access provisioning
• Segregation of duties in access approval (requester is not approver)

CC6.3 — Access Modification and Removal

The organization identifies and authenticates system users. Access credentials are removed or modified when no longer needed.

What auditors look for:

• Timely deprovisioning of access upon termination (within 24 hours is a common standard)
• Access modification procedures when roles change
• Periodic access reviews (quarterly or semi-annually)
• Privileged access reviews with enhanced scrutiny
• Service account management and review

CC6.4 — Physical Access Restrictions

The organization restricts physical access to facilities and protected information assets.

What auditors look for:

• Physical access controls at office locations (badge access, visitor logs)
• Data center physical security (if applicable, or reliance on cloud provider controls)
• Environmental controls (fire suppression, climate control, power redundancy)
• Physical access review procedures

CC6.5 — Protection Against External Threats

The organization protects against threats from sources outside system boundaries.

What auditors look for:

• Perimeter security controls (firewalls, WAF, DDoS protection)
• Vulnerability management program
• Penetration testing (annual at minimum)
• Threat intelligence and monitoring
• Security information and event management (SIEM)

CC6.6 — System Boundaries and Entry Points

The organization manages system boundaries and restricts system entry points.

What auditors look for:

• Documented system boundary definitions
• API security controls
• VPN or zero-trust network access for administrative access
• Public-facing service hardening
• Rate limiting and abuse prevention

CC6.7 — Data Transmission Restrictions

The organization restricts the transmission, movement, and removal of information to authorized internal and external users and processes.

What auditors look for:

• Data classification policy
• Data loss prevention controls
• Encryption requirements for data in transit
• Removable media restrictions
• Secure file transfer mechanisms

CC6.8 — Unauthorized or Malicious Software Prevention

The organization implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software.

What auditors look for:

• Endpoint detection and response (EDR) deployment
• Anti-malware on all endpoints
• Application whitelisting or control (where applicable)
• Email security (anti-phishing, anti-spam)
• Software installation restrictions

CC7: System Operations

CC7 criteria address how your organization monitors, detects, and responds to security events that could affect the system.

CC7.1 — Detection of Changes to Infrastructure and Software

The organization uses detection and monitoring procedures to identify changes to configurations and new vulnerabilities.

What auditors look for:

• Vulnerability scanning on a defined cadence (weekly or continuous)
• Configuration monitoring and drift detection
• File integrity monitoring (where applicable)
• Cloud security posture management

CC7.2 — Anomaly Detection and Monitoring

The organization monitors system components and operations for anomalies that are indicative of malicious acts, natural disasters, and errors.

What auditors look for:

• SIEM or centralized log analysis
• Alerting rules for security-relevant events
• Anomaly detection capabilities
• 24/7 monitoring or managed detection and response (MDR)
• Log retention meeting policy requirements (typically 90 to 365 days)

CC7.3 — Security Event Evaluation

The organization evaluates security events to determine whether they could or have resulted in a failure to meet objectives.

What auditors look for:

• Alert triage procedures
• Event classification and severity ratings
• Defined thresholds for escalation to incident response
• Documentation of event evaluations

CC7.4 — Incident Response

The organization responds to identified security incidents by executing a defined incident response process.

What auditors look for:

• Written incident response plan
• Defined roles and responsibilities for incident handling
• Communication procedures (internal and external)
• Evidence of incident response execution for any incidents during the observation period
• Tabletop exercises or simulations if no incidents occurred
• Post-incident review procedures

CC7.5 — Incident Recovery

The organization identifies, develops, and implements activities to recover from identified security incidents.

What auditors look for:

• Recovery procedures and playbooks
• Backup and restore capabilities tested regularly
• Business continuity and disaster recovery plans
• Recovery time and recovery point objectives defined and tested
• Lessons learned incorporated into controls

CC8: Change Management

CC8 criteria cover how your organization manages changes to infrastructure, software, and processes to maintain the integrity of your control environment.

CC8.1 — Change Management Process

The organization authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet objectives.

What auditors look for:

• Formal change management policy and procedures
• Change request and approval workflows (ticketing system)
• Segregation of duties between development and production deployment
• Testing and quality assurance before production release
• Peer code review requirements
• Emergency change procedures with retrospective approval
• Rollback procedures for failed changes
• Change documentation and audit trail

CC9: Risk Mitigation

CC9 criteria address how your organization mitigates risks through business processes, vendor management, and other mechanisms.

CC9.1 — Risk Mitigation Activities

The organization identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions.

What auditors look for:

• Business continuity planning
• Disaster recovery testing
• Insurance coverage assessment
• Risk transfer mechanisms
• Contingency planning for key personnel, vendors, and systems

CC9.2 — Vendor and Business Partner Risk Management

The organization assesses and manages risks associated with vendors and business partners.

What auditors look for:

• Vendor assessment and due diligence procedures
• Vendor risk tiering methodology
• Review of vendor SOC reports or equivalent assessments
• Contractual security requirements (data processing agreements, SLAs)
• Ongoing vendor monitoring and reassessment cadence
• Subservice organization identification and oversight

Availability Criteria (A Series)

The Availability criteria supplement the Common Criteria with additional requirements focused on ensuring system uptime and performance meet service commitments. Include this category if your customers depend on your system's availability and you make contractual commitments around uptime.

A1.1 — Capacity Management

The organization maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and enable the implementation of additional capacity.

What auditors look for: Auto-scaling configurations, capacity monitoring dashboards, capacity planning processes, performance testing results.

A1.2 — Environmental Protections and Recovery

The organization authorizes, designs, develops, implements, operates, approves, maintains, and monitors environmental protections, software, data backup, and recovery infrastructure.

What auditors look for: Backup procedures with defined RPO/RTO, backup testing and verification records, disaster recovery plans, DR testing results, geographic redundancy.

A1.3 — Recovery Plan Testing

The organization tests recovery plan procedures supporting system recovery to meet its objectives.

What auditors look for: Annual (or more frequent) DR testing, documented test results, remediation of issues found during testing, updated recovery procedures based on test outcomes.

Processing Integrity Criteria (PI Series)

The Processing Integrity criteria address the completeness, validity, accuracy, timeliness, and authorization of system processing. Include this category if your service performs calculations, data transformations, or processing where accuracy is critical to your customers.

PI1.1 — Quality Assurance for Processing

The organization implements policies and procedures over system processing to ensure completeness, accuracy, timeliness, and authorization.

What auditors look for: Input validation controls, processing reconciliations, output verification procedures, data quality monitoring, error handling and correction processes.

PI1.2 — System Input Controls

The organization implements policies and procedures over system inputs that result in products, services, and reporting to meet the entity's objectives.

What auditors look for: Input validation rules, authorization of data inputs, error detection at point of entry, data format and range checks.

PI1.3 — Processing Error Detection and Correction

The organization implements policies and procedures to address processing errors identified during processing.

What auditors look for: Automated error detection mechanisms, error logging and tracking, correction procedures, root cause analysis for processing errors, notification procedures for affected customers.

Confidentiality Criteria (C Series)

The Confidentiality criteria address the protection of information designated as confidential. Include this category if you handle proprietary client data, intellectual property, or other information that requires protection beyond standard security measures.

C1.1 — Confidential Information Identification

The organization identifies and maintains confidential information to meet the entity's objectives related to confidentiality.

What auditors look for: Data classification policy, identification procedures for confidential data, labeling or tagging mechanisms, inventory of confidential data repositories.

C1.2 — Confidential Information Disposal

The organization disposes of confidential information to meet the entity's objectives related to confidentiality.

What auditors look for: Data retention and disposal policies, secure deletion procedures, certificate of destruction records, media sanitization processes, disposal verification.

Privacy Criteria (P Series)

The Privacy criteria address personal information collected, used, retained, disclosed, and disposed of by the organization. Include this category if you process consumer personal information and want to demonstrate privacy compliance. Note that SOC 2 Privacy criteria are distinct from regulatory privacy frameworks like GDPR or CCPA, though there is significant overlap.

P1.1 — Privacy Notice

The entity provides notice to data subjects about its privacy practices.

P2.1 — Choice and Consent

The entity communicates choices available to data subjects regarding the collection, use, retention, disclosure, and disposal of personal information.

P3.1 — Collection Limitation

The entity collects personal information only for the purposes identified in the notice.

P3.2 — Collection from Data Subjects

The entity collects personal information by fair and lawful means.

P4.1 — Use Limitation and Data Minimization

The entity limits the use of personal information to the purposes identified in the notice.

P4.2 — Data Retention

The entity retains personal information only as long as necessary to fulfill the stated purposes.

P4.3 — Personal Information Disposal

The entity securely disposes of personal information to meet the entity's objectives related to privacy.

P5.1 — Access to Personal Information

The entity grants data subjects the ability to access their stored personal information for review.

P5.2 — Correction of Personal Information

The entity corrects inaccurate personal information.

P6.1 through P6.7 — Disclosure and Notification

These criteria cover third-party disclosures, cross-border data transfers, breach notification procedures, and related privacy obligations.

P7.1 — Data Quality

The entity collects and maintains accurate, up-to-date, complete, and relevant personal information.

P8.1 — Dispute Resolution

The entity provides a complaint resolution process and remediation.

What auditors look for across the Privacy criteria: Privacy impact assessments, data processing agreements, consent management mechanisms, data subject access request procedures, privacy-by-design practices, data mapping and inventory, cross-border transfer mechanisms (SCCs, BCRs), breach notification procedures, and privacy training for personnel handling personal information.

Scoping Your SOC 2: Which Criteria to Include

Selecting the right Trust Service Criteria is one of the most important decisions in your SOC 2 program. Including unnecessary criteria increases audit scope, cost, and ongoing maintenance burden without proportional value to your customers.

Scoping Decision Framework

Trust Service Category	Include When	Skip When
Security (Common Criteria)	Always required	Never optional
Availability	You make SLA commitments; customers depend on uptime; your service is mission-critical	Your service is not time-sensitive; no SLA obligations
Processing Integrity	Your service performs calculations, financial processing, or data transformations	You provide storage, communication, or workflow tools without critical processing logic
Confidentiality	You handle client IP, trade secrets, or other proprietary information requiring enhanced protection	Standard security controls adequately protect all data you handle
Privacy	You process consumer PII on behalf of customers; customers ask about privacy in questionnaires	You process only B2B business data; customers do not raise privacy requirements

For most B2B SaaS companies, starting with Security and Availability provides the strongest compliance signal with manageable scope. You can add criteria in subsequent audit cycles as customer requirements evolve.

For a complete checklist approach to implementing these controls, see our SOC 2 compliance checklist. For a deeper understanding of what SOC 2 requires beyond the control list, see our SOC 2 compliance requirements guide.