SOC 2 Readiness Checklist

What is SOC 2 readiness?

SOC 2 readiness means your organisation's controls and processes are operating effectively and producing evidence that an auditor can independently verify. Developed by the AICPA, SOC 2 (System and Organization Controls 2) evaluates controls relevant to the Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Most organisations pursuing SOC 2 target the Security criterion as a minimum. Additional criteria are included based on contractual requirements or the nature of services delivered to customers. Readiness is not achieved by having policies on paper — auditors assess whether controls are documented, implemented, and consistently operating with supporting evidence.

This checklist covers the six practical control areas that determine whether your organisation is ready to proceed to a SOC 2 Type I or Type II audit. Work through each section, identify gaps, and prioritise remediation before your audit window opens.

Complete SOC 2 readiness checklist

Rate each item: fully implemented, in progress, or not implemented. Items not fully implemented become your remediation backlog.

1 Governance & Risk Management

Security roles and responsibilities are clearly defined and assigned to named individuals
Information security policies have been documented, approved by management, and communicated to all staff
Information security risks are assessed on a defined schedule with documented findings and risk ratings
Management reviews security performance, control effectiveness, and compliance activities with documented outcomes
Security objectives and improvement actions are tracked to completion with named owners and target dates

2 Access Control

Access to systems and data is granted based on documented business need and formal approval
Multi-factor authentication (MFA) is enforced for all critical systems and remote access
User access rights are reviewed on a regular cycle with documented records of reviews and changes made
Access is removed or modified promptly when employees change roles or leave the organisation, with evidence of timely revocation
Privileged and administrative accounts are subject to enhanced controls, monitoring, and periodic recertification

3 Data Protection

Sensitive data is encrypted in transit using current standards (TLS 1.2 or higher) across all external and internal channels
Sensitive data is encrypted at rest in production databases, file stores, and backup media
Data retention and disposal requirements are documented and disposal of customer data is handled according to agreed schedules with records maintained
Customer and confidential information is classified, and access is restricted based on classification level

4 Security Operations

Security and system event logs are collected, stored, and reviewed at a defined frequency with alert thresholds configured
Vulnerability scans are performed at a defined cadence and scan results are documented
Critical and high-severity vulnerabilities are remediated within defined timelines documented in policy, with tracking records available
Endpoint protection (antivirus, EDR, or equivalent) is deployed and actively managed across all company-owned devices
Security incidents are detected, recorded, investigated, and resolved with documented timelines and root cause findings

5 Change & Vendor Management

Changes to production systems follow a documented change management process with review, approval, and rollback procedures
Software releases are tested in a non-production environment and approved before deployment to production
Third-party vendors with access to systems or customer data are assessed for security risk before onboarding
Critical suppliers are reviewed on an ongoing basis and security requirements are included in contractual agreements

6 Business Continuity & Awareness

Backups of critical systems and data are performed on a defined schedule and restoration is tested periodically with documented results
Business continuity and disaster recovery plans are documented, current, and cover the systems and services in scope for the SOC 2 audit
All employees complete security awareness training at onboarding and at least annually, with completion records retained
Incident response procedures are documented and have been tested through a tabletop exercise or live simulation with findings recorded
Evidence demonstrating control effectiveness is consistently collected, retained, and readily retrievable for auditor review

Common SOC 2 readiness mistakes

These are the gaps most frequently identified during SOC 2 readiness assessments and reported as exceptions in audit findings.

Controls exist in policy but are not consistently operating

The most common SOC 2 exception. A policy that states access is reviewed quarterly must be evidenced by dated access review records for every quarter in scope. Auditors test operating effectiveness against documented commitments — intention without evidence generates an exception.

No evidence collection process before the audit window opens

SOC 2 Type II audits cover a defined period — typically three to twelve months. Evidence must exist for the entire period under review. Starting an evidence collection programme after the period closes cannot retroactively satisfy the requirement.

Offboarding without timely access revocation

Auditors sample termination and access revocation records to verify that access was removed within the timeframe stated in policy. Delays between employment end dates and access removal are a common finding, particularly for SaaS tools outside core IT provisioning workflows.

