SOC 2 Compliance Checklist for Startups: 24 Steps

A SOC 2 audit evaluates whether a company’s security controls are suitably designed and, for a Type 2 report, whether they operated effectively throughout a defined period. Preparing for it involves defining the audit’s scope, implementing controls, operating them on a regular schedule, and retaining dated evidence of each.

Although SOC 2 doesn’t produce a pass or fail result, first audits often surface exceptions. An exception is a tested sample in which a control did not operate as described, such as a quarterly access review that was skipped or a former employee’s account that stayed active past the deadline in your offboarding policy.

This checklist is for startups of roughly 5 to 50 people without a dedicated security hire. It splits the work into 24 steps across four stages and pairs each step with the evidence auditors typically request. The AICPA’s criteria do not prescribe controls, so treat these steps as a starting point and check them against your auditor’s request list.

01Define the scope

02Put the controls in place

03Run them over the period3 to 12 months

04Complete the auditAbout 9 to 14 weeks

Steps 1 to 4. Decide which Trust Services Criteria, systems, people and vendors the audit covers, choose between a Type 1 and a Type 2 report, and select a CPA firm.

Steps 5 to 21. Approve your policies, enforce access controls, and set up the processes the auditor will test. For a Type 2 report, every control needs to be operating before the observation period begins.

Steps 22 and 23. Operate each control on its schedule and keep dated evidence of it. A Type 2 auditor samples records from across the entire period.

Step 24. The auditor requests evidence, tests your controls and sends a draft report for your review before issuing the final one.

Hover over a stage to see what it involves. Durations are typical planning estimates for a first-time company.

How to prepare for your first SOC 2 audit

Most startups begin SOC 2 work because a customer asks for the report. Before you buy a tool or sign with an auditor, settle these five things:

1. Who asked, and for what. Ask the customer whether they need a Type 1 or a Type 2 report, and by when. That answer sets your timeline.
2. One owner. A founder, the CTO or the first engineer who owns security runs the project and answers the auditor.
3. A budget. The CPA audit alone typically costs $10,000 to $50,000, and the first year can reach $80,000 or more once you add readiness work, tools and a penetration test. Our SOC 2 cost guide breaks it down.
4. A realistic date. A Type 1 can be done within a few months if most controls already exist. A first Type 2 commonly takes 12 to 15 months from readiness to report, because the auditor tests controls over a period of 3 to 12 months.
5. A gap list. Compare what you do today with the 24 steps below. Every gap goes into one of three piles: change a setting, write something down, or start doing something. Start the third pile first, because it needs history before the audit period opens.

Then work through the stages in order. The 30-day plan after the checklist shows how to spread the first month. Our page on SOC 2 for startups explains what Jutsu contributes and what stays with you and your auditor.

Stage 1: Define the scope (steps 1 to 4)

These four steps decide which criteria, systems and people the audit covers. Settle them and write them down before any other work begins.

Scope and ownership4 steps

1. Name one accountable ownerOne person runs the program: a founder, the CTO or the first engineer who owns security. They set deadlines, make the scope calls and answer the auditor. Write security duties into job descriptions so the auditor can see who does what.Keep: The owner’s name, an org chart and job descriptions that list security duties.When: At kickoff, and when roles change. Owner: Founder or CTO. 2. Choose Type 1 or Type 2, and your criteriaAsk your customers which report they need. A Type 1 report checks that your controls are designed properly on a single date. A Type 2 checks that they operated over a period, commonly 3 to 12 months. Startups with a contract deadline often get a Type 1 first and start the Type 2 period right after. Security is in nearly every SOC 2 report and covers 33 common criteria in nine series, CC1 to CC9. Availability, Processing Integrity, Confidentiality and Privacy are optional and add 28 more, so add one only when a customer asks for it.Keep: The customer requirement (an email or contract clause), the report type and the criteria you chose.When: Before you talk to auditors. Owner: Founder, with sales. 3. Define the system boundary and write the system descriptionList the product, cloud accounts (AWS, Google Cloud, Azure), databases, code repositories, internal tools, people and vendors that store or process customer data. That list becomes your system description, which you update whenever any of it changes. Physical data center security sits with your cloud provider, and under the carve-out method the auditor leaves it out of testing. Your own cloud settings stay yours, and so do the complementary user entity controls (CUECs) listed in the provider’s SOC report.Keep: A dated system inventory, an architecture or data-flow diagram and a one-page scope statement.When: At kickoff, and after major changes. Owner: Engineering. 4. Pick an independent CPA firm and agree the audit periodOnly a licensed CPA firm can issue a SOC 2 report. Compare firms on startup experience, whether your customers accept their reports, fees, and what triggers extra charges. Sign the engagement letter and agree the audit period dates before a Type 2 period begins. Our guide on how to choose a SOC 2 auditor covers what to verify before you sign.Keep: The signed engagement letter, the agreed scope and period, and the auditor’s evidence request list.When: Before the audit period starts. Owner: Founder or finance.

