SOC 2 Controls List for 2026

Starting a SOC 2 program means creating controls that fit your company’s goals, risks, and systems. These controls will vary depending on how your organization operates, the data you handle, and what your customers expect.

SOC 2 is based on five Trust Services Criteria, each tied to a specific type of risk. Knowing which controls apply helps you prepare for audits, handle vendor reviews, and keep your security practices in order.

This post outlines the main types of SOC 2 controls, how they connect to the criteria, and where to begin when building your list.

What Are SOC 2 Controls?

SOC 2 controls are the policies, procedures, and technical measures used to protect systems and data. They reduce the risk of security incidents, mistakes, or unauthorized access.

These controls are based on the SOC 2 Trust Services Criteria, which auditors use as a guide when assessing your organization.

Common examples include password rules, multi-factor authentication, logical access security measures, access permissions, and steps for onboarding and offboarding employees.

Each control supports your overall security program and helps meet the expectations of customers and service organizations.

SOC 2 Controls Definition

What Is The Difference Between SOC 2 Controls, Criteria, And Points Of Focus?

SOC 2 criteria define what a company must meet, controls show how the company meets those criteria, and points of focus guide control design, implementation, and assessment.

The SOC 2® – SOC for Service Organizations: Trust Services Criteria are the formal requirements used in SOC 2 examinations for Security, Availability, Processing Integrity, Confidentiality, and Privacy. They include nine Common Criteria series, CC1 through CC9, plus additional criteria for the other Trust Services Categories in scope.

Controls vary by organization. Two companies can meet the same criterion with different control sets based on their systems, risks, service commitments, and audit scope. Points of focus are not separate controls, and they do not require one-to-one control mapping. A practical SOC 2 controls matrix links each criterion to control owners, evidence sources, and testing cadence.

SOC 2 Controls List

The SOC 2 controls framework is built around five Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. These controls guide how a company protects systems and data and form the core of what auditors evaluate during a SOC 2 examination.

SOC 2 Controls List

1. Security Controls

Security is the foundation of SOC 2. This category focuses on strong operational practices and defenses against both digital and physical threats. Controls in this section often include multi-factor authentication, web application firewalls, physical and virtual measures, and physical safeguards at server facilities.

Auditors also review indirect controls, such as hiring policies for security roles, to assess whether the organization has built the right environment for protecting confidential information.

SECURITY CONTROLS

Examples include:

• Multi-factor authentication
• Web application firewalls
• Detection and monitoring procedures for unauthorized activity
• Physical safeguards for server rooms
• Hiring and background checks for staff in sensitive roles
• Security awareness training for all employees

2. Privacy Controls

Privacy controls apply to the personal information a company collects, uses, retains, discloses, and disposes of. Organizations must clearly communicate their privacy policies to individuals whose data they store.

SOC 2 Privacy Controls

These controls typically require organizations to:

• Obtain consent before collecting data
• Limit data collection to what is necessary
• Collect data through lawful methods
• Use data only for the purpose stated
• Dispose of data once it is no longer needed, following internal compliance process requirements
• Maintain documentation as part of internal control responsibilities

3. Confidentiality Controls

Confidential data often needs to be shared with trusted parties, for example, contract terms exchanged with a business partner under NDA, or source code shared with a development vendor.

Controls focus on classifying confidential data, limiting unauthorized access, and securely disposing of it after a defined retention period. These safeguards help maintain trust services principles and support compliance efforts.

Confidentiality Controls

The goal of confidentiality controls is to allow secure sharing without exposing unauthorized users to that data.

Typical controls:

• Data classification policies
• Role-based access permissions
• Use of encryption at rest and in transit
• Secure disposal processes for confidential information
• Retention schedules for confidential data

4. Processing Integrity Controls

These controls address whether systems perform as intended. They focus on the accuracy, completeness, and reliability of system processing, especially when large volumes of data are ingested, processed, and exported. Effective controls confirm that inputs and outputs match and that no data is lost or altered during processing.

