SOC 2 Readiness Checklist for Startups
See how close you are to a SOC 2 audit in about 4 minutes.
Answer 26 yes, partially, or no questions across the 10 areas SOC 2 auditors review. You get a readiness score, a score for each area, and the gaps worth closing first.
The checklist
Check your SOC 2 readiness
Access control
Who can get into what, and how you prove it.
Is multi-factor authentication (MFA) turned on for every work tool, including email, cloud (AWS/GCP/Azure), GitHub, Slack, and your password manager? Key
Why this matters: Stolen passwords are the most common way attackers get in, and auditors check MFA on every critical system.
Does each person only have the access they need for their job? That means no shared admin logins, and production access limited to a few people.
Why this matters: If one account is compromised, limited access limits the damage.
Do you review who has access to your key systems at least every quarter, and keep a record of each review?
Why this matters: Auditors ask for proof the reviews happened, not just that you could do them.
When someone leaves, is all their access removed within a day or so, following a checklist? Key
Why this matters: Former employees with live accounts are one of the first things auditors look for.
Security policies
The written rules your audit is measured against.
Do you have written security policies (for example information security, acceptable use, access control) that leadership has formally approved? Key
Why this matters: A SOC 2 audit checks you against your own policies, so without them there's nothing to audit.
Has every employee read and acknowledged those policies, with a record you can show?
Why this matters: Auditors want proof each person agreed to the rules, usually at hire and once a year.
HR and training
How you vet, bind, and train the people with access.
Do you run background checks on new hires, where the law allows?
Why this matters: Auditors check that people are vetted before they get access to customer data.
Does everyone sign a confidentiality agreement when they join?
Why this matters: It formally commits employees and contractors to protecting customer data.
Does everyone complete security awareness training when they join and at least once a year?
Why this matters: Phishing targets people, not servers, and auditors ask for completion records.
Infrastructure and endpoints
How your data and devices are protected.
Is customer data encrypted at rest, including databases, file storage, and backups?
Why this matters: Encryption protects data if storage is ever exposed, and auditors verify it's switched on.
Is all data encrypted in transit, with HTTPS everywhere, including internal services and APIs?
Why this matters: Unencrypted traffic can be read or changed by anyone in the middle.
Are company laptops managed with a device management (MDM) tool that enforces disk encryption, screen lock, and updates?
Why this matters: A lost laptop is a common incident, and auditors want to see devices are protected by policy, not by trust.
Do you scan for vulnerabilities and patch them on a regular schedule?
Why this matters: Auditors want to see that you find known weaknesses and fix them in a set timeframe.
Change management
How code gets from a laptop to production.
Does every code change get reviewed and approved by someone other than the author before it reaches production? Key
Why this matters: Peer review is how auditors confirm no one person can push unchecked changes.
Do you have separate environments for development/testing and production, with no real customer data used in testing?
Why this matters: Keeping them apart stops experiments from breaking or exposing production.
Are production deployments traceable, so you can see who deployed what, and when?
Why this matters: Auditors pick sample changes and follow them from ticket to deploy.
Logging and monitoring
Whether you'd know if something went wrong.
Are logs from your app, cloud, and identity provider collected in one central place and kept for a set period? Key
Why this matters: If something goes wrong, you need a record of what happened, and auditors check it exists.
Do you get alerts for important events (unusual logins, admin changes, outages), with a named person responsible for responding?
Why this matters: Logs only help if someone notices when something looks wrong.
Incident response
What happens on your worst day.
Do you have a written incident response plan that says who does what, and when to tell customers? Key
Why this matters: Auditors expect a plan before an incident, not one written during it.
Have you tested that plan (for example with a tabletop exercise) in the last 12 months?
Why this matters: A plan nobody has practiced tends to fall apart under pressure, and auditors ask for evidence of a test.
Vendor management
The tools and companies you share data with.
Do you keep an up-to-date list of vendors that handle your company or customer data?
Why this matters: Your customers' data is only as safe as the tools you share it with.
Do you review the security of key vendors (for example their SOC 2 report) before signing and about once a year?
Why this matters: Auditors expect you to check that critical vendors meet your standards.
Risk assessment
How you decide what to worry about.
Have you done a formal risk assessment in the last 12 months that covers what could go wrong, how likely it is, and what you're doing about it? Key
Why this matters: SOC 2 requires at least a yearly risk assessment, and many other controls trace back to it.
Is one person clearly responsible for security and compliance, and does leadership review security at least once a year?
Why this matters: Auditors look for clear ownership and leadership oversight.
Backups and business continuity
Whether you can recover when things break.
Are backups automatic, and have you actually restored from one in the last 12 months to prove it works? Key
Why this matters: A backup you’ve never restored is a guess, and auditors ask for proof of a test.
Do you have a written plan for keeping the business running if a key system, cloud region, or vendor goes down?
Why this matters: Auditors want to see you've thought through recovery before you need it.
Prefer a printable version?
Download the SOC 2 readiness checklist (PDF)
The key controls auditors check across all 10 SOC 2 areas, the evidence they ask for, and how to score your readiness.
Your download has started. Download again
What the checklist covers
The 10 areas auditors commonly review for SOC 2 security, in plain language, with what auditors typically ask to see for each.
01
Access control
Who can get into what, and how you prove it.
What auditors ask for: An export of users and roles for each key system, your MFA settings, your last quarterly access review with sign-off, and offboarding tickets showing when each person's access was removed.
4 questions · SOC 2 criteria CC6.1–CC6.3
02
Security policies
The written rules your audit is measured against.
What auditors ask for: Approved policy documents with version history and approval dates, and a signed acknowledgment from each employee.
2 questions · SOC 2 criteria CC2.2, CC5.3
03
HR and training
How you vet, bind, and train the people with access.
What auditors ask for: Background check confirmations, signed confidentiality agreements, and security training completion records for a sample of employees.
3 questions · SOC 2 criteria CC1.1, CC1.4, CC2.2
04
Infrastructure and endpoints
How your data and devices are protected.
What auditors ask for: Encryption settings for databases, storage, and backups, your TLS configuration, an MDM report covering every laptop, and recent vulnerability scans with the fixes that followed.
4 questions · SOC 2 criteria CC6.1, CC6.7, CC6.8, CC7.1
05
Change management
How code gets from a laptop to production.
What auditors ask for: A sample of production changes, each with its pull request, an approval from someone other than the author, and the matching deployment record.
3 questions · SOC 2 criteria CC8.1
06
Logging and monitoring
Whether you'd know if something went wrong.
What auditors ask for: Log retention settings, your alert rules and who receives them, and examples of alerts that were investigated.
2 questions · SOC 2 criteria CC7.2
07
Incident response
What happens on your worst day.
What auditors ask for: Your incident response plan, notes from your last tabletop exercise, and records of any real incidents and how they were handled.
2 questions · SOC 2 criteria CC7.3–CC7.5
08
Vendor management
The tools and companies you share data with.
What auditors ask for: Your vendor list with a risk rating for each, and the security reviews (such as SOC 2 reports) you collected for key vendors.
2 questions · SOC 2 criteria CC9.2
09
Risk assessment
How you decide what to worry about.
What auditors ask for: Your risk register with likelihood, impact, and an owner for each risk, the date it was last reviewed, and notes from leadership's security review.
2 questions · SOC 2 criteria CC3.1–CC3.4
10
Backups and business continuity
Whether you can recover when things break.
What auditors ask for: Backup schedules and retention settings, a record of your last restore test, and your business continuity plan.
2 questions · SOC 2 criteria CC7.5, CC9.1, A1.2–A1.3
FAQs
SOC 2 readiness questions, answered
What is a SOC 2 readiness assessment?
A readiness assessment checks your current security practices against what a SOC 2 auditor will look for, before the audit starts. It shows which controls are in place, which are partly there, and which are missing, so you can close gaps before they turn into audit findings.
What does this SOC 2 readiness checklist cover?
It covers 10 areas auditors commonly review for SOC 2 security: access control, security policies, HR and training, infrastructure and endpoints, change management, logging and monitoring, incident response, vendor management, risk assessment, and backups and business continuity.
How is my readiness score calculated?
Each Yes earns full points, each Partially earns half, and each No earns none. Key controls count double. Your overall score is the share of possible points you earned: under 50% is Early stage, 50% to 79% is Getting close, and 80% or more is Audit ready, as long as no key control is answered No.
Does a high score mean we will pass our SOC 2 audit?
No. This is a self-assessment, not an audit. Auditors test evidence that your controls actually work, so treat your score as a starting point for planning rather than a prediction of your audit result.
What is the difference between SOC 2 Type 1 and Type 2?
A Type 1 report looks at whether your controls are designed properly at a single point in time. A Type 2 report tests whether those controls operated effectively over a period of time, typically 3 to 12 months, which is why enterprise buyers usually ask for Type 2.
Does this checklist work for SOC 2 Type 1 and Type 2?
Yes. Both reports use the same criteria, so the questions apply to either. The questions with a time frame, like quarterly access reviews, annual training, and a tested backup in the last 12 months, are the ones a Type 2 auditor checks over your observation period.
What happens to my answers?
Your answers stay in your browser while you take the checklist. If you enter your work email to unlock your full results, we receive your email, your score, and your answers so we can send you your results and follow up about your free hours.
What should we do after we get our results?
Start with the key controls in your top gaps, since those can hold up an audit on their own. If you want help turning your gaps into a plan with a realistic timeline, you can request a free SOC 2 gap assessment from YSecurity.
Know your gaps? The next step is a plan.
Turn your gaps into a plan
Send your company email and we'll come back with your gap assessment and a realistic timeline.
Get a free SOC 2 gap assessment →