Want the score before the checklist? This article is the detailed checklist: eight control areas, evidence lists, common gaps, remediation steps. For the 90-second interactive version that scores you out of 100 and surfaces your top three gaps, use the free SOC 2 readiness assessment tool. Take the tool first if you want to know which sections of this checklist to read first.
A readiness assessment is the work you do before an auditor starts the clock. It surfaces the controls you are missing, the evidence you cannot produce yet, and the policy gaps that will generate exceptions. These eight areas follow the Trust Services Criteria structure and reflect what auditors actually sample in 2026.
2026 context: The Trust Services Criteria are unchanged, but auditor interpretation tightened after the AICPA released supplemental practice guides in November 2025. If your platform uses AI in a customer-facing or data-processing function, expect questions mapped to CC1.4 (documented roles for anyone who can deploy or modify production models), CC3.1 (a risk register that explicitly names prompt injection, training data leakage, and model hallucination), CC6.1 (API and embeddings-store access reviewed quarterly like production database access), and CC7.2 (logged model inputs and outputs with an incident-response process for AI failures). Vanta and Drata both shipped 2026 AI control templates in Q1. If you self-attest, reference NIST AI RMF Govern, Map, Measure, and Manage functions in your control narratives. Separately, continuous evidence has replaced point-in-time collection as the baseline expectation: auditors sample broadly across the full observation window, and gaps in alert review, incident documentation, or vendor reassessment records are visible.
1. Governance and Risk Management
Governance and risk management is where auditors confirm that leadership owns the compliance program, not just the security team. They look for a formal risk assessment methodology, a risk register with named owners, and evidence that management reviews and acts on it at least annually. Without documented executive accountability, every technical control you show them is harder to rely on.
Evidence auditors ask for:
- Board or executive meeting minutes referencing security and risk review
- A current risk register with likelihood/impact ratings and assigned owners
- A RACI or equivalent chart showing who is responsible for each control area
- A formal risk assessment report from within the last 12 months
Common gap: The risk register exists but has not been updated since the last audit; risks added after the observation window started are treated as unaddressed.
2. Security and Access Control
Access control is typically where auditors spend the most time. They want to see that access follows least-privilege, that provisioning and de-provisioning are systematic, and that someone reviews who has what access on a defined schedule. For 2026, embeddings stores, AI API keys, and model deployment roles must appear in access reviews alongside production database permissions. See which controls auditors check first for the typical sampling sequence.

Evidence auditors ask for:
- Access review reports showing reviewer name, date, and per-user approval or removal decision (quarterly cadence is standard)
- MFA enforcement configuration screenshots for all production-system logins
- Terminated-employee access revocation tickets with timestamps
- Privileged access logs for the observation period
Common gap: Access reviews are completed but not retained with the reviewerβs sign-off, making the evidence unpresentable.
3. Data Protection and Encryption
This area covers how your organization classifies, encrypts, and disposes of sensitive data throughout its lifecycle. Auditors want to see that encryption is applied consistently to data at rest and in transit, that key management is documented and tested, and that a data classification policy exists to define what counts as sensitive.

Evidence auditors ask for:
- Data classification policy with defined sensitivity tiers
- Configuration evidence showing TLS 1.2 or higher on all external endpoints
- Key rotation schedule and logs from AWS KMS, Azure Key Vault, or equivalent
- Documented data retention and disposal procedures with destruction records
Common gap: Encryption is implemented but the key rotation schedule is informal or undocumented, leaving auditors unable to verify the control operates consistently.
4. Change Management and Configuration Control
Change management controls confirm that production systems evolve intentionally. Auditors sample a set of recent changes and trace each one from ticket creation through approval, testing, and deployment. They look for separation of duties between the person writing code and the person merging to production, and for evidence that emergency changes follow a documented exception process.
Evidence auditors ask for:
- Change request tickets with approver names, approval dates, and linked test results
- CI/CD pipeline configuration showing required peer review before merge to main
- A documented emergency change procedure with post-implementation review requirements
- Configuration baseline documents and a record of any deviations
Common gap: Developers with merge permissions also have direct production push access, collapsing the separation of duties the control depends on.
5. Monitoring, Logging, and Incident Response
Detection and response capabilities are audited as a system, not as individual tools. Auditors want to see that logs are collected from all critical systems, that alerts are reviewed on a documented schedule, and that your incident response plan has been tested. They sample alert review records and incident tickets across the observation window; gaps in daily log review are visible.
Evidence auditors ask for:
- Log source inventory showing all critical systems feeding a central platform
- Alert review records with timestamps and analyst sign-offs for the observation period
- A tested incident response plan with tabletop exercise documentation and dates
- Post-incident review reports for any security events during the audit window
Common gap: The IR plan exists but has never been exercised; auditors treat an untested plan as equivalent to no plan.
For a full list of mapped controls, see the SOC 2 controls list.
6. Vendor and Third-Party Risk Management
Your control environment extends to every vendor with access to your systems or customer data. Auditors sample 5 to 15 vendors from your risk register and ask for the assessment file on each. They also check Section IV of each vendorβs SOC 2 report for Complementary User Entity Controls (CUECs), which are controls the vendorβs audit explicitly requires your organization to implement. If you have not addressed them, you have a gap.
Evidence auditors ask for:
- A vendor inventory with risk-tier classifications (Critical / Elevated / Standard) and last-assessment dates
- SOC 2 Type II reports from all Tier 1 vendors, dated within the last 12 months
- Completed security questionnaires (SIG or CAIQ format) for critical vendors
- Vendor contracts with security, incident notification, and data return or deletion terms
Common gap: SOC 2 reports are collected at onboarding but not refreshed annually; expired reports do not satisfy the continuous-evidence expectation.
For guidance on pulling evidence across all eight areas efficiently, see the SOC 2 evidence collection guide.
7. System and Infrastructure Resilience
The Availability criterion requires you to prove that critical systems can be restored within documented recovery targets. Auditors look for defined RTOs and RPOs, backup configuration evidence, and records of actual recovery tests. Configuration documents and untested plans are not sufficient on their own.

