SOC 2 Readiness Checklist
A SOC 2 checklist for startups facing a first audit: set scope and criteria, write policies, run controls and collect evidence before the auditor arrives.
- Typical schedule once, then annually
- The checklist 5 sections, 25 items
- Variables
{{company}}
Use this checklist when a customer asks for a SOC 2 report and you need to get from "we are fairly secure" to an audit you can pass. It covers the readiness phase: deciding scope, closing gaps, and making sure controls run long enough to produce evidence. It fits SaaS companies with a small engineering team and no dedicated compliance staff.
Who owns it
One person must own the project, usually the CTO, a security lead or an operations lead. They will need time from engineering, HR and finance. Choose the audit firm early, because their expectations shape the evidence you collect. Adapt this to your jurisdiction and your customers' requirements; it is a practical checklist, not legal advice.
Common pitfalls
- Scoping too wide. Every system in scope needs controls and evidence. Start with the production service your customers actually use.
- Policies nobody follows. Templates copied from the internet describe processes you do not run. The auditor will test what the policy says.
- Starting the Type II window too early. If controls are not running reliably yet, the observation period will collect exceptions instead of evidence.
- Evidence collected at the last minute. Screenshots taken in a rush rarely show the date or the population. Collect evidence as each control runs.
- Treating tools as the answer. Compliance platforms help with tracking, but someone still has to do the reviews and the onboarding steps.
Recurring controls like access reviews and vendor checks can each run as their own scheduled checklist, so the evidence builds up as you go.
The checklist: SOC 2 readiness for {{company}}
Scope and audit approach
-
Decide which Trust Services Criteria are in scope
Security is always included. Add Availability, Confidentiality, Processing Integrity or Privacy only if customers need them.
-
Define the system boundary: services, infrastructure, people and vendors in scope
-
Decide between a Type I report first or going straight to Type II
-
Shortlist and select an audit firm and agree a timeline
-
Identify subservice organisations (e.g. your cloud provider) and collect their SOC reports
Gap assessment
-
Map your existing practices to the criteria in scope and list the gaps
-
Complete a documented risk assessment for the in-scope system
-
Assign an owner to every control and every gap
-
Agree a remediation plan with dates for each gap
Policies and people
-
Write or adapt the core policies: information security, access control, change management, incident response, vendor management, business continuity
Keep them short and true to how you work. Get management approval and record the date.
-
Have all staff acknowledge the policies and record the acknowledgements
-
Set up onboarding steps: background checks where lawful, security training and signed confidentiality terms
-
Set up offboarding steps that remove all access promptly and leave a record
Technical controls
-
Enforce SSO and multi-factor authentication on in-scope systems
-
Require reviewed pull requests and protected branches for production code
-
Turn on central logging and alerting for production and admin actions
-
Confirm encryption in transit and at rest for customer data
-
Set up vulnerability scanning and a documented patching timeline
-
Confirm backups run and test a restore
-
Manage endpoints: disk encryption, screen lock and OS updates on company laptops
Run controls and collect evidence
-
Schedule recurring controls: access reviews, vendor reviews, risk assessment updates, backup tests
-
Run a tabletop incident response exercise and record the outcome
-
Set up an evidence folder per control and per period
-
Run an internal readiness review before the audit window starts optional
Some audit firms offer a paid readiness assessment that finds gaps before the real audit.
-
Confirm the start date of the observation period with the auditor
Checklist as Markdown
Frequently asked questions
What is the difference between SOC 2 Type I and Type II?
A Type I report checks whether your controls are designed properly at a single point in time. A Type II report also tests whether they operated effectively over an observation period, often several months. Many customers ask for Type II, but a Type I can be a useful first step while the period runs.
How long does it take to get SOC 2 ready?
It depends on how many gaps you have. A small team with good engineering habits can often get ready within a few months, while a team starting from scratch needs longer. A Type II report then also needs the full observation period before the auditor can issue it.
Do we need a compliance automation tool for SOC 2?
No. The audit tests your controls, not your tooling. Platforms can save time on evidence collection and reminders, but a small team can also pass with clear policies, scheduled checklists and a well-organised evidence folder.
Updated