SOC 2 Controls List for 2026

SOC 2 Controls List for 2026

Updated: August 31, 2026

SOC 2 controls are the policies, procedures, and technical safeguards a company uses to protect its systems and customer data.

Common examples include multi-factor authentication, access reviews, vendor checks, backups, incident response procedures, and change approvals.

Auditors test these controls against the AICPA criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security, including CC1 through CC9, applies to every examination, while the remaining scope depends on the organization’s services and risks.

Read this 2026 SOC 2 controls list to understand how the controls work, who owns them, and what evidence auditors review.

Download SOC 2 Controls List PDF

Table of Contents

  1. What Are SOC 2 Controls?
  2. What Is the Difference Between SOC 2 Controls, Criteria, and Points of Focus?
  3. SOC 2 Controls List
  4. What Are the Five SOC 2 Control Categories?
  5. What Are the SOC 2 Common Criteria CC1 to CC9?
  6. Which SOC 2 Controls Are Hardest to Automate?
  7. What Changed for SOC 2 in 2026?
  8. How Many Controls Are in SOC 2?
  9. Which SOC 2 Controls Fail Most Often in Audits?
  10. What Evidence Do Auditors Request for SOC 2 Controls?
  11. How Do SOC 2 Controls Map to Other Frameworks?
  12. What Are Complementary User Entity Controls in SOC 2?
  13. How Bright Defense Can Help with SOC 2
  14. FAQs

What Are SOC 2 Controls?

SOC 2 controls are the everyday security steps a company uses to protect its systems and information. Auditors check whether the controls are well designed. For Type 2, they also check whether the controls worked during the review period.

What Are SOC 2 Controls

Here are some common SOC 2 controls and what they mean in simple terms:

Controls vary between organizations. Their design depends on the system boundary, risk assessment, service commitments, technology, workforce, vendors, and trust services categories included in the examination.

What Is the Difference Between SOC 2 Controls, Criteria, and Points of Focus?

SOC 2 controls are the safeguards an organization uses to meet the applicable SOC 2 criteria.

Criteria, in contrast, describe what those controls are expected to achieve.

Points of focus serve a different purpose. They provide explanatory considerations for each criterion. However, they are not separate controls and do not require one-to-one control mapping.

At the framework level, the AICPA Trust Services Criteria cover five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

These include the Common Criteria, CC1 through CC9, plus additional criteria for any other categories included in the examination.

The table below explains each concept separately:

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

Term Meaning Example
SOC 2 Criteria What the controls should achieve CC6 covers logical and physical access
SOC 2 Controls Safeguards used to meet the criteria MFA, access reviews, and employee offboarding
Points of Focus Details that help explain each criterion Checking whether access is approved, limited, reviewed, and removed

Two organizations may use different controls to meet the same criterion. One control can support several criteria, while one criterion may require several controls.

SOC 2 Controls List

Organizations create their own controls to meet the applicable SOC 2 requirements based on their systems, risks, service commitments, and examination scope.

Here is a practical list of example controls for CC1 through CC9:

SOC 2 Common Criteria Controls, CC1 Through CC9