Stage 2: Put the controls in place (steps 5 to 21)

Each step pairs a control that auditors commonly expect at startups with the evidence they usually request. The references next to each group show which Trust Services Criteria it maps to. SOC 2 lets each company choose controls that fit its environment, so treat these as a strong baseline rather than a fixed list. For a Type 2 report, every control needs to be running before the audit period begins.

Policies, people and riskCC1, CC2, CC3, CC5

5. Approve policies that match how you workWrite and approve policies for information security, access control, acceptable use, change management, incident response, vendors and data retention. Only commit to what you will do: if a policy says access is reviewed every quarter, the auditor will ask to see each review.Keep: Each policy with the name of its approver, the approval date and the version number.When: At launch, then once a year. Owner: Security owner. 6. Train everyone and collect policy acknowledgmentsEvery employee and contractor completes security awareness training and signs that they have read the policies, at hire and once a year. Contractors are the group most often missing from these records.Keep: Training completion records and signed acknowledgments with each person’s name, the date and the policy version.When: At hire, then once a year. Owner: People ops. 7. Run onboarding and offboarding the same way every timeGrant access by role, approved by someone other than the requester. Where local law allows, run a background check before a new hire can reach customer data. When someone leaves, remove their access to every system (Google Workspace, AWS, GitHub, Slack) within the time your policy sets. Late removal is one of the most frequent findings in first audits.Keep: Access requests showing who approved them, background check records, and offboarding checklists with timestamps the auditor can compare with HR termination dates.When: Every hire, role change and departure. Owner: IT or people ops. 8. Keep a risk register and review it with leadershipOnce a year, list the threats to your systems and data, rate each for likelihood and impact, and decide what you will do about it. Leadership reviews the register, recent incidents and open issues at least once a year.Keep: A dated risk register with owners, ratings and treatment plans, plus the notes or sign-off from the leadership review.When: Once a year, and after major changes. Owner: Founder or security owner.

Access, cloud and devicesCC6

9. Enforce MFA on every in-scope systemRequire multi-factor authentication on Google Workspace or Microsoft 365, AWS, GitHub and every other in-scope system, either directly or through an identity provider that requires it. Single sign-on makes access easier to manage but does not replace MFA. Write down any service-account exceptions.Keep: An export of the enforcement settings, a user list showing each account’s MFA status, and the exception list.When: Always on. Check it monthly. Owner: IT or engineering. 10. Limit admin access and review access every quarterGive admin and production access only to people with a documented need. Every quarter, review who can reach each in-scope system and remove what is no longer needed. Failed access reviews are the most common reason for a qualified opinion in published audit data. Have someone else review the reviewer’s own access.Keep: A list of privileged accounts with a reason for each, and for every review: the user list, how it was pulled, the reviewer and the date.When: At each grant, then every quarter. Owner: Engineering. 11. Manage company laptopsEnforce disk encryption, screen lock, endpoint protection and operating system updates on every company laptop through a device management tool.Keep: A device inventory and an export of the settings from your device management tool.When: Always on. Export monthly. Owner: IT. 12. Keep an inventory of systems and data storesList every in-scope cloud account, repository, database, storage bucket and device. Review risky configuration changes and fix misconfigurations, such as a storage bucket open to the internet.Keep: A dated inventory export, configuration findings and the history of their fixes.When: Kept current. Reviewed on a schedule you set. Owner: Engineering. 13. Protect customer data and secretsEncrypt customer data in databases, storage and backups, and use TLS for every connection to your service. Keep API keys and passwords in a secrets manager, not in code or chat. Delete customer data at the end of its retention period, and wipe retired devices before disposal.Keep: Encryption and TLS settings, a data-flow diagram, key rotation records where you rotate keys, and deletion and disposal records.When: At design time and when systems change. Owner: Engineering.

