SOC 2 Readiness Checklist

A SOC 2 audit examines whether your controls were designed appropriately and, in a Type II, whether they operated effectively across a defined period. Readiness is therefore two things: having the controls, and being able to evidence that they ran. Most organisations have more of the first than the second.

This checklist covers what to put in place before an auditor arrives, in the order that avoids rework.

Before you start: three decisions

1. Which Trust Services Criteria apply. Security is mandatory. Availability, Processing Integrity, Confidentiality and Privacy are optional and each adds scope, controls and evidence. Include one only if a customer has asked for it or your service genuinely depends on it.

2. Type I or Type II. Type I tests design at a point in time. Type II tests operating effectiveness across a period, commonly three to twelve months. Type II is what enterprise buyers usually mean, and the observation window cannot be shortened.

3. Scope. Which systems, which environments, which team. Narrower scope means less evidence, fewer controls and a faster audit. Scope to the service your customer is buying.

Governance and risk

• ☐ A named owner for the SOC 2 programme, with authority and budget

• ☐ Information security policy, approved by management and reviewed annually

• ☐ Risk assessment completed, documented, with treatment decisions recorded

• ☐ Organisation chart and defined security responsibilities

• ☐ Board or management oversight of security, with meeting records

• ☐ Vendor risk management process, with assessments on record for critical vendors

• ☐ Confidentiality agreements in place with employees and contractors

Access control

• ☐ Single sign-on in place wherever supported

• ☐ Multi-factor authentication enforced on all accounts, including administrative and service accounts

• ☐ Documented joiner, mover and leaver process, with evidence of execution

• ☐ Access granted on least privilege, with approval recorded

• ☐ Quarterly access reviews, with evidence of what was reviewed and what changed

• ☐ Privileged access separately controlled and logged

• ☐ Password policy enforced technically, not just written down

Change management

• ☐ Version control for all production code

• ☐ Peer review required before merge, enforced by the tooling

• ☐ Separate development, staging and production environments

• ☐ Deployment approvals recorded

• ☐ Rollback procedure documented and tested

• ☐ Infrastructure changes tracked the same way as code changes

System operations and monitoring

• ☐ Centralised logging from applications, infrastructure and cloud

• ☐ Alerting configured with defined thresholds, routed to a named owner

• ☐ Monitoring coverage for availability if Availability is in scope

• ☐ Capacity monitoring with defined thresholds

• ☐ Log retention meeting the audit period plus margin

Vulnerability and patch management

• ☐ Vulnerability scanning on a defined schedule, with results retained

• ☐ Annual penetration test with findings tracked to closure

• ☐ Patch management policy with defined timelines by severity

• ☐ Evidence that patches were applied within those timelines

• ☐ Endpoint protection deployed and monitored across all devices

Incident response

• ☐ Documented incident response plan with roles and escalation

• ☐ Incident log, including incidents that turned out to be nothing

• ☐ At least one tabletop exercise conducted, with notes

• ☐ Customer notification process defined

• ☐ Post-incident review process, with records where incidents occurred

Business continuity and backup

• ☐ Backup running on a defined schedule across all critical systems

• ☐ Restore testing performed and evidenced — not just backup success logs

• ☐ Business continuity and disaster recovery plan documented

• ☐ Recovery time and recovery point objectives defined and agreed

• ☐ Annual continuity test with results recorded

Data protection

• ☐ Encryption in transit enforced across all external connections

• ☐ Encryption at rest for databases, storage and backups

• ☐ Key management process documented

• ☐ Data classification applied, with handling rules per class

• ☐ Data retention and secure deletion policy, actually running as jobs

• ☐ Production data not used in non-production environments

People

• ☐ Background checks where legally permitted and appropriate

• ☐ Security awareness training on joining and annually, with completion records

• ☐ Onboarding and offboarding checklists, with completed examples on file

• ☐ Acceptable use policy acknowledged by all staff

Evidence collection — the part that fails audits

Controls existing is not the same as controls being evidenced. For every control above, decide now:

What artefact proves it ran? A ticket, an approval, a log export, a signed record, a screenshot with a timestamp.

Who produces it, and when?

Where is it stored, and can it be produced quickly during the audit?

Start collecting on day one of the observation window, not at the end. Evidence that is reconstructed afterwards is the single most common cause of exceptions in a Type II report.

Suggested sequence

Four to eight months from a standing start is realistic. Organisations already running version control, single sign-on, peer review and centralised logging reach the faster end.

Where companies get caught out

Starting evidence collection late. The observation window is the window. You cannot evidence a quarterly access review that happened once, a week before the audit.

Including criteria nobody asked for. Adding Availability or Privacy because they sound thorough adds months. Ask the customer who requested SOC 2 what they need covered.

Treating policies as the deliverable. Auditors test whether policies are followed, not whether they exist. A policy the team has never read produces exceptions.

Leaving vendor management until the end. Critical vendor assessments take time because they depend on other companies responding.

Get a SOC 2 readiness assessment

Aadit Technologies runs SOC 2 readiness as a structured engagement: scope and criteria selection, gap assessment against the Trust Services Criteria, control implementation support, evidence collection design, and audit support through fieldwork.

Request a SOC 2 readiness assessment →

Frequently asked questions

What is a SOC 2 readiness assessment?

A structured review of your current controls against the Trust Services Criteria in scope, producing a gap list, a remediation plan and an evidence collection design. It is done before the observation window starts, so that the controls being observed are the right ones.

How long does SOC 2 take to prepare for?

Four to eight months from a standing start for a Type II, because the observation window alone is three months minimum. Organisations with mature engineering practices move faster, since much of the control work is already in place and only needs evidencing.

What is the difference between SOC 2 Type I and Type II?

Type I assesses whether controls are suitably designed at a single point in time. Type II assesses whether they operated effectively over a period. Type II is what most enterprise buyers mean when they ask for a SOC 2 report.

Do we need a penetration test for SOC 2?

SOC 2 does not name penetration testing explicitly, but auditors expect evidence of technical vulnerability testing, and a penetration test is the normal way to provide it. Plan for it within the programme rather than as a late addition.

Can we fail a SOC 2 audit?

You do not fail in the sense of a pass or fail grade. The auditor issues a report that may contain exceptions where controls did not operate as described, and buyers read those exceptions. A readiness assessment beforehand is what prevents surprises.

Is SOC 2 better than ISO 27001?

Neither is better — they answer different questions for different audiences. US buyers usually ask for SOC 2; European, Indian and Middle Eastern buyers usually ask for ISO 27001. See our comparison of SOC 2 and ISO 27001.