SOC 2 Compliance Checklist for Startups

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.

The checklist below pairs each control with the evidence auditors typically request and is written for startups of roughly 5 to 50 people without a dedicated security hire. The AICPA’s criteria does not specify controls; use these controls as a starting point, but check with your auditor, as their request list may be different.

01Define the scope

02Put the controls in place

03Run them over the period3 to 12 months

04Complete the auditAbout 9 to 14 weeks

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.

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.

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

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.

Step 1: Define the scope

Determines which criteria, systems and people the audit covers. You should have it settled and documented before any work begins.

Scope Checklist5 Items

Choose your categories.Security is required in nearly all SOC 2 report and covers 33 common criteria grouped into nine series, CC1 through CC9, while Availability, Processing Integrity, Confidentiality and Privacy are optional and together add 28 more. Most startups begin with Security and add a category as required by customers. Choose Type 1 or Type 2.A Type 1 report assesses whether your controls are designed properly as of a single date, whereas a Type 2 assesses whether they operated effectively over a period that commonly runs from 3 to 12 months. Startups facing a contractual deadline often obtain a Type 1 report first and begin the Type 2 observation period immediately afterward. Define the system boundary.Document the product, cloud accounts, databases, code repositories, internal tools, people and vendors that store or process customer data, this inventory forms the basis of your system description. Write the system description and keep it current.It covers the services, infrastructure, people, data and vendors in scope, and it needs updating whenever any of those change. Identify what your cloud provider covers.Physical data center security is typically handled by cloud providers such as AWS, Google Cloud, or Azure. When your auditor applies the carve-out method, the provider’s controls are excluded from direct testing in your SOC 2 examination. Your organization remains responsible for its own cloud configuration and security controls, including applicable complementary user entity controls (CUECs) identified in the provider’s SOC report.

Planning Suggestions

Handle these alongside the scope, before any controls are built.

Assign an OwnerOne person, often a founder or the CTO, should be accountable for the program as a whole.

Select Your Auditor EarlyOnly a licensed CPA firm can issue a SOC 2 report, and our guide on how to choose a SOC 2 auditor covers what to verify before signing an engagement letter.

Agree on the Audit Period DatesThe engagement letter and the audit period dates should be agreed on with your CPA firm before a Type 2 observation period begins.

OptionalRun a Readiness AssessmentThe assessment should be completed before any controls are built, because it identifies the gaps that Step 2 needs to close. Our post on SOC 2 gap analysis compares the options.

Write a one-page scope statement listing the categories, report type, systems and vendors in scope, along with a list of the people it covers.

For a first-time company, a common planning estimate is 12 to 15 months of calendar time from readiness through a completed Type 2 report.

Step 2: Put the Controls in Place

Each item pairs a control that auditors commonly expect at startups with the evidence they usually request, and the references in each heading indicate which Trust Services Criteria it maps to. Since SOC 2 lets each company choose controls that fit its environment, treat these as a strong baseline rather than a fixed list.

Policies and PeopleCC1, CC2, CC5

Core Policies Written and ApprovedPolicies covering information security, access control and incident response should be written and formally approved by leadership.Keep each policy with the name of the person who approved it, the approval date and the version number. Policy Acknowledgments at Hire and Every YearEvery employee and contractor should sign an acknowledgment confirming they have read the security policies.Keep the signed acknowledgments with each person’s name, the date and the policy version. Security Awareness Training at Hire and Every YearSecurity awareness training should be completed by every employee during onboarding and again each year.Keep completion records for every employee and contractor in scope. Background Checks Where Local Law PermitsEach new hire should pass a background check before receiving access to customer data.Keep a completion record for each hire, dated on or near the start date. Documented Roles and ResponsibilitiesSecurity responsibilities should be defined in each job description, and one person should be accountable for the security program.Keep an org chart and job descriptions that list security duties. Annual Leadership Review of the Security ProgramSecurity risks, incidents and open issues should be reviewed by leadership at least once a year.Keep the meeting notes or a short written sign-off from the review.

Access ControlCC6