Build, detect and respondCC7, CC8

14. Review every production changeEvery production change goes through a pull request approved by someone other than its author. Emergency fixes that skip review get a ticket and a review afterward. Development and testing happen in environments separate from production.Keep: Branch protection settings, pull request history, a ticket for each hotfix with its later review, and a diagram or account list showing the separate environments.When: Every change. Owner: Engineering. 15. Scan for vulnerabilities and run a yearly penetration testRun vulnerability scans on a set schedule and fix each finding within the time your policy sets for its severity. Once a year, have an independent firm test your application and infrastructure. No criterion requires a penetration test by name, but auditors and customers commonly expect one.Keep: Scan reports, tickets with close dates (or a signed risk acceptance), and the penetration test report with retest results.When: Scans on schedule. Penetration test yearly. Owner: Engineering. 16. Collect security logs in one placeSend logs from AWS CloudTrail, Google Workspace, GitHub and your production systems to one place, and keep them for the whole audit period.Keep: A list of log sources, the retention settings and sample logs from early in the period.When: Always on. Owner: Engineering. 17. Name who reviews alerts and record each decisionDecide who looks at each security alert, how severity is set and when an alert goes to someone else. Record the outcome every time.Keep: Alert records showing who reviewed each one, when, and what they concluded.When: Every alert. Owner: Security owner. 18. Write an incident response plan and test itThe plan says who leads a response, how incidents are classified and when customers are told. Log every incident, including minor ones. Once a year, walk the team through a realistic scenario, such as a stolen admin account.Keep: The approved plan, an incident log with a timeline and notes for each incident, and exercise notes with the date, attendees and follow-ups.When: Every incident. Exercise yearly. Owner: Security owner and leadership.

Vendors, backups and continuityCC9, A1

19. Review your critical vendorsList every vendor that handles customer data and give each a risk tier based on its access. Once a year, review the high-risk ones, usually by reading their SOC 2 reports for exceptions that affect you.Keep: The vendor list with tiers, their current SOC 2 reports and a record of your review, including the CUECs that apply to you.When: At onboarding, then yearly. Owner: Security owner or operations. 20. Back up your data and test a restoreRun backups automatically and restore from them on a schedule to prove the data comes back.Keep: The backup settings and a dated record of each restore test.When: Backups always on. Restore tests on a schedule. Owner: Engineering. 21. Write a business continuity and disaster recovery planDescribe how the service keeps running or recovers after a major outage: recovery targets, who decides, who tells customers and which vendors you depend on.Keep: The approved plan, a contact list and a record of its most recent test.When: Yearly, and after major changes. Owner: Operations or engineering.

Stage 3: Run the controls through the audit period (steps 22 and 23)

A Type 2 auditor samples dated records from across the entire audit period. Each control needs to run from the first day of the period, and a control that was set up but not repeated on schedule is reported as an exception. The frequencies below are not SOC 2 requirements, but they are common practice. Your own policies set each frequency, and the auditor tests whether your team followed them.

Evidence and readiness2 steps