Vendor security not assessed before production access is granted

Subservice organisations and vendors with access to systems or customer data are part of your SOC 2 control environment. Auditors check that vendor risk assessments were completed before access was granted, not added retrospectively when the audit is announced.

Backup restoration not tested

Having a backup schedule is not sufficient. SOC 2 requires evidence that backups can be successfully restored. Untested backups, or backups tested but not documented, leave a gap in availability-related controls that auditors will flag.

Scope defined too broadly relative to available evidence

Organisations sometimes include all systems to appear comprehensive, then cannot produce consistent evidence across every system in scope. A focused, well-evidenced scope passes more reliably than a broad scope with coverage gaps.

SOC 2 Type I vs Type II

SOC 2 offers two report types. Understanding the difference helps you choose the right starting point and plan your audit timeline.

Type I — Design at a point in time

A SOC 2 Type I report assesses whether your controls are suitably designed as of a specific date. It does not evaluate whether controls operated effectively over time. Type I is often used as a first milestone or when there is insufficient operating history for a Type II.

Auditors assess

Controls are suitably designed to meet the Trust Service Criteria
Policies and procedures exist and are documented as of the report date
The system description accurately reflects the in-scope environment
Management's assertion is supported by evidence on hand at the report date

Type II — Operating effectiveness over a period

A SOC 2 Type II report tests whether controls operated effectively throughout a defined review period — typically six to twelve months. This is the report most customers and enterprise buyers expect and is required for many enterprise procurement processes.

Auditors assess

Controls operated consistently throughout the entire audit period
Evidence is current, complete, and covers the full review window
Exceptions are identified and their impact on the overall opinion is assessed
Staff demonstrate awareness of their responsibilities in control procedures
Subservice organisation reliance and complementary user entity controls are addressed

FAQ

What are the SOC 2 Trust Service Criteria?

The AICPA defines five Trust Service Criteria for SOC 2: Security (the Common Criteria, required in all SOC 2 engagements), Availability, Processing Integrity, Confidentiality, and Privacy. Most organisations include Security as the minimum and add Availability and Confidentiality when contractually required by enterprise customers. The scope of criteria included determines which controls are tested.

How long does SOC 2 preparation take?

For a SOC 2 Type I, organisations with mature internal controls can be ready in six to twelve weeks. For a Type II, the audit period itself is typically three to twelve months, so the full process from readiness assessment to receiving a Type II report often takes six to eighteen months depending on control maturity and evidence history at the start of the engagement.

What is the difference between SOC 2 and ISO 27001?

SOC 2 is an attestation engagement conducted by a licensed CPA firm under AICPA standards, resulting in a confidential audit report shared with specific parties. ISO 27001 is an international standard that results in a publicly verifiable certification and focuses on Information Security Management Systems (ISMS). SOC 2 places greater emphasis on the effectiveness of controls and their operational maturity, while ISO 27001 establishes a comprehensive information security management framework. Many organisations pursue both, and significant control overlap exists between the two frameworks.

Do we need a penetration test for SOC 2?

A penetration test is not explicitly required by the SOC 2 Trust Service Criteria, but it is a widely expected control for the Security criterion and is commonly included in system descriptions as evidence of vulnerability management maturity. Many auditors will note the absence of penetration testing as an observation, and most enterprise customers expect to see penetration testing referenced in a SOC 2 report.

What happens if auditors find exceptions?

Exceptions do not automatically result in a qualified or adverse opinion. The auditor assesses the nature, frequency, and risk impact of each exception. Minor isolated exceptions with compensating controls may be noted without affecting the overall opinion. Systematic exceptions — where a control failed repeatedly or entirely — are more serious. Transparency with your auditor and early remediation of known gaps minimises exception risk.

Can SOC 2 preparation support ISO 27001 certification?

Yes. The two frameworks share significant control overlap in access management, vulnerability management, incident response, vendor risk, and business continuity. Evidence collected during SOC 2 preparation can directly support ISO 27001 controls, reducing duplicated effort. Many organisations pursuing both frameworks use an integrated GRC platform to manage controls, evidence, and audit readiness across both simultaneously.