Multi-Factor Authentication on Every In-Scope SystemEnforce multi-factor authentication for users accessing in-scope systems, either directly or through an identity provider configured to require MFA. Single sign-on simplifies centralized access management but does not replace MFA.Keep an export of the enforcement settings and a user list showing each account’s MFA status. Approved, Role-Based AccessAccess should be granted based on each person’s role and approved by someone other than the requester.Keep a ticket or request for each new account that shows who approved it. Prompt OffboardingA departing employee’s access should be removed from every system within the timeframe your policy defines. Late removal is one of the most frequent findings in first audits.Keep an offboarding checklist for each departure, with timestamps the auditor can compare against HR termination dates. Quarterly Access ReviewsAccess to each in-scope system should be reviewed every quarter, and access that is no longer needed should be removed. Failed access reviews are the most common reason for a qualified opinion in published audit data.Keep the reviewed user list, how it was pulled, the reviewer and the date. Limited Admin and Production AccessAdministrative and production access should be limited to people with a documented business need.Keep a list of privileged accounts with the justification for each. Managed Company LaptopsDisk encryption, screen lock and operating system updates should be enforced on every company laptop through a device management tool.Keep an export from your device management tool. Asset InventoryEvery in-scope system, device and data store should be listed in a maintained inventory.Keep a dated export of the inventory. Data Deletion and Device DisposalCustomer data should be deleted at the end of its retention period, and retired devices should be wiped before disposal.Keep deletion and device disposal records.

Engineering and Change ManagementCC6.7, CC7.1, CC8

Peer-Reviewed Production ChangesEvery production change should go through a pull request approved by someone other than its author.Keep your branch protection settings and the pull request history. Review of Emergency ChangesEmergency changes, or hotfixes, that bypass normal review to fix an urgent production issue should be reviewed and documented afterward.Keep a ticket for each hotfix with the later review recorded on it. Encryption at Rest and in TransitCustomer data should be encrypted in databases, storage and backups, and all connections to your service should use TLS.Keep exports or screenshots of the encryption settings and your TLS configuration. Scheduled Vulnerability ScansVulnerability scans should run on a set schedule, and each finding should be fixed within the timeframe your policy defines for its severity.Keep scan reports and tickets showing when each finding was closed, or a signed risk acceptance where it wasn’t. Annual Penetration TestYour application and infrastructure should be tested for exploitable weaknesses by an independent firm. No criterion requires a penetration test by name, but auditors and customers commonly expect one.Keep the test report and the retest results showing the findings were fixed. Separate Development and Production EnvironmentsDevelopment and testing should take place in environments separate from production.Keep a diagram or account list showing the separation.

Monitoring and Incident ResponseCC7

Centralized LoggingLogs from cloud, identity and other key systems should be collected in one place and retained for the full audit period.Keep a list of log sources, the retention settings and sample logs from early in the period. Alert Review by a Named PersonEach security alert should be investigated by a designated person or team, and the outcome should be recorded.Keep alert records showing who reviewed each one, when, and what they concluded. Written Incident Response PlanThe plan should define who leads a response, how incidents are classified and when customers are notified.Keep the approved plan. Incident LogEvery security incident, including minor ones, should be logged and handled according to the plan.Keep a timeline and post-incident notes for each incident. Annual Incident Response TestThe plan should be tested at least once a year through a tabletop exercise based on a realistic incident.Keep the exercise notes with the date, attendees and follow-up items.

Risk, Vendors and ContinuityCC3, CC9

Annual Risk AssessmentThreats to your systems and data should be identified, rated for likelihood and impact, and documented with a plan for addressing each one.Keep a dated risk register with owners, ratings and treatment plans. Vendor Inventory with Risk TiersEvery vendor that handles customer data should be listed and assigned a risk tier based on its level of access.Keep the vendor list with each vendor’s tier. Annual Review of Critical VendorsHigh-risk vendors should be reviewed each year, typically by examining their SOC 2 reports for exceptions that affect your company.Keep their current SOC 2 reports and a record of your review. Backups and Restore TestingBackups should run automatically, and restores should be tested periodically to confirm the data can be recovered.Keep the backup settings and a dated record of the restore test. Business Continuity and Disaster Recovery PlanThe plan should describe how the service continues operating or recovers after a major outage, including recovery targets and responsible owners.Keep the approved plan and a record of its most recent test.

Step 3: Run the controls throughout the audit period

A Type 2 auditor samples dated records from across the entire audit period. Each control therefore needs to operate 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 not SOC 2 requirements but they are common practice. Your own policies set each frequency, and the auditor tests whether your team followed the policies.

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 the Step 2 checklist, 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.

Step 4: Complete the audit

Final Stage ChecklistFinal Stage Checklist

Prepare the Management AssertionLeadership should sign a written statement confirming that the system description is accurate and that the controls were suitably designed and, for a Type 2, operated effectively. Respond to the Evidence RequestRequested records should be delivered by the auditor’s deadlines. 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. Review the Draft ReportA written response should be prepared for each exception before the report is finalized. Share the Report Under NDACustomers should receive the report under a nondisclosure agreement. The controls should continue operating afterward, because the next annual report covers the following period.

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.

FAQ

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 the Step 2 checklist, 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.