Criterion Example Control Statement Owner Evidence Cadence
CC1.1 Management maintains a code of conduct that employees acknowledge when hired and annually afterward. HR Approved code and signed acknowledgments Annual
CC1.2 The governing body reviews security risks, control performance, and material incidents. Executive Team Meeting minutes and security reports Quarterly
CC1.3 Organizational structures, reporting lines, and assigned security responsibilities are documented and reviewed for current accuracy. Executive Team Organization chart, role descriptions, and review records Annual
CC1.4 Security roles are filled through defined hiring requirements, background screening, and role-based training. HR Job requirements, screening records, and training completion Per Hire
CC1.5 Security responsibilities appear in job descriptions and are evaluated during performance reviews. HR Job descriptions and performance review records Annual
CC2.1 Security policies are approved, published, and communicated to personnel with relevant responsibilities. Security Policies, approvals, and distribution records Annual
CC2.2 Personnel receive security awareness training covering their internal control responsibilities. Security Training content, completion records, and acknowledgments Annual and At Onboarding
CC2.3 Customers and external parties can report security concerns through a documented communication channel. Security Published reporting process and tickets Continuous
CC3.1 Management documents the service commitments and system requirements used as the basis for risk assessment. Compliance System description, commitments, and requirement records Annual
CC3.2 Management performs a documented risk assessment covering internal, external, vendor, and technology risks. Security Risk assessment and risk register Annual and After Material Change
CC3.3 The risk assessment includes fraud scenarios covering unauthorized access, data misuse, and management override. Security Fraud risk analysis within the risk assessment Annual
CC3.4 Significant system, vendor, and organizational changes trigger a documented risk reassessment. Security Change records and updated risk assessments Per Material Change
CC4.1 Control owners review assigned controls and document whether each control operated as written. Compliance Control review records and supporting evidence Quarterly
CC4.2 Control deficiencies are reported to management and the governing body with assigned corrective actions. Compliance Deficiency reports, action plans, and oversight minutes Quarterly
CC5.1 Management selects control activities that address the risks recorded in the risk assessment. Compliance Risk register mapped to the control library Annual
CC5.2 Approved security configuration standards are applied to systems and monitored for unauthorized changes. IT Configuration standards and monitoring results Continuous
CC5.3 Approved policies and supporting procedures define expected behavior and operating steps for each control area. Compliance Policy library, procedures, and approval records Annual
CC6.1 Production access requires centralized authentication and MFA at the identity provider. Security Identity-provider settings and authentication policy Continuous
CC6.2 System access is granted after documented approval and removed promptly when authorization ends. IT Access tickets and identity-provider logs Per Event
CC6.3 System owners review user roles, privileged access, and unnecessary permissions. Security Access review records and change tickets Quarterly
CC6.4 Physical access to facilities and protected assets is restricted to authorized personnel and reviewed periodically. IT Badge records, visitor logs, and access review records Quarterly
CC6.5 Storage media is sanitized or destroyed through an approved disposal process before reuse or disposal. IT Disposal logs and destruction certificates Per Event
CC6.6 Firewalls, endpoint protections, and network monitoring restrict and detect threats outside system boundaries. Security Configurations, alerts, and review records Continuous
CC6.7 Data transmission, movement, and removal are restricted to authorized users and protected through encryption. Security Encryption settings, transfer controls, and endpoint policies Continuous
CC6.8 Managed antimalware or endpoint detection software operates on supported company endpoints and servers. Security Coverage reports and alert records Continuous
CC7.1 Vulnerability scans are performed, findings are prioritized, and remediation is tracked against approved deadlines. Security Scan reports and remediation tickets Monthly
CC7.2 Security logs are centralized and monitored for anomalous or unauthorized activity. Security SIEM settings, alerts, and investigation records Continuous
CC7.3 Security events are evaluated to determine whether they qualify as incidents affecting service commitments. Security Alert triage records and incident determinations Continuous
CC7.4 Security incidents are documented, investigated, contained, and closed according to the incident response plan. Security Incident tickets and investigation records Per Event
CC7.5 Recovery activities following a confirmed security incident are performed, documented, and reviewed with assigned corrective actions. Security Incident recovery records, post-incident reviews, and corrective actions Per Event
CC8.1 Production changes require documented review, testing, approval, and deployment records. Engineering Pull requests, approvals, test results, and deployment logs Per Change
CC9.1 Management evaluates business disruption risks and maintains appropriate continuity measures. Operations Business impact assessment and continuity plan Annual
CC9.2 Critical vendors receive risk reviews before onboarding and throughout the relationship. Compliance Vendor inventory, assessments, contracts, and review records Annual

Additional Category Controls for Availability, Processing Integrity, Confidentiality, and Privacy

The table below covers the Availability, Confidentiality, and Processing Integrity criteria in full, plus one example from the Privacy category. The Privacy category contains 18 criteria across the eight P series listed after the table.

Criterion Example Control Statement Owner Evidence Cadence
A1.1 System capacity and resource usage are monitored against defined thresholds. Engineering Monitoring dashboards and alerts Continuous
A1.2 Backup processes, environmental protections, and recovery infrastructure are maintained for the production environment. IT Backup configurations, job logs, and facility reports Continuous
A1.3 Disaster recovery procedures are tested against approved recovery objectives. IT Recovery test results and action records Annual
C1.1 Confidential information is classified and handled according to approved access and retention rules. Security Data inventory, classifications, and access settings Annual
C1.2 Confidential information is disposed of through approved methods at the end of its retention period. IT Disposal records and retention schedules Per Event
PI1.1 Data definitions, processing specifications, and system documentation are maintained for services covered by processing integrity commitments. Engineering System documentation and data dictionaries Annual
PI1.2 System inputs are validated for required format, authorization, and completeness before processing. Engineering Validation rules, test results, and error logs Per Transaction
PI1.3 Processing runs according to approved specifications, with exception handling and reprocessing controls in place. Engineering Job logs, exception reports, and reprocessing records Continuous
PI1.4 System outputs are reviewed for completeness and accuracy and delivered only to authorized recipients. Engineering Output reconciliations and delivery records Per Transaction
PI1.5 Stored processing data is retained completely and accurately, with backup and retrieval controls protecting the records. Engineering Storage configurations, integrity checks, and retrieval tests Continuous
P8.1 Privacy complaints and inquiries are recorded, investigated, resolved, and reviewed for recurring problems. Privacy Complaint log and resolution records Per Event