soc-2-processing-integrity-control

SOC 2 Processing Integrity Controls

Examples include:

• Timely error detection and correction during periods of high processing demand
• Input validation and sanity checks
• Monitoring data pipelines to verify inputs and outputs match expected results
• Reconciling processed data through automated checks and reporting
• Controls that prevent unauthorized system components’ logic changes
• Automated alerts for processing failures

5. Availability Controls

Availability controls aim to reduce downtime and maintain reliable service delivery. These are critical for SaaS platforms and cloud providers. This category also involves input from senior management when defining acceptable recovery objectives and allocating resources.

soc-2-availability-controls-explained

Typical controls include:

• Secure backup procedures
• Disaster recovery plans
• Business continuity plans
• Environmental risk management assessments
• Predictive capacity planning as part of a formal readiness assessment

Control Categories in SOC 2

SOC 2 controls are also grouped into functional categories that support the five TSCs. These include:

1. Control Environment (CC1)

• Encourages ethical behavior and integrity
• Involves senior leadership and the board in oversight
• Assigns clear responsibilities for controls

2. Communication and Information (CC2)

• Documents policies and procedures clearly
• Communicates data-handling expectations to staff and third parties
• Shares incident updates and risk alerts on time

3. Risk Assessment (CC3)

• Regularly evaluates new risks to security and compliance
• Identifies internal and external threats
• Considers the impact of system changes or new services

4. Monitoring Activities (CC4)

• Tracks control performance over time
• Flags control failures or policy violations
• Shares findings with stakeholders

5. Control Activities (CC5)

• Deploys policies and procedures that put management directives into action
• Selects controls that address the risks surfaced during risk assessment
• Applies controls across technology, processes, and personnel

6. Logical and Physical Access Controls (CC6)

• Manages user credentials and system permissions
• Uses strong authentication methods
• Restricts physical access to hardware

7. System and Operations Controls (CC7)

• Logs security events and monitors for anomalies
• Responds to system incidents
• Maintains change logs and version control

8. Change Management Controls (CC8)

• Requires documented approvals for all code or system changes
• Tests updates in a staging environment
• Tracks who made changes and when

9. Risk Mitigation Controls (CC9)

• Supports recovery from business disruptions
• Maintains vendor risk assessment practices
• Includes monitoring and contract terms for third-party vendors

Common Criteria (CC-Series)

The Security category includes nine Common Criteria series (CC1–CC9) containing 33 criteria in total, and these apply whenever any category is in scope.

• 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

Each criterion represents a layer of control maturity and helps shape an auditor’s opinion on whether your environment meets SOC 2 standards.

Which SOC 2 Controls Are Hardest To Automate?

The hardest SOC 2 controls to automate are the ones that depend on human judgment, documented review decisions, approvals, or live exercises instead of a simple system-state check. SOC 2 is risk-based rather than checklist-based, and many controls still require uploaded evidence rather than continuous monitoring, which limits full automation.

The controls below usually create the most manual work.

1. Risk Assessment Controls

These controls require a completed risk assessment, a treatment plan, assigned owners, remediation tracking, and periodic review. Drata highlights that risk outputs directly determine control scope, which ties this process to human evaluation rather than automated signals.

2. Periodic User Access Reviews

These reviews depend on human validation of access rights, role appropriateness, and remediation decisions. Vanta notes that quarterly reviews remain time-intensive for most teams, and evidence typically includes reviewer comments and completed access changes.

3. Vendor Management And Third-Party Reviews

AICPA’s How to Perform Proper Vendor Management paper lists governance, policy, third-party risk assessment reviews, due diligence procedures, evaluation of vendor controls, and ongoing monitoring as core parts of the process. Drata adds that organizations should keep a current vendor inventory with risk ratings and review compliance reports or similar evidence for critical vendors at least annually.

4. Incident Response And Business Continuity Testing

