SOC 2 compliance › Readiness checklist
SOC 2 readinessSOC 2 readiness checklist: what auditors ask to see
Most checklists list controls. This one lists what you should be able to show for each control, so you can tell whether you are ready to start the audit window or whether starting now would only create exceptions.
Free for buyers · provider-funded introductions · Updated October 2026
Three possible outcomes
Work through scope, the control areas and the gate. You will land in one of these.
Start the window
You can answer yes to every gate question. Agree the start date with your auditor and begin.
Fix, then start
A few gaps remain and each has an owner and a date. Close them before the window opens.
Remediate first
Gaps in access, change approval or evidence capture would create exceptions. Run a gap assessment and fix those first.
Settle scope before you touch a control
Scope decides how many controls apply, so get it wrong and every later step is wasted.
- Criteria: Security is always in scope. Add Availability, Processing integrity, Confidentiality or Privacy only if a contract or customer needs them.
- System boundary: which product, environments, locations and vendors the report will cover.
- Report type: Type 1 or Type 2. Check what your customer accepts, using our Type 1 vs Type 2 guide.
- Audit period: the window the auditor will accept for a first report. Confirm it before you start.
- The requester: read the customer contract or questionnaire. It often states the report type, period and criteria.
11 control areas: what to have and what auditors sample
For each item, the left column is the control to have in place. The right column is the evidence an auditor typically asks to see, so keep it as the control runs.
Access control
Who can get into what, and how that is controlled and reviewed.
| What to have in place | Evidence auditors typically sample |
|---|---|
| MFA and unique accounts on in-scope systems | MFA enforcement settings; user list export |
| Role-based access with approval for requests | Role matrix; access request tickets with approver |
| Periodic access reviews and fast removal on exit | Signed review records; offboarding tickets with dates |
Change management
How changes reach production and who approves them.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Every production change reviewed and approved first | Pull requests with reviewer; change tickets |
| Development and production separated | Environment configuration; access lists |
| Emergency changes documented afterwards | Emergency change log with retrospective approval |
Risk assessment
How you identify, rate and decide what to do about risk.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Documented risk assessment at least annually | Risk register with owners and dates |
| Treatment decision for each material risk | Treatment plans; management sign-off |
| Review after major changes to the system | Meeting notes or updated register |
Logging and monitoring
Whether security events are recorded, alerted on and looked at.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Central logging of security-relevant events | Log source inventory; sample log entries |
| Alerts configured for defined events | Alert rules; tickets raised from alerts |
| Evidence that someone reviews the alerts | Review records; on-call or triage notes |
Vulnerability management
How weaknesses are found and fixed.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Regular vulnerability scanning | Scan reports across the period |
| Defined patching timelines that are followed | Remediation tickets with open and close dates |
| Penetration test with tracked fixes | Test report; retest or closure evidence |
Incident response
What happens when something goes wrong.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Written plan with roles and contacts | Plan with approval history |
| Incidents logged, handled and reviewed | Incident tickets; post-incident reviews |
| Plan exercised at least once | Tabletop or simulation record |
Vendor management
Third parties that touch your systems or customer data.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Inventory of vendors and subprocessors | Vendor list showing what data each can reach |
| Due diligence on critical vendors | Completed reviews; their assurance reports |
| Security terms in vendor contracts | Signed agreements or data processing terms |
People and training
Joiners, movers, leavers and awareness.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Onboarding checks where lawful | Completed onboarding checklists |
| Security awareness training for everyone in scope | Completion records with dates |
| Policies read and acknowledged | Signed or recorded acknowledgements |
Data protection
How data is secured and how long you keep it.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Encryption in transit and at rest | Configuration settings or screenshots |
| Data classification and retention rules | Policy plus evidence of deletion |
| Keys and secrets managed securely | Secrets tool configuration; access list |
Continuity and recovery
Whether you can keep running and recover.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Backups running as designed | Backup job logs |
| Restores tested | Restore test record |
| Continuity and recovery plan reviewed | Plan with review date |
Governance and policies
Who owns the controls and how management oversees them.
| What to have in place | Evidence auditors typically sample |
|---|---|
| Policies approved by management and reviewed on a schedule | Policies with version history |
| A named owner for each control | Control matrix with owners |
| Leadership reviews security regularly | Meeting minutes or review records |
Auditors sample across the period for a Type 2. A control that exists on paper but leaves no evidence counts for little, so capture evidence from day one.
Are you ready to start the Type 2 window?
Answer honestly. Starting the window early produces exceptions that stay in the report.
- Scope, criteria and system boundary are agreed in writing, and the system description is drafted.
- Every in-scope control has a named owner.
- Policies are approved by management and acknowledged by staff.
- MFA and access reviews are already operating on in-scope systems.
- Every production change is approved before release, not just most of them.
- Logging and alerting are live and someone reviews them.
- Vulnerability scanning is running and a penetration test is done, with fixes tracked.
- Evidence is captured as controls run, rather than reconstructed later.
Any no above means fix it before the window starts. Also confirm with your auditor the start date and the period they will accept for a first report.
Readiness help is not the audit
You, an advisor, a tool and the auditor each have a different job. Keep advisory and audit roles separate.
| Task | You | Readiness advisor | Automation tool | Auditor |
|---|---|---|---|---|
| Decide scope and criteria | Lead, using customer contracts | Advises | — | Confirms acceptability |
| Write policies | Approve and own | Can draft | Templates only | — |
| Implement controls | Do the work | Guides | Helps with some checks | — |
| Collect evidence | Keep controls running | Reviews what is collected | Gathers from connected systems | Samples it |
| Pre-audit gap assessment | Fix the gaps | Can run it | Can flag gaps | Not usually the same firm that audits you |
| Test controls and issue the report | — | — | — | Only the CPA firm, independently |
More on choosing between them in the providers section of the SOC 2 hub.
Notes for buyers outside the US
- ISO 27001 overlap: the control sets overlap substantially, so scoping them together can reduce duplicated work. See the ISO 27001 cost guide.
- Hosting and subprocessors: US customers often ask where data is hosted and which vendors can reach it. Know the answer before they ask.
- Contract first: your customer contract decides the report type, period and criteria, not a template.
- Local rules stay separate: SOC 2 does not satisfy local obligations such as the DPDP Act or RBI guidelines.
Common readiness mistakes
- Starting the window before controls reliably run, then logging exceptions.
- Treating evidence as an end-of-period task instead of capturing it as you go.
- Over-scoping criteria that no contract requires.
- Buying a Type 1 by default when the customer wants Type 2.
- Letting the auditor also write your controls, which blurs independence.
- No named owners, so controls drift once the project team moves on.
SOC 2 readiness questions
What is a SOC 2 readiness assessment?
Is a readiness assessment required before a SOC 2 audit?
How long does SOC 2 readiness take?
Can we do SOC 2 readiness ourselves?
How much does a readiness assessment cost?
Does passing a readiness assessment mean we will pass the audit?
Start with the requirement, not the auditor.
Free for buyers · provider-funded introductions