22. Start an evidence calendarTurn every recurring control into a calendar entry with an owner, a due date, the evidence format and where it is stored. Save dated originals when the work happens instead of rebuilding them when the auditor asks. A Type 2 sample can come from the first weeks of the period.Keep: A control and evidence list, dated exports and review history.When: A weekly check-in, plus each control on its own schedule. Owner: Security owner. 23. Run a readiness review before the period startsCheck that each documented control really runs. Pull a sample of your own evidence the way an auditor would, and close missing records before the Type 2 period opens. If you have not compared your controls with the criteria yet, our post on SOC 2 gap analysis compares the options.Keep: Readiness notes, an issue list and the fixes.When: Before the Type 2 period, then at check-ins. Owner: Security owner and engineering.

As Alerts Arrive

Review Security AlertsKeep a record of who reviewed each alert, what they decided and any follow-up.

Each Hire

Grant Approved Access and Complete OnboardingKeep the access request, the signed policy acknowledgment and the training record.

Each Departure

Remove All Access Within Your Policy’s TimeframeKeep the offboarding checklist with timestamps showing when each account was removed.

Each Production Change

Require an Independent Code ReviewKeep the merged pull request showing who approved it.

Monthly

Check MFA, Devices and Vulnerability ScansKeep an export or screenshot of each check and a ticket for every open finding.

Quarterly

Review User AccessKeep the reviewed user list with the name of the person who reviewed it, the date and any changes made.

Yearly

Complete the Annual Reviews and TestsKeep a dated record of each annual item in steps 5 to 21, including the risk assessment, vendor reviews and penetration test.

Collecting evidence continuously also shortens fieldwork, because most of the auditor’s evidence request can then be fulfilled from records that are already centralized.

Stage 4: Complete the audit (step 24)

The auditor requests evidence, tests your controls and sends a draft report for your review before issuing the final one. Evidence collection typically takes 5 to 7 weeks, followed by about 2 weeks of testing for a Type 1 or 2 to 4 weeks for a Type 2, and 2 to 3 weeks for reporting.

Audit handoff1 step

24. Hand the audit materials to your CPA firmLeadership signs a management assertion confirming that the system description is accurate and that the controls were suitably designed and, for a Type 2, operated effectively. Deliver the system description and every requested sample by the auditor’s deadlines. Review the draft report, its dates and any exceptions, and write a response for each exception before the report is final. Then share the report with customers under a nondisclosure agreement, and keep the controls running: the next report covers the next period.Keep: The final system description, the signed management assertion, a log of requests and responses, and the CPA report.When: During and after the audit. Owner: Founder and security owner.

A 30-day SOC 2 plan for startups

No startup finishes a Type 2 audit in 30 days. In a month you can name owners, close the riskiest gaps and start the routines that make the audit period credible. Spread the first month like this:

Week 1

Draw the line: steps 1 to 4Name the owner, write down what your customers require, talk to two or three CPA firms and map the systems that touch customer data.

Week 2

Close the high-risk gaps: steps 5 and 9 to 13Enforce MFA, cut back admin access, approve the core policies, confirm laptop settings and give every remaining gap an owner.

Week 3

Prove the routines: steps 6, 7 and 14 to 20Test alert review, access approvals, code review, training records, a backup restore and a short incident exercise.

Week 4

Rehearse the audit: steps 22 and 23Pull a sample of your own evidence, check timestamps and gaps, assign follow-ups and agree the audit period with your CPA firm.

The Most Common Control Failures in First SOC 2 Audits

Published audit data shows that most exceptions come from controls that are documented but not performed or recorded consistently.

One CPA firm’s review of 75 SOC 2 audits completed between January 2025 and June 2026 found at least one exception in 71% of them, and first-time audits produced exceptions more often than renewals. A separate 2024 benchmark of 193 SOC reports found exceptions in 54.9% of them, with failed user access reviews as the most common reason for a qualified opinion.

71%

of 75 SOC 2 audits had at least one exception

88%

needed additional evidence during fieldwork

54.9%

of 193 SOC reports had at least one exception

Share of the 75 Audits With an Exception in Each Area

Access Control and User Provisioning51%

Change Management41%