These controls require real exercises and documented outcomes rather than passive monitoring. Evidence typically includes test scenarios, participant records, results, and lessons learned, which ties compliance to executed scenarios rather than system data.

5. Change Management Approvals

Automation can capture commits and deployments, yet approval workflows, testing validation, and exception handling still rely on human decisions. Change management requires authorization, tracking, and approval across the lifecycle, which keeps this control dependent on documented review rather than automated checks.

6. Governance And People Controls

These controls depend on policy review, employee acknowledgment, hiring records, and performance evaluations. Policies need to be formally reviewed and accepted, which ties compliance to organizational processes instead of system telemetry.

A practical rule is that SOC 2 controls are hardest to automate when the auditor needs to see who made a decision, what they reviewed, why they approved it, and what happened next. Even the best SOC 2 compliance software cannot remove the human steps tied to these controls.

How Many Controls Are In SOC 2?

SOC 2 does not define a fixed number of controls because it is based on the Trust Services Criteria rather than a standardized checklist. The framework includes 33 common criteria organized into nine series (CC1 through CC9), plus 28 additional criteria across the Availability, Processing Integrity, Confidentiality, and Privacy categories, for a total of 61 criteria. Each organization maps its own controls to the criteria in scope based on its systems, risks, and audit boundaries.

The total number of controls varies across organizations:

The final count depends on several factors:

1. The Trust Services Categories selected, such as Security, Availability, Confidentiality, Processing Integrity, and Privacy.
2. The complexity of systems and infrastructure.
3. The level of risk and regulatory exposure.
4. Auditor expectations and control granularity.

Most SOC 2 reports focus on the Security category, which contains the core common criteria, and additional categories increase the total control count.

Which SOC 2 Controls Fail Most Often In Audits?

SOC 2 controls often fail when they rely on people to complete reviews, approvals, evidence collection, or follow-up on time.

In a SOC 2 audit, a “failed” control usually means the auditor found an exception, such as missing evidence, late performance, incomplete review, or activity that did not match the control description.

An exception does not automatically fail the whole report.

The auditor documents it, management can provide a response, and the report can still be issued with a qualified or unqualified opinion depending on the severity and pervasiveness of the exception.

The most common SOC 2 control exceptions usually involve:

• Access Reviews: Not completed on time or missing reviewer decisions
• User Access Removal: Not completed promptly after termination or role change
• Change Approvals: Missing, late, or not tied to testing evidence
• Vendor Reviews: Incomplete or not updated during the audit period
• Risk Assessments: Missing owners, treatment plans, or review records
• Security Training: Missing records for required employees
• Incident Response and Disaster Recovery Tests: Not performed or not documented
• Vulnerability Management: Open findings without a clear remediation plan

These issues often appear in Type 2 audits since auditors test control operation across the review period.

A control may be well designed, but still produce an exception when one sampled instance is missing approval, evidence, review notes, or remediation records.

The best way to reduce SOC 2 audit exceptions is to assign control owners, collect evidence throughout the audit period, and review gaps before fieldwork begins.

What Evidence Do Auditors Request For SOC 2 Controls?

SOC 2 auditors request evidence that proves each control is designed, assigned, performed, reviewed, and documented during the audit period. For a Type 1 report, auditors review whether controls are suitably designed at a point in time. For a Type 2 report, auditors test whether those controls operated effectively across the full review period.

Common SOC 2 evidence usually falls into five families:

1. Access Evidence: Access review records, MFA settings, onboarding and offboarding tickets
2. Change Management Evidence: Change approvals and deployment logs
3. Risk and Vendor Evidence: Risk registers, vendor reviews, and security questionnaires
4. Resilience Evidence: Incident response tests, backup records, and vulnerability scan results
5. People Evidence: Policy approvals, employee acknowledgments, and security training records

For Type 2 reports, auditors test a sample of instances pulled from the audit period rather than every occurrence. The population must be complete before the auditor can rely on the sample.

Strong evidence should show who owned the control, who performed the activity, when it happened, what was reviewed, what decision was made, and what follow-up action was completed.

