# 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**](/content/wp-content/uploads/2026/01/SOC-2-Controls-List-PDF.pdf)

## Table of Contents

01. [What Are SOC 2 Controls?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-0/index.html)
02. [What Is the Difference Between SOC 2 Controls, Criteria, and Points of Focus?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-1/index.html)
03. [SOC 2 Controls List](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-2/index.html)
04. [What Are the Five SOC 2 Control Categories?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-3/index.html)
05. [What Are the SOC 2 Common Criteria CC1 to CC9?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-4/index.html)
06. [Which SOC 2 Controls Are Hardest to Automate?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-5/index.html)
07. [What Changed for SOC 2 in 2026?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-6/index.html)
08. [How Many Controls Are in SOC 2?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-7/index.html)
09. [Which SOC 2 Controls Fail Most Often in Audits?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-8/index.html)
10. [What Evidence Do Auditors Request for SOC 2 Controls?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-9/index.html)
11. [How Do SOC 2 Controls Map to Other Frameworks?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-10/index.html)
12. [What Are Complementary User Entity Controls in SOC 2?](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-11/index.html)
13. [How Bright Defense Can Help with SOC 2](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-12/index.html)
14. [FAQs](/content/resources/soc-2-controls-list/#pp-toc-kth1y7v4nile-anchor-13/index.html)

## **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:

- **Multi-Factor Authentication:** Users must provide more than a password when signing in.
- **Access Approval:** An authorized person must approve access before it is given.
- **Access Reviews:** The company regularly checks who has access and removes access that is no longer needed.
- **Employee Offboarding:** The company removes an employee’s access when the employee leaves.
- **Vulnerability Management:** The company looks for security weaknesses and fixes them.
- **Incident Response Testing:** The company practices how it will respond to a security incident.
- **Vendor Reviews:** The company checks whether its vendors follow suitable security practices.
- **Production Change Approval:** Changes to live systems must be reviewed and approved before release.

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](/content/resources/soc-2-requirements/index.html) 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:

- **P1: Notice, 1 criterion**
- **P2: Choice and Consent, 1 criterion**
- **P3: Collection, 2 criteria**
- **P4: Use, Retention, and Disposal, 3 criteria**
- **P5: Access, 2 criteria**
- **P6: Disclosure and Notification, 7 criteria**
- **P7: Quality, 1 criterion**
- **P8: Monitoring and Enforcement, 1 criterion**

Organizations can use this matrix as a starting point when [becoming SOC 2 compliant](/content/resources/how-to-become-soc-2-compliant/index.html). 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:

- Multi-factor authentication and role-based access
- User access approvals, reviews, and timely removal
- Web application firewalls and network protections
- Centralized security logging and alert review
- Physical access restrictions at server facilities
- Background checks for sensitive roles
- Security awareness and phishing training
- Vulnerability scanning and remediation tracking
- Approved and tested system changes
- Incident detection, response, and recovery procedures

### **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:

- Published and regularly reviewed privacy notices
- Documented consent and privacy preference management
- Personal information inventories and classification
- Collection limited to disclosed and approved purposes
- Restrictions on the use of personal information
- Procedures for access, correction, and deletion requests
- Retention schedules and secure disposal procedures
- Approval and documentation of third-party disclosures
- Privacy requirements in vendor agreements
- Privacy complaint handling and compliance monitoring
- Personal information incident response and notification procedures

### **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:

- Data classification and handling policies
- Confidentiality agreements and NDAs
- Role-based access and least-privilege permissions
- Periodic access reviews for confidential data
- Encryption at rest and in transit
- Approved methods for transferring confidential information
- Data loss prevention and download restrictions
- Confidentiality requirements in vendor agreements
- Retention schedules for confidential information
- Verified deletion and physical media destruction

### **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:

- Required-field, format, and range validation
- Duplicate detection and transaction sequence checks
- Authorization requirements before processing
- Automated monitoring of scheduled processing jobs
- Record-count and control-total reconciliations
- Reviews of outputs against expected processing results
- Exception queues and documented error correction
- Procedures for correcting and reprocessing failed transactions
- Approval and testing of changes to processing logic
- Automated alerts and escalation for processing failures

### **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:

- Secure backup procedures
- Disaster recovery plans
- Business continuity plans
- Environmental controls at hosting facilities
- Capacity planning based on usage trends

## **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**

- Promotes integrity and ethical values
- Defines oversight responsibilities
- Assigns authority and accountability

### **CC2: Communication and Information, 3 Criteria**

- Uses relevant and reliable information
- Communicates responsibilities internally
- Supports communication with external parties

### **CC3: Risk Assessment, 4 Criteria**

- Defines suitable objectives
- Evaluates material risks
- Considers fraud and significant changes

### **CC4: Monitoring Activities, 2 Criteria**

- Evaluates whether controls remain present and functional
- Communicates control deficiencies for correction

### **CC5: Control Activities, 3 Criteria**

- Selects activities that address risks
- Applies general controls over technology
- Maintains policies and procedures

### **CC6: Logical and Physical Access Controls, 8 Criteria**

- Authorizes, modifies, reviews, and removes access
- Restricts physical access to protected assets
- Protects systems against unauthorized access and malicious software

### **CC7: System Operations, 5 Criteria**

- Monitors vulnerabilities, configurations, and security events
- Evaluates anomalies and possible incidents
- Responds to and recovers from confirmed incidents

### **CC8: Change Management, 1 Criterion**

- Authorizes, tests, approves, implements, and documents system changes

### **CC9: Risk Mitigation, 2 Criteria**

- Selects responses to business disruption risks
- Evaluates and manages vendor and business-partner risks

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](/content/resources/best-soc-2-compliance-software/index.html) 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 trust services categories included in scope
- The complexity of its systems and infrastructure
- Its risk exposure and regulatory obligations
- Its control design and level of granularity
- Its workforce, vendors, service commitments, and system boundaries

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:

- **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.

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:

- **Access Evidence:** Access approvals, access reviews, MFA settings, and onboarding and offboarding tickets
- **Change Evidence:** Pull-request approvals, test results, deployment logs, and emergency-change records
- **Risk and Vendor Evidence:** Risk registers, treatment records, vendor reviews, contracts, and security reports
- **Security and Resilience Evidence:** Vulnerability reports, incident exercises, backup records, and recovery tests
- **People and Governance Evidence:** Policy approvals, acknowledgments, training records, and oversight minutes

## **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](/content/iso-27001/index.html), 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:

- **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.

Reports commonly list the following CUECs:

- 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 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](/content/resources/soc-2-gap-assessment/index.html), 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.