The Privacy category contains 18 criteria organized into eight series:

Organizations can use this matrix as a starting point when becoming SOC 2 compliant. Each applicable criterion should connect to at least one documented control, responsible owner, evidence source, and operating frequency.

What Are the Five SOC 2 Control Categories?

The SOC 2 controls framework covers five trust services categories: 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.

Below are the five SOC 2 control categories, what each one covers, and examples of the controls organizations may use to meet the related criteria:

SOC 2 Controls List

1. Security Controls

Security is included in every SOC 2 examination and is evaluated through the 33 Common Criteria organized across CC1 through CC9. These criteria cover the control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation.

Security controls protect information and systems from unauthorized access, use, disclosure, modification, or damage. They include administrative, technical, and physical safeguards that prevent security incidents, detect suspicious activity, and support incident response and recovery.

Auditors examine direct safeguards, such as multi-factor authentication and security monitoring, as well as supporting controls such as assigned responsibilities, employee screening, security training, policy reviews, and management oversight. During a Type 2 examination, auditors test whether the controls operated effectively throughout the examination period.

SECURITY CONTROLS

Examples include:

2. Privacy Controls

Privacy controls apply when an organization includes the Privacy category in its SOC 2 examination. They govern personal information throughout its lifecycle, including collection, use, retention, disclosure, disposal, access, correction, and monitoring.

These controls assess whether the organization handles personal information according to its privacy notices, service commitments, and applicable requirements. Privacy focuses on personal information and related individual rights. Confidentiality covers information that the organization has classified as confidential.

SOC 2 Privacy Controls

Examples include:

3. Confidentiality Controls

Confidentiality controls apply when an organization includes the Confidentiality category in its SOC 2 examination. They protect information that the organization has classified as confidential or committed to hold in confidence. Criterion C1.1 covers the identification and maintenance of confidential information, while C1.2 addresses its disposal.

Confidential information may include contract terms, source code, proprietary designs, financial records, and customer data classified as confidential. The organization may store this information internally or share it with approved parties under an NDA or other contractual agreement.

Controls define how confidential information is classified, accessed, stored, transmitted, retained, and destroyed. They permit authorized use and sharing while protecting the information from unauthorized disclosure throughout its lifecycle.

Confidentiality Controls

Examples include:

4. Processing Integrity Controls

Processing Integrity controls apply when an organization includes the Processing Integrity category in its SOC 2 examination. They assess whether system processing is complete, valid, accurate, timely, and authorized according to the organization’s processing objectives.

These controls cover the full processing cycle, including data input, transformation, output, error handling, and correction. Inputs and outputs do not need to be identical because systems often transform data. Reconciliations confirm that authorized records were processed correctly, expected outputs were produced, and missing, duplicate, delayed, or invalid transactions were detected.

Auditors may examine validation rules, processing logs, control totals, exception reports, reconciliations, error queues, output reviews, and alerts. Controls over changes to processing logic support consistent results after system updates.

soc-2-processing-integrity-control

Processing integrity controls include:

5. Availability Controls

Availability controls apply when an organization includes the Availability category in its SOC 2 examination. The category includes A1.1 through A1.3 and addresses whether information and systems remain available for operation and use according to the organization’s service commitments and system requirements.

SOC 2 does not prescribe a universal uptime percentage, recovery time objective, or recovery point objective. The organization defines these targets based on customer commitments, business needs, and risk. Senior management approves the objectives and provides the personnel, technology, and funding needed to support them.

These controls reduce the likelihood and duration of service disruptions. They cover system monitoring, capacity management, redundancy, backups, environmental protection, incident response, disaster recovery, and recovery testing.

soc-2-availability-controls-explained

Availability controls include:

What Are the SOC 2 Common Criteria CC1 to CC9?

The Security category is expressed through nine series of Common Criteria, CC1 through CC9, containing 33 criteria in total. They apply to every SOC 2 examination, including examinations that add Availability, Processing Integrity, Confidentiality, or Privacy.

CC1: Control Environment, 5 Criteria