Logging, Monitoring and Alerting37%

Risk Assessment and Vendor Management32%

System Description Accuracy28%

Security Configuration and Vulnerability Management24%

Incident Response and Continuity Testing19%

An audit can appear in more than one area. Figures are from two published audit benchmarks: a review of 75 SOC 2 audits completed between January 2025 and June 2026, and a 2024 review of 193 SOC reports.

Most of these exceptions can be prevented with a few consistent operating practices:

1. Reconcile Offboarding Against HR Records. Auditors compare each termination date with the date of access removal, and any gap beyond your policy’s timeframe is recorded as an exception.
2. Record How Each User List Was Generated. Auditors increasingly verify that the list you reviewed was complete, and the saved query or export settings show how the list was produced.
3. Assign a Second Reviewer for the Reviewer’s Own Access. A person who reviews their own access creates a segregation-of-duties exception.
4. Open a Ticket for Every Hotfix. Emergency changes made without a ticket or approval are a frequent change management finding.
5. Include Contractors in Training and Policy Acknowledgments. Contractors are the group most often missing from training and acknowledgment records.

How Jutsu Can Help

A spreadsheet and a shared calendar can support this checklist, but keeping both accurate over a 6 to 12 month observation period is difficult for a small team.

Compliance ActivityMonitoring

Sign-in from a new locationAlert

Investigation openedLogged

MFA check on connected accountsPassed

SOC 2 evidence exportReady

Security Operations

Jutsu monitors connected cloud, identity, code and endpoint sources around the clock, triages each alert, and logs every investigation and response as it happens.

Audit Evidence

Jutsu runs posture checks on connected Google Cloud, Google Workspace and Windows systems, produces daily and weekly activity reports, and exports SOC 2 evidence for your auditor.

Learn More About Jutsu

Jutsu is not an auditor and does not guarantee an audit outcome. SOC 2 evidence exports are included from the Startup plan.

For the hands-on product steps, see how to set up SOC 2 and ISO 27001 in Jutsu.

FAQ

Does every startup need SOC 2?

No. SOC 2 is not required by law. Startups usually begin when a customer, a procurement team or a contract asks for a report. Confirm the business need and the report type before you spend money.

Is there an official SOC 2 checklist?

No. The AICPA publishes the Trust Services Criteria, which set the outcomes your controls should achieve but do not prescribe the controls. Each company decides with its auditor which controls meet each criterion.

What does a startup need for SOC 2?

A startup needs a defined scope, the controls in steps 5 to 21, a system description and a written management assertion from leadership. A licensed CPA firm then performs the audit.

How long does it take a startup to get SOC 2?

A Type 1 report can be completed within a few months when most controls are already in place. A first Type 2 takes longer because it covers a period of operation, and a common planning estimate for a first-time company is 12 to 15 months from readiness through a completed report.

How long should the Type 2 observation period be?

The AICPA does not set a minimum, and periods between 3 and 12 months are common. A shorter first period produces a report sooner, but the length should be agreed with your auditor and checked against your customers’ contract requirements before the period begins.

Do we need a penetration test for SOC 2?

No criterion requires one by name, but auditors evaluate how you test your defenses, and many customers expect to see a recent penetration test report. Most startups run a penetration test each year for both reasons.

Can a 10-person startup without a security hire do this?

Yes. The criteria are the same for every company, but a small company can meet them with simpler controls. One accountable owner with a shared calendar and an evidence collection tool can cover most of the work.

What happens if the auditor finds an exception?

A small number of exceptions is common and usually does not change the overall opinion. Many exceptions in the same area can lead to a qualified opinion, and you can include a management response in the report explaining the cause and the fix.

Is SOC 2 a certification?

No. A SOC 2 report is an attestation: a CPA firm’s opinion on your controls. No certificate is issued, and describing a company as “SOC 2 certified” is inaccurate.

Sources

• AICPA: Trust Services Criteria (revised points of focus, 2022)
• AICPA: SOC 2 description criteria
• AICPA: SOC suite of services