SOC 2 Blog · March 2026
SOC 2 Compliance Checklist: 50 Controls You Need in 2026
Getting ready for a SOC 2 audit requires more than a general understanding of the Trust Services Criteria — it requires knowing exactly which controls you need to implement, what evidence proves each control is operating, and which gaps to close first. This checklist gives you all of that.
Below you will find 50 SOC 2 controls organised by Trust Services Criterion, each with a plain-English description and priority rating. This checklist reflects the controls that auditors consistently test in SOC 2 engagements and that zGovern's pre-built control library covers out of the box. Use it as your gap assessment baseline: for each control, evaluate whether it is fully implemented and evidenced, partially in place, or missing entirely.
Key Takeaways
- SOC 2 is principles-based — you design controls appropriate for your environment rather than following a single prescribed list. This checklist reflects what auditors consistently expect to see.
- The Security criterion (CC series) is mandatory; controls 1–34 are required for every SOC 2 engagement.
- Prioritise Critical controls first — these are most frequently tested and most commonly found deficient.
- A control is only considered implemented when it is both in place technically and evidenced in a way the auditor can verify.
- zGovern maps all 50 of these controls automatically and continuously monitors the technical ones — so you can see your compliance posture in real time, not just before an audit.
How to Use This Checklist
For each control below, assess its current status in your organisation using three categories:
- Implemented and evidenced: The control is in place, operating consistently, and you have documentation or logs that prove it. No action needed.
- Partially implemented: Some aspects of the control are in place but there are gaps — inconsistent enforcement, missing documentation, or incomplete evidence. Remediation needed.
- Missing: The control is not yet in place. This is a gap that must be closed before the audit period begins (for Type 1) or before the observation period ends (for Type 2).
Priority ratings (Critical / High / Medium) reflect how frequently auditors test each control and how significant a finding it generates when missing. Address Critical gaps first.
Security (CC Series) — Required
The Security criterion is mandatory in every SOC 2 engagement. It covers the broadest range of controls and maps to the COSO internal control framework. The 34 controls below represent the core Security requirements that auditors test in virtually every engagement.
CC1 — Control Environment
4 controls
CC1.1
Critical
Information Security Policy
A formal, board- or executive-approved Information Security Policy exists, has been communicated to all employees, and is reviewed at least annually.
CC1.2
High
Organisational Structure and Reporting Lines
Security responsibilities are formally assigned. An individual or team is accountable for information security program management.
CC1.3
High
Code of Conduct and Ethics Policy
A Code of Conduct or Acceptable Use Policy exists and has been acknowledged by all employees, typically during onboarding and at least annually thereafter.
CC1.4
High
Background Checks
Background checks are conducted for all employees with access to production systems or customer data, in accordance with local laws. Records are retained.
CC2 — Communication and Information
3 controls
CC2.1
Critical
Security Awareness Training
All employees complete security awareness training upon hire and at least annually. Completion records are maintained.
CC2.2
Medium
Internal Security Communication
Security updates, policy changes, and incident summaries are communicated to affected personnel. A mechanism exists for employees to report security concerns.
CC2.3
Medium
External Communication of Security Commitments
Your system's security commitments to customers are documented (e.g., in contracts, DPAs, or a public Trust Center) and reflect actual control practices.
CC3 — Risk Assessment
3 controls
CC3.1
Critical
Formal Risk Assessment Process
A documented risk assessment methodology exists and is applied at least annually. Risks are identified, rated by likelihood and impact, and assigned owners.
CC3.2
High
Risk Register Maintenance
A risk register is maintained, reviewed regularly, and updated when new risks are identified or existing risks change in severity.
CC3.3
High
Risk Treatment Decisions
For each identified risk, a treatment decision is documented: accept, mitigate, transfer, or avoid. Mitigation actions have owners and target dates.
CC6 — Logical and Physical Access
8 controls
CC6.1
Critical
Multi-Factor Authentication (MFA)
MFA is enforced for all users accessing production systems, cloud consoles, VPN, and any administrative interfaces. No exceptions without compensating controls.
CC6.2
Critical
Principle of Least Privilege
User access is provisioned according to the minimum permissions required for their role. Over-privileged accounts are identified and remediated.
CC6.3
High
Access Provisioning and Onboarding
A formal process exists for provisioning access to new employees. Access is role-based, approved by a manager, and documented.
CC6.4
Critical
Access Deprovisioning and Offboarding
All access is revoked within 24 hours of employee termination. An offboarding checklist is used and completion records are retained.
CC6.5
Critical
Periodic Access Reviews
User access is reviewed at least quarterly. Reviewers certify appropriateness of access; inappropriate access is revoked. Review records are maintained.
CC6.6
High
Remote Access Controls
Remote access to production systems is restricted and requires MFA and VPN or equivalent network controls. Remote sessions are logged.
CC6.7
High
Privileged Access Management
Privileged and admin accounts are identified, inventoried, and subject to additional controls including just-in-time access where feasible.
CC6.8
Medium
Physical Access Controls
Physical access to systems processing customer data is restricted to authorised personnel. Data centres are third-party facilities with SOC 2 or ISO 27001 certifications.
CC7 — System Operations and Monitoring
6 controls
CC7.1
Critical
Security Event Logging
Security events are logged across production systems including authentication events, privilege escalations, and API calls. Logs are retained for at least 12 months.
CC7.2
Critical
Security Monitoring and Alerting
Automated monitoring is in place to detect anomalous activity, policy violations, and potential security incidents. Alerts are routed to an on-call team.
CC7.3
High
Vulnerability Management
Vulnerabilities are identified through regular scanning (at least quarterly). Critical and high vulnerabilities have defined SLA remediation timelines and are tracked to closure.
CC7.4
Critical
Incident Response Plan
A formal Incident Response Plan documents roles, escalation procedures, communication protocols, and post-incident review requirements. It is tested at least annually.
CC7.5
High
Incident Logging and Tracking
All security incidents are logged with severity, detection time, response actions, and resolution. Post-incident reviews are conducted for significant incidents.
CC7.6
High
Endpoint Detection and Response (EDR)
Endpoint protection software is deployed on all company-owned devices. Threats are automatically detected, quarantined, and escalated.
CC8 — Change Management
4 controls
CC8.1
Critical
Change Management Policy
A formal Change Management Policy defines the process for requesting, approving, testing, and documenting changes to production systems.
CC8.2
Critical
Code Review and Approval for Production Deployments
All code deployed to production is reviewed and approved by at least one individual other than the author before deployment. Approval records are maintained (e.g., GitHub PR reviews).
CC8.3
High
Separation of Development and Production Environments
Development, staging, and production environments are logically separated. Customer data does not flow into development or staging environments without explicit controls.
CC8.4
Medium
Emergency Change Procedures
A defined process exists for emergency changes that bypass normal approval workflows. Emergency changes are documented and subject to post-implementation review.
CC9 — Risk Mitigation and Vendor Management
4 controls
CC9.1
Critical
Vendor Risk Assessment
All critical and high-risk vendors are assessed for security posture before engagement and at least annually thereafter. Assessment records are retained.
CC9.2
High
Vendor Contractual Security Requirements
Vendor contracts include data processing agreements (DPAs), security obligations, breach notification requirements, and the right to audit where applicable.
CC9.3
High
Vendor Inventory
A current inventory of all vendors with access to customer data or production systems is maintained, including their data access scope and risk tier.
CC9.4
High
Business Continuity and Disaster Recovery Plan
A BCP/DR plan documents recovery time objectives (RTOs) and recovery point objectives (RPOs) and is tested at least annually. Backup and restoration procedures are documented.
Availability (A Series) — Optional
Include the Availability criterion if your customers rely on your service availability or if you have SLA commitments. These 6 controls reflect what auditors test when Availability is in scope.
A1 — Availability Controls
6 controls
A1.1
High
Capacity Planning
Current and projected capacity is monitored. Capacity increases are planned and implemented before limits are reached. Auto-scaling or equivalent controls are in place.
A1.2
Critical
Uptime and Performance Monitoring
Real-time monitoring of system availability and performance metrics is in place. Alerts notify the on-call team when availability or latency thresholds are breached.
A1.3
Critical
Backup and Restoration Procedures
Data backups are performed at defined intervals (minimum daily for production data). Backup restoration is tested at least annually and test results are documented.
A1.4
High
Incident Response for Availability Events
The Incident Response Plan covers availability incidents including system outages, DDoS attacks, and cloud provider failures. Escalation and communication procedures are documented.
A1.5
Medium
Environmental Protections
Physical hosting environments (typically cloud data centres) have environmental controls including power redundancy, fire suppression, and physical security. Third-party attestations (e.g., data centre SOC 2) are retained.
A1.6
High
Disaster Recovery Plan and Testing
A disaster recovery plan documents recovery procedures, RTOs, and RPOs. DR tests are conducted at least annually and results — including gaps and remediation actions — are documented.
Confidentiality (C Series) — Optional
Include Confidentiality if your product handles data that customers designate as confidential — trade secrets, financial data, proprietary information, or any data subject to NDA.
C1 — Confidentiality Controls
4 controls
C1.1
High
Data Classification Policy
A Data Classification Policy defines categories of data (e.g., Public, Internal, Confidential, Restricted) and specifies handling requirements for each category.
C1.2
Critical
Encryption of Confidential Data
Confidential data is encrypted at rest (AES-256 or equivalent) and in transit (TLS 1.2+). Encryption key management procedures are documented.
C1.3
High
Access Controls for Confidential Data
Access to confidential data is restricted to personnel with a business need. Access lists are reviewed periodically and access is revoked when no longer needed.
C1.4
Medium
Data Retention and Disposal
Data retention periods are defined and enforced. Confidential data is securely deleted or destroyed when retention periods expire or upon customer request.
Privacy (P Series) — Optional
Include Privacy if your product collects, processes, or stores personal information about individuals. These controls demonstrate a structured privacy management program.
P1–P8 — Privacy Controls
6 controls
P1.1
High
Privacy Notice and Consent
A clear privacy notice discloses how personal information is collected, used, retained, and shared. Consent mechanisms are implemented where required by applicable law.
P2.1
High
Choice and Opt-Out Mechanisms
Individuals can opt out of non-essential processing activities. Opt-out requests are honoured within a defined timeframe and records are maintained.
P4.1
High
Data Subject Access and Correction Rights
A process exists for individuals to request access to, correction of, or deletion of their personal information. Requests are fulfilled within regulatory timeframes.
P5.1
Medium
Retention and Disposal of Personal Information
Personal information is retained only as long as necessary for the purposes for which it was collected. Disposal procedures ensure personal information is securely deleted.
P6.1
High
Disclosure to Third Parties
Personal information is disclosed to third parties only for stated purposes or as required by law. Third-party processors are subject to data processing agreements.
P8.1
Critical
Privacy Incident Response
A process exists to identify, contain, and notify affected individuals and regulators of privacy incidents in accordance with applicable laws (GDPR 72-hour notification, CCPA, etc.).
Running Your Gap Assessment
A gap assessment translates this checklist into an actionable remediation plan. Here is how to structure the process:
- Assign ownership: For each control, identify the person responsible for its implementation and ongoing operation. Unowned controls are a red flag in audits.
- Rate current status: Mark each control as Implemented, Partial, or Missing. Be honest — auditors will find the gaps you are not.
- Identify evidence gaps: For implemented controls, confirm you have evidence. A control that is operating but not evidenced is treated as missing by auditors.
- Prioritise by risk: Address Critical gaps before High before Medium. Use zGovern's risk register to track each gap as a risk item with an owner and target resolution date.
- Set a readiness date: Based on gap count and remediation velocity, project when all Critical and High gaps will be closed. That is your earliest viable audit start date.
zGovern automates much of this process. When you connect your integrations, zGovern immediately surfaces control gaps from your live infrastructure — no manual checklist required for the technical controls. The control library in zGovern maps directly to the AICPA Trust Services Criteria, so every gap you see in zGovern corresponds to a real audit requirement.
Conclusion
SOC 2 compliance is not a mystery — it is a well-defined set of controls that auditors test in a predictable way. The checklist above covers the 50 controls that matter most in 2026 SOC 2 engagements, organised so you can immediately identify gaps and prioritise remediation work.
The key to an efficient SOC 2 program is not checking controls off a list once — it is monitoring them continuously so gaps surface in real time rather than during audit fieldwork. zGovern's continuous monitoring platform does exactly that: it maps your controls, monitors your infrastructure every 6 hours, and alerts you when gaps emerge, so your compliance posture is always visible and your next audit requires minimal emergency preparation.