CC2: Communication and Information, 3 Criteria

CC3: Risk Assessment, 4 Criteria

CC4: Monitoring Activities, 2 Criteria

CC5: Control Activities, 3 Criteria

CC6: Logical and Physical Access Controls, 8 Criteria

CC7: System Operations, 5 Criteria

CC8: Change Management, 1 Criterion

CC9: Risk Mitigation, 2 Criteria

Auditors test the controls mapped to each applicable criterion. Their opinion addresses whether the controls were suitably designed and, for a Type 2 examination, operated effectively to provide reasonable assurance that the organization met its service commitments and system requirements.

Which SOC 2 Controls Are Hardest to Automate?

The hardest SOC 2 controls to automate are the ones that depend on human judgment, documented approvals, review decisions, or live exercises. Software can collect system data and track evidence, but it cannot complete the human decisions required for these controls.

1. Risk Assessment Controls

Risk assessment controls require management to evaluate threats, business impact, existing safeguards, treatment decisions, and accepted residual risk. Responsible personnel make and approve each underlying decision. Compliance tooling stores the results and tracks the resulting actions.

2. Periodic User Access Reviews

Access reviews require system owners to evaluate each user’s role, permissions, privileged access, and continued business need. Automated tools produce the user population. Reviewers document each decision and complete the resulting access changes.

3. Vendor Management and Third-Party Reviews

Vendor management under CC9.2 covers governance, third-party risk assessment, due diligence, evaluation of vendor controls, and ongoing monitoring. Organizations maintain a current vendor inventory and retain reviews, contracts, security reports, risk decisions, and follow-up records for critical providers.

4. Incident Response and Business Continuity Testing

Incident response and continuity controls require real exercises with documented outcomes. Evidence includes test scenarios, participant records, results, and lessons learned from each exercise.

5. Change Management Approvals

Change management approvals depend on human decisions at three points: approval workflows, testing validation, and exception handling. Automation captures commits and deployments, and reviewers supply the authorization and approval records that CC8.1 requires across the change lifecycle.

6. Governance and People Controls

Governance and people controls depend on policy review, employee acknowledgment, hiring records, and performance evaluations. Each policy requires a formal review and a recorded acceptance from the personnel it covers.

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.

What Changed for SOC 2 in 2026?

No SOC 2 criteria changed in 2026. The AICPA continues to use the 2017 Trust Services Criteria with revised points of focus from 2022, published as TSP section 100. The criteria were not expanded or renumbered for 2026.

Organizations continue to use the 2018 SOC 2 Description Criteria with revised implementation guidance from 2022, published as DC section 200, when preparing the system description.

No newer version of either document has replaced them.

How Many Controls Are in SOC 2?

SOC 2 does not prescribe a fixed number of controls. The framework contains 33 Common Criteria and 28 additional criteria across Availability, Processing Integrity, Confidentiality, and Privacy, producing 61 criteria when every category is included.

Criteria and controls are different. One control may support several criteria, while one criterion may require several controls. The organization’s control count depends on several factors:

The 33 Common Criteria apply to every SOC 2 examination. Adding other trust services categories increases the number of applicable criteria and may require additional controls.

Which SOC 2 Controls Fail Most Often in Audits?

SOC 2 controls fail most often when they depend on people to complete reviews, approvals, evidence collection, or follow-up on time. A failed control appears in the report as an exception, which results from missing evidence, late reviews, incomplete approvals, unperformed activities, or differences between the written control and its actual operation.

An exception does not automatically produce a modified opinion. The auditor considers its nature, frequency, effect, and relationship to other controls before determining how it affects the report.

Exceptions appear most often in these areas:

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.

Organizations can reduce exceptions through clear control ownership, evidence collection throughout the review period, complete control populations, and internal reviews before audit fieldwork begins.

What Evidence Do Auditors Request for SOC 2 Controls?

SOC 2 auditors request evidence showing that each control was designed, assigned, performed, reviewed, and documented. For a Type 1 report, auditors evaluate whether controls are suitably designed as of a specified date. For a Type 2 report, auditors test whether those controls operated effectively throughout the review period.

For Type 2 reports, auditors test samples from complete and accurate populations covering the review period rather than examine every occurrence.

The sampling method depends on the control’s nature, frequency, and level of automation.

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

The controls matrix should separately record the assigned control owner.

SOC 2 evidence falls into five families:

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.

SOC 2 control mappings include:

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.

Reports commonly list the following CUECs:

CUECs are different from complementary 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 define the customer’s own obligations under the report. The customer should read the CUEC section and confirm that its own internal controls match those responsibilities.

How Bright Defense Can Help with SOC 2

Bright Defense helps organizations prepare for SOC 2 examinations through scoping, readiness assessments, control development, policy work, evidence planning, and audit preparation. The team reviews current practices against the applicable criteria, documents SOC 2 gaps, assigns control owners, and organizes evidence for auditor testing.

Support can cover risk assessments, policy reviews, access controls, vendor management, security monitoring, internal readiness testing, and auditor coordination. Continued control monitoring and evidence collection help organizations maintain control operation after the SOC 2 report is issued.

FAQs

1. What Is a SOC 2 Controls List?

A SOC 2 controls list records the policies, procedures, processes, and safeguards an organization operates to address the Trust Services Criteria included in its examination scope.

2. Does the AICPA Provide a SOC 2 Controls Checklist?

No. The AICPA publishes the Trust Services Criteria, not a universal checklist of prescribed controls. Each organization develops controls based on its systems, risks, scope, service commitments, and system requirements.

3. What Are the SOC 2 Common Criteria?

The Common Criteria contain 33 criteria organized across CC1 through CC9. They form the Security category and apply to every SOC 2 examination.

4. When Are the Other Trust Services Categories Added?

Availability, Processing Integrity, Confidentiality, and Privacy are added to the examination scope when they are relevant to the organization’s services, risks, service commitments, and system requirements.

5. What Should a SOC 2 Controls Matrix Contain?

A useful controls matrix maps each control to the applicable criteria and records its description, owner, frequency, systems or processes in scope, evidence source, and testing status or procedure.

6. How Should an Organization Start Building Its Controls List?

The organization should define its system and examination scope, document its service commitments and system requirements, select the applicable categories, assess relevant risks, and map existing controls to the criteria. It should then document gaps, write clear control statements, and assign control owners and evidence sources.

7. What Should Be Shared When a Customer Requests the Controls List?

The organization should usually provide its current SOC 2 report through a secure process, often under an NDA, instead of releasing its internal controls matrix. A Type 2 report includes the system description, management’s assertion, auditor’s opinion, tests of controls, and test results. A Type 1 report does not cover operating effectiveness over a period.

8. How Often Should SOC 2 Controls Be Tested?

Internal testing frequency should reflect the control’s operating frequency and risk. Automated controls may be monitored continuously, event-driven controls should be reviewed when relevant events occur, and periodic controls may be tested monthly, quarterly, or annually. The service auditor separately determines the nature, timing, and extent of testing for the SOC 2 examination.

9. What Should Customers Check in a Vendor’s SOC 2 Report?

Customers should review the report type, examination date or period, systems and services in scope, Trust Services Categories covered, auditor’s opinion, test exceptions, management responses, subservice organizations, and complementary user entity controls.

10. Can One SOC 2 Control Support Several Criteria?

Yes. One control can support several criteria when its design and operation address each relevant objective. The controls matrix should clearly map the control to every criterion it supports.

11. How Do I Read a SOC 2 Controls List for the First Time?

Start with the criterion reference and control statement. Determine what action the control requires, who performs it, how often it operates, which systems or processes it covers, and what evidence it produces. This approach helps connect the control’s wording with its purpose and the relevant Trust Services Criteria.

12. How Do I Know Which SOC 2 Controls Apply to My Role?

Review the control owner, responsible team, and required activities. A control may apply to you when your role performs an activity, approves a request, reviews information, maintains a system, or provides evidence. The control owner or compliance team should clarify any responsibilities that are not clearly documented.

13. How Can I Tell Whether a SOC 2 Control Is Written Clearly?

A clear control statement describes who performs the activity, what action occurs, which systems or information it covers, how often it operates, and what record it produces. Statements such as “management reviews access” are too vague because they do not specify the reviewer, systems, frequency, or evidence.

14. How Do I Know What Evidence a SOC 2 Control Requires?

The evidence should demonstrate that the control operated as written during the applicable date or examination period. Common evidence includes system logs, screenshots, approval records, access reviews, tickets, reports, meeting minutes, and signed policies. The evidence should show who performed the activity, when it occurred, what it covered, and the result.

15. What Should I Do When Actual Practice Does Not Match the Controls List?

Document the difference and report it to the control owner or compliance team. They should determine whether the control failed, the process changed, or the written description is outdated. The organization can then correct the process or update the control wording, document the decision, and retain evidence of any corrective work. Evidence should never be created or backdated to make an unperformed control appear complete.