Evidence auditors ask for:
- Documented RTO and RPO for each critical system, approved by management
- Backup configuration screenshots and retention policy documentation
- Recovery test results with dates, testers, timing, and any issues found
- Disaster recovery plan with activation criteria and communication procedures
Common gap: Backups run successfully but recovery has never been tested; auditors cannot rely on a backup that has only been written, never read.
8. Personnel Security and Awareness Training
Auditors review the entire employee lifecycle: background checks at hire, security training completion within a defined window, and access revocation at termination. For SOC 2 Type 2, evidence must accumulate across the full observation period, not just at a point in time before the audit. Training platforms like KnowBe4 or Proofpoint work fine; what matters is what the records prove.
Evidence auditors ask for:
- Training completion records showing each employeeβs name, specific modules completed, date, and quiz score where applicable
- Phishing simulation reports with click rates and report rates over time, plus remediation assignments for anyone who clicked
- Background check policy and confirmation that checks ran for new hires during the observation period
- Onboarding and offboarding checklists with completion sign-offs
Common gap: The training completion window is defined in policy (e.g., 30 days from hire) but logs show employees completing training 60 to 90 days in; the policy and the records contradict each other.
SOC 2 Readiness: 8-Point Comparison
| Assessment | Implementation complexity | Resource requirements | Expected outcomes | Ideal use cases | Key advantages |
|---|---|---|---|---|---|
| Governance and Risk Management | High: organization-wide coordination, executive engagement | Moderate: executive time, governance specialists, documentation | Clear accountability, documented policies, identified governance gaps | SOC 2 readiness, strategic compliance alignment | Foundation for SOC 2 controls; aligns compliance with business objectives |
| Security and Access Control | High: technical integration, legacy system challenges | High: IAM/PAM tools, MFA, ongoing admin effort | Restricted access, audit trails, reduced insider risk | Protecting sensitive systems and identities, enterprise IAM rollouts | Prevents unauthorized access; enables least-privilege enforcement |
| Data Protection and Encryption | Medium to High: encryption deployment and key management | High: HSMs/KMS, crypto expertise, performance overhead | Encrypted data at rest/in transit, compliant handling, reduced disclosure risk | Regulated data environments, customer data protection | Strong protection against data breaches; meets encryption standards |
| Change Management and Configuration Control | Medium: process design, cultural adoption | Moderate: CMDB/tools, process owners, training | Controlled changes, fewer outages, audit-ready change history | DevOps/production systems needing controlled deployments | Prevents untested changes; supports rollback and auditability |
| Monitoring, Logging, and Incident Response | High: SIEM, alerting, SOC processes | High: licensing, log storage, skilled security staff | Rapid detection and response, forensic evidence, lower dwell time | Environments requiring active threat detection and SOC | Enables fast detection/containment; provides compliance evidence |
| Vendor and Third-Party Risk Management | Medium: vendor assessments, contractual controls | Moderate: vendor management resources, tools, legal review | Reduced third-party risk, documented vendor controls, continuity plans | Organizations with multiple cloud/third-party providers | Visibility into vendor controls; mitigates supply-chain risk |
| System and Infrastructure Resilience | Medium to High: DR architectures and testing | High: backup/replication infra, failover sites, test resources | Defined RTO/RPO, validated recovery, improved availability | Services with strict availability and recovery requirements | Ensures continuity and minimizes data loss in disasters |
| Personnel Security and Awareness Training | Low to Medium: program design and deployment | Moderate: training platforms, HR involvement, simulation tools | Improved staff security behavior, training records for audits | All organizations aiming to reduce human risk | Reduces human-caused incidents; builds security-aware culture |
The most common pattern across first-time audits is not that controls are absent, it is that controls exist but the evidence trail has gaps: reviews with no sign-offs, policies that do not match logs, vendors that were assessed once and never again. Close the evidence gaps before the observation window opens.