A practical controls matrix should link each control to its owner, evidence source, and testing cadence so evidence collection stays consistent across the audit window.

How Do SOC 2 Controls Map To Other Frameworks?

SOC 2 controls map to other frameworks when the same control objective supports similar requirements in ISO 27001, NIST CSF 2.0, HIPAA, PCI DSS, and other security programs.

A single control can support multiple frameworks when the scope and testing frequency match.

Common SOC 2 control mappings include:

• Governance Controls: ISO 27001 Clause 5, NIST CSF Govern, and HIPAA security management process
• Access Controls: ISO 27001 access control, NIST CSF Protect, HIPAA access safeguards, and PCI DSS access restrictions
• Risk Assessment Controls: ISO 27001 risk treatment, NIST CSF Identify, HIPAA risk analysis, and PCI DSS Requirement 12
• Vendor Management Controls: ISO 27001 supplier security, NIST CSF supply chain risk, HIPAA business associate oversight, and PCI DSS Requirement 12.8
• Incident Response Controls: ISO 27001 incident management, NIST CSF Respond, HIPAA security incident procedures, and PCI DSS Requirement 12.10
• Business Continuity Controls: ISO 27001 continuity planning, NIST CSF Recover, and HIPAA contingency planning
• Security Monitoring Controls: ISO 27001 logging and monitoring, NIST CSF Detect, and PCI DSS logging requirements
• Change Management Controls: ISO 27001 change control, NIST CSF Protect, and PCI DSS change control

A control mapping does not make the frameworks identical. Each framework has its own scope, wording, evidence expectations, and audit method. The practical goal is to maintain one control library that supports several compliance programs without duplicating the same evidence work.

What Are Complementary User Entity Controls In SOC 2?

Complementary User Entity Controls, or CUECs, are controls that SOC 2 report users must operate on their own side for the report’s control assumptions to remain valid.

The service auditor’s opinion assumes these customer-side controls operate, so the report’s assurance is not complete on the vendor’s controls alone.

Common CUECs include:

• Managing user access after accounts are created
• Removing access when employees leave or change roles
• Using strong passwords and multi-factor authentication
• Reviewing activity reports or security alerts provided through the service
• Configuring integrations, permissions, and data-sharing settings correctly
• Following the service provider’s security and acceptable use requirements

CUECs are different from subservice organization controls. CUECs are the customer’s responsibility to operate, while subservice organization controls belong to the vendor’s downstream service providers. Those subservice controls appear in the SOC 2 report through the carve-out or inclusive method.

CUECs are important during vendor reviews since they explain what the customer must do, not only what the vendor controls. A SOC 2 report may support vendor assurance, but the customer still needs to check the CUEC section and confirm that its own internal controls match those responsibilities.

How Bright Defense Cybersecurity Compliance Can Help With SOC 2

Bright Defense Cybersecurity Compliance helps organizations achieve SOC 2 compliance through a structured support model that covers readiness, control implementation, and audit preparation. The team conducts a SOC 2 gap assessment to identify control deficiencies, develops security controls aligned with SOC 2 criteria, and prepares complete audit documentation with organized evidence.

We guide clients through each phase, including scope definition, policy development, evidence collection, and auditor coordination, which creates a clear and manageable compliance path. CISSP and CISA certified experts provide continuous monitoring, risk assessments, and policy updates so compliance remains active after certification. This approach keeps security practices consistent across operations and supports long-term audit success through practical execution and direct support.

FAQs

What does a SOC 2 controls list mean?

A SOC 2 controls list is the set of controls your organization operates and tests as evidence for the Trust Services Criteria in scope, typically organized in a controls matrix that links each criterion to one or more controls and evidence sources.

Is there one official SOC 2 checklist that every company must follow?

No. SOC 2 uses control criteria (the Trust Services Criteria) rather than a single universal checklist, so the SOC 2 requirements depend on scope, system boundaries, and your service commitments.