SOC 2 Readiness Checklist for Startups (2026): 44 Items Mapped to the Criteria and the Evidence Auditors Pull

Before you start: what "readiness" actually means

Readiness is the period before the auditor's clock starts. You are trying to reach a point where every control you will describe to the auditor exists, has an owner, and, for recurring controls, has already run at least once with evidence saved. If you are still deciding whether you need SOC 2 at all, start with our beginner's guide to SOC 2 for B2B SaaS founders. If you are still deciding between report types, read SOC 2 Type 1 vs Type 2 and the calendar math behind it first. This article assumes you have decided and need the working list.

Two facts from the AICPA's criteria document shape everything below:

• The criteria are short; the points of focus are guidance. TSP Section 100 says some points of focus "may not be suitable or relevant to the entity," and that using the criteria "does not require an assessment of whether each point of focus is addressed." You design controls that fit a 10-person company. You do not have to implement every bullet in the document.
• The Security category (the common criteria) is always in scope. Availability, Processing Integrity, Confidentiality and Privacy are optional add-ons. For a first audit, the usual advice is to add one only if a customer contract asks for it.

The criterion numbers on each item (CC6.2 and so on) come from the AICPA's 2017 Trust Services Criteria. The 2022 revision changed only the points of focus, not the criteria themselves. Your auditor will map your controls to these numbers, so it helps to speak the same language from day one.

How to read each item: the CC chip shows the criterion it supports. The evidence line is what an auditor typically asks to see. The last chip says whether a compliance platform's integrations can usually collect that evidence (tool-collectable) or whether a person has to produce it (you own it).

Scope is the cheapest place to save money and the easiest place to lose credibility. Every system you include adds evidence for every recurring control. Every system you leave out has to be defensible when a customer's security reviewer reads your system description.

• 1.1Collect the commitments that triggered the audit

  Pull the security clauses from your MSAs, DPAs, and the questionnaires that stalled deals. These become the "service commitments and system requirements" your system description is measured against.

  Evidence: contract excerpts, your public security page, the DPA template.
  System descriptionyou own it
• 1.2Pick the categories: Security, plus only what a contract demands

  Add Availability if you sign uptime SLAs that buyers expect to see covered. Add Confidentiality if contracts restrict how you retain and delete customer data. Each extra category adds criteria, and every added criterion needs controls and evidence.

  TSP 100 categoriesyou own it
• 1.3Draw the system boundary on one page

  Typically in scope: the production application, production cloud accounts, data stores holding customer data, the code repository and CI/CD pipeline, the identity provider, and the laptops of people with production access. Typically out of scope: the marketing site, sales tooling, and internal analytics that never receive customer data.

  Evidence: architecture and data-flow diagram, list of in-scope cloud accounts and projects.
  CC2.1CC6.1you own it
• 1.4List subservice organizations and get their SOC reports

  Your cloud host, payment processor, auth provider, and any LLM API that receives customer data. Most startups use the carve-out method: the auditor doesn't test AWS's data centers, but you must show you reviewed AWS's own report and the controls it expects you to run.

  Evidence: each vendor's current SOC 2 report or bridge letter, plus your review notes.
  CC9.2partly tool
• 1.5Map the complementary controls in both directions

  Write down the controls your vendors expect you to operate (for example, AWS expects you to manage IAM). Then write down what you expect your customers to do, such as managing their own users and enabling SSO in your product. The second list becomes your complementary user entity controls (CUECs).

  System descriptionyou own it
• 1.6Fix the in-scope population of people

  Employees and contractors who touch in-scope systems. This list becomes the population auditors sample for onboarding, training, background checks and offboarding, so it must match your HRIS and identity provider.

  Evidence: HRIS export reconciled to IdP user list.
  CC1.4CC6.2tool-collectable
• 1.7Choose Type 1 or Type 2, and the window

  This decides when recurring controls must start producing evidence. A Type 2 window can't begin until your controls are live. Our Type 1 vs Type 2 guide walks through the three common paths and their calendars.

  you own it

This is where startups feel most out of place. The criteria talk about boards, accountability and competence because they inherit the COSO internal-control framework. You don't need a corporate structure you don't have. You do need to describe how oversight really works at your size, and keep proof that it happened.

• 2.1Name a security owner and publish an org chart

  One accountable person (often the CTO at seed stage) with security responsibilities written into their role. Keep the org chart current; auditors compare it against the people list from 1.6.

  Evidence: org chart, role description with security duties.
  CC1.3you own it
• 2.2Document oversight, then hold the meetings

  CC1.2 expects the board to exercise oversight of internal control. For a small company, that can be a recurring security review with the board or founders, covering risks, incidents and open deficiencies. Keep the minutes. Placeholder minutes were among the fabricated artifacts alleged in 2026's biggest compliance-platform scandal (see Phase 6).

  Evidence: dated agendas and minutes, attendee list.
  CC1.2CC2.2you own it
• 2.3Code of conduct and acceptable-use policy, signed at hire

  Each in-scope person acknowledges both. A sample of hires from the window will be checked for signatures dated near their start date.

  Evidence: signed acknowledgments per sampled hire.
  CC1.1tool-collectable
• 2.4Background checks, as your policy defines them

  A point of focus under CC1.4 is "Considers the Background of Individuals." Decide what you check, for whom, and in which countries local law allows it, then apply it consistently. Include contractors if they get production access.

  Evidence: completion record for each sampled hire.
  CC1.4partly tool
• 2.5Security awareness training at hire and every year

  This is the classic sampled control. CPA firm Linford & Co. uses it as its worked sampling example, so expect completion dates to be checked person by person.

  Evidence: training completion report with dates.
  CC1.4CC2.2tool-collectable
• 2.6Write the policy set, approve it, and version it

  At minimum: information security, access control, change management, incident response, risk management, vendor management, business continuity and disaster recovery, data classification and retention, and acceptable use. CC5.3 is literally "deploys control activities through policies… and procedures." Approval dates must precede the window.

  Evidence: policies with owner, version and approval date; acknowledgment records.
  CC5.3CC2.2templates from tool, content is yours
• 2.7Make accountability real: a sanctions clause and performance reviews

  CC1.5 asks that individuals are held accountable for control responsibilities. A disciplinary clause in the security policy, plus reviews that mention security duties for the owners, covers it.

  CC1.5you own it
• 2.8Give customers a way to report incidents and see commitments

  A point of focus under CC2.3 says external users get information on how to report system failures, incidents and concerns. A security page with a contact address and a published subprocessors list usually covers it.

  Evidence: URL of the security page, support or security inbox, customer notification template.
  CC2.3you own it

Auditors read the risk assessment to judge whether your controls respond to your risks. A generic list of ten risks with default ratings tells them you didn't do one.

• 3.1Run a real risk assessment

  Identify threats to the in-scope system, rate likelihood and impact, name an owner and a treatment, and link each treated risk to the controls that address it. Repeat it at least annually and whenever the system changes significantly. CC3.4 asks you to assess changes that could affect internal control.

  Evidence: dated risk register with ratings, owners, treatment decisions and approval.
  CC3.1CC3.2CC3.4you own it
• 3.2Include fraud risk explicitly

  CC3.3 is its own criterion. Its points of focus cover incentives, opportunities and "risks related to the use of IT and access to information." For a startup, that means asking who could change production data or billing without detection.

  CC3.3you own it
• 3.3Build the vendor inventory and rate each vendor

  Every vendor that stores, processes or can access customer data, rated by criticality. For critical vendors, collect the SOC report, sign a DPA or confidentiality terms, and record a periodic review. The CC9.2 points of focus also include an offboarding procedure for vendors.

  Evidence: vendor list with criticality, review dates, reports on file, signed confidentiality terms.
  CC9.2partly tool
• 3.4Treat LLM and AI APIs as vendors, not as libraries

  The common 2026 gap: an engineer wires a model API into a support or analytics feature, and customer data now flows to a party missing from your vendor list and subprocessor page. Add every AI provider that receives customer data, record its data-retention and training terms, and reflect it in 1.4.

  CC9.2CC3.4you own it
• 3.5Write a business continuity and disaster recovery plan

  CC9.1 covers business-disruption risk. Its points of focus also include considering insurance, so note your cyber policy if you have one. Keep the plan short and specific: who declares a disaster, the recovery targets, the restore procedure, and the order in which services come back.

  Evidence: approved BC/DR plan; insurance certificate if referenced.
  CC9.1you own it
• 3.6Inventory and classify assets and data

  A point of focus under CC6.1 is "Identifies and Manages the Inventory of Information Assets." Maintain a list of devices, cloud resources and data stores with a classification, such as public, internal, confidential, or customer data.

  Evidence: asset inventory export; data classification policy.
  CC6.1tool-collectable

This is the part engineers expect, and the part compliance platforms automate best. The trap is configuring the control once and forgetting that the auditor tests whether it operated throughout the window.

Access (CC6.1–CC6.3)

• 4.1SSO and MFA on the identity provider, cloud consoles and code host

  The criteria don't say "MFA." CC6.6 lists "Requires Additional Authentication or Credentials" as a point of focus. Buyers' questionnaires ask for MFA directly, though, and auditors expect it for administrative access. Enforce it centrally instead of hoping each person turns it on.

  Evidence: IdP policy screenshot or config export; per-user MFA status.
  CC6.1CC6.6tool-collectable
• 4.2Approved access before credentials are issued

  CC6.2 says it outright: before issuing credentials, the entity "registers and authorizes" new users. Use a ticket or HRIS-triggered workflow showing who approved which access, dated before the account was created.

  Evidence: access request tickets for sampled new hires, with approval timestamp ≤ account creation.
  CC6.2partly tool
• 4.3Offboarding within a defined deadline

  Same criterion, second half: credentials are removed when access is no longer authorized. Pick a deadline you can meet (for example, the termination date or the next business day), write it into the policy, and compare termination dates with deprovisioning dates in every system.

  Evidence: termination list vs. IdP and cloud deprovisioning logs for sampled leavers.
  CC6.2CC6.3tool-collectable
• 4.4Periodic user access reviews with recorded decisions

  A point of focus under CC6.3 is "Reviews Access Roles and Rules… on a periodic basis." Quarterly is common. The evidence is the reviewer's decision on each account (keep or remove) and proof that removals happened. A list exported and never looked at doesn't count.

  Evidence: review record per quarter: reviewer, date, decisions, follow-up tickets.
  CC6.3you own it (tool runs the workflow)
• 4.5Least privilege in production, with a break-glass path

  The common gap is standing database access for every developer. Scope production access to roles. Grant elevated access just in time where you can, and log break-glass use.

  CC6.3partly tool

Data, endpoints and network (CC6.5–CC6.8)

• 4.6Encrypt data at rest and in transit, and protect the keys

  The CC6.1 points of focus include "Uses Encryption to Protect Data" and "Protects Encryption Keys." CC6.7 covers transmission. In practice: storage and database encryption enabled, TLS everywhere, and keys in a managed KMS with restricted access.

  Evidence: cloud config showing encryption; TLS config; KMS key policies.
  CC6.1CC6.7tool-collectable
• 4.7Manage endpoints: disk encryption, screen lock, updates, anti-malware

  CC6.8's points of focus include restricting software installation and using anti-malware. CC6.7 adds protecting mobile devices. An MDM or a lightweight device agent produces this evidence for every laptop continuously.

  Evidence: device compliance report for in-scope people.
  CC6.7CC6.8tool-collectable
• 4.8Boundary protection: no public databases, reviewed firewall rules

  CC6.6 covers threats from outside the system boundary. Use security groups and WAF rules with least exposure, and treat any publicly reachable data store as a deficiency.

  CC6.6tool-collectable
• 4.9Data disposal and media handling

  CC6.5 asks that protections stay in place until data can no longer be recovered. Document how laptops are wiped on return and how customer data is deleted at contract end. Physical security (CC6.4) is usually inherited from your cloud provider through the carve-out in 1.4. If you keep no office servers, say so in the system description.

  CC6.4CC6.5you own it

Operations and incidents (CC7)

• 4.10Vulnerability and configuration monitoring with remediation deadlines

  CC7.1 points of focus: defined configuration standards, change detection, detecting unauthorized components, and vulnerability scans. Scan infrastructure and dependencies, set remediation deadlines by severity in policy, and track that you meet them.

  Evidence: scan reports, tickets showing critical/high findings closed within your stated deadline.
  CC7.1tool-collectable
• 4.11Centralized logging and alerting that someone answers

  CC7.2 covers monitoring for anomalies, and one of its points of focus is "Monitors Detection Tools for Effective Operation." Send cloud audit logs and application auth logs to one place, alert on a defined set of events, and route alerts to an on-call person.

  Evidence: logging config, alert rules, a sample of alerts with a response recorded.
  CC7.2partly tool
• 4.12Incident response plan plus at least one tabletop exercise

  CC7.3–CC7.5 run from triage to recovery. Among the CC7.5 points of focus is "Implements Incident-Recovery Plan Testing." If you had no real incident in the window, the tabletop is the evidence that the plan works, so run it before the window ends.

  Evidence: IR plan; tabletop write-up with date, scenario, attendees and lessons learned; incident tickets if any.
  CC7.3CC7.4CC7.5you own it
• 4.13Backups, and a restore test you can prove

  Enabled backups are configuration. A restore you performed and timed is evidence. Do one before the window and repeat it on the schedule in your BC/DR plan.

  Evidence: backup config; restore test record with date and result.
  CC7.5CC9.1partly tool

Change management (CC8.1)

• 4.14Every production change is reviewed, tested and traceable, including emergencies

  CC8.1 is one criterion with a long list of points of focus: authorize, design, document, track, test, approve, deploy, and "Provides for Changes Necessary in Emergency Situations." For most startups this means branch protection on the main branch, at least one reviewer who isn't the author, CI tests that must pass, and infrastructure-as-code changes going through the same pull-request flow. Write down an emergency-change path that requires review after the fact, so hotfixes don't become exceptions.

  Evidence: branch protection settings; a sample of merged PRs showing approver ≠ author and passing checks; emergency-change log.
  CC8.1CC5.2tool-collectable

• 5.1Combine continuous monitoring with a periodic separate evaluation

  CC4.1's first point of focus is "Considers a Mix of Ongoing and Separate Evaluations." A compliance platform's automated tests are the ongoing part. A quarterly or semi-annual review where the security owner checks every control's status is the separate part, and it should leave a record.

  CC4.1partly tool
• 5.2Decide on a penetration test, and know why

  Penetration testing appears in the criteria only as an example of a separate evaluation under CC4.1, not as a requirement. In practice, many customers ask for an annual pentest letter during due diligence. Drata puts a pentest at roughly $5,000–$15,000. If you commission one, fix the high-severity findings before the window starts, or record them in 5.3.

  CC4.1you own it
• 5.3Keep a deficiency log with owners and dates

  CC4.2 asks that deficiencies are communicated to the people responsible for fixing them, including senior management, in a timely way. A ticket queue tagged "control deficiency," reviewed in the oversight meeting from 2.2, closes the loop.

  CC4.2you own it

In a Type 2 audit, the auditor doesn't look at every pull request or every new hire. They ask for a complete population, such as all hires in the window or all production changes, and test a sample. Your readiness work should assume that sample will include your worst week.

• 6.1Make every recurring control's population exportable

  For each recurring control, know which system produces the complete list: HRIS for hires and leavers, the code host for merged changes, the ticketing tool for access requests and incidents. If you can't produce a complete population, the auditor can't sample it.

  tool-collectable
• 6.2Plan for exceptions to expand the sample

  The AICPA sets no fixed SOC 2 sample sizes; the auditor decides using professional judgment. Linford & Co.'s worked example shows how fast a few misses compound for a control with a large population, such as training completions across 389 people:

  25initial sample, zero deviations expected

  40sample after one deviation

  60after a second; a third means the control failed

  For small populations, such as a monthly reconciliation where three months are tested, the same article notes that any deviation is a failure of operating effectiveness. Automated controls need far fewer samples: Strike Graph's auditor-facing guide says they "typically only require one sample, regardless of frequency or risk." That's one more reason to automate the recurring items above.

  you own it
• 6.3Evidence comes from the system of record, dated inside the window

  Prefer exports and API pulls over screenshots, and make sure dates fall inside the period under audit. Name files by control, for example CC6.2_offboarding_2026-Q4.csv, so the request list maps to the evidence one to one.

  tool-collectable
• 6.4Choose the CPA firm deliberately, not as a bundle afterthought

  A SOC 2 report can only be issued by a licensed CPA firm. Check the firm in the AICPA Peer Review Public File, ask how many SOC examiners will work on your engagement, and ask for a redacted sample report. Many compliance platforms refer customers to partner firms. The firm still has to be independent of the platform's sales promises.

  you own it
• 6.5Run a readiness assessment (gap analysis) before the window

  Either your auditor, a consultant, or your compliance platform's built-in tests can do it. The output is a list of missing or weak controls mapped to criteria, which becomes your remediation backlog. Drata puts an external gap assessment at $5,000–$25,000.

  partly tool
• 6.6Draft the system description and walk it through with the auditor

  Management writes the system description; the auditor tests against it. Draft it from items 1.1–1.5 and review it with the auditor before fieldwork. A mismatch between what you describe and what you operate becomes an exception.

  you own it

What the criteria say vs. what auditors and buyers expect

Many checklists present every item as "required by SOC 2." That's not how the framework works, and knowing the difference helps you push back on scope creep. A buyer's questionnaire can still require what the criteria don't.

The rule that matters more than any row: whatever you write in a policy becomes a control you will be tested against. A policy promising monthly access reviews, when you run them quarterly, produces two failed months per quarter. Write the frequency you will actually keep.

What a compliance platform does (and doesn't) take off the list

Of the 44 items, 13 are marked tool-collectable, 10 are partly handled by a tool, and 21 are owned by a person. Platforms such as Vanta, Drata and Secureframe connect to your cloud, identity provider, HRIS, code host and devices, then run continuous tests. That covers most of Phase 4 and the evidence mechanics in Phase 6. They also ship policy templates and run training and access-review workflows. What they can't do is make the decisions: what's in scope, what your risks are, who keeps which access, and whether the tabletop exercise taught you anything.

Prices are AWS Marketplace list prices and official pricing pages, checked in October 2026. Negotiated quotes often differ. The audit fee is separate: Drata's cost guide puts a Type 1 at $7,500–$15,000 and a Type 2 at $12,000–$20,000 for small to midsize companies. For a broader shortlist, see our comparison of SOC 2 automation tools and our compliance tool picks for early-stage startups. For the full budget picture, see SOC 2 cost and timeline.

Platform vs. spreadsheet: the trade-off for a first audit

A spreadsheet and shared drive can work for a very small team with a simple stack, especially for a Type 1. The cost shows up later. Every recurring control in a Type 2 window means someone pulling and filing evidence by hand, on schedule, for the whole period.

A 12-week readiness plan

The plan below is our planning example for a team of roughly 5–30 people on a single cloud provider, aiming for a Type 2 window to start after readiness. It's not a vendor promise. Your pace depends mostly on how many engineering changes Phase 4 requires.

FAQ

How we researched this

We extracted all 33 common criteria and their points of focus from the AICPA's TSP Section 100 (2017 Trust Services Criteria, with the March 2020 updates). We then turned each criterion into the controls a small SaaS company typically operates, and noted the evidence an auditor would request. Sampling behavior comes from a CPA firm's published guidance (Linford & Co.) and Strike Graph's sampling guide. Cost figures come from Drata's published cost guide, and platform prices from AWS Marketplace listings and official pricing pages, checked in October 2026. The "tool-collectable" labels reflect what integration-based platforms generally automate. Confirm specifics with the vendor and your auditor. The 12-week plan is our own planning example, not a guaranteed timeline. We have no affiliate relationship with any vendor named here.

References & sources

1. AICPA, TSP Section 100: 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with March 2020 updates) — PDF copy; current 2022 revised points of focus at aicpa-cima.com
2. Linford & Co. LLP, "Audit Sampling in SOC Examinations" (updated April 23, 2025) — linfordco.com/blog/audit-sampling/
3. Journal of Accountancy, "Promises of 'fast and easy' threaten SOC credibility" (February 1, 2026) — journalofaccountancy.com
4. IANS Research, "Delve Allegations Expose Weak Points in Modern Compliance" (March 2026) — iansresearch.com
5. Drata, "SOC 2 Audit Cost" — drata.com/blog/soc-2-audit-cost
6. Strike Graph, "SOC 2 Type 2 population and sampling guide" — help.strikegraph.com
7. AICPA & CIMA, Peer Review "For the Public" (Public File search) — aicpa-cima.com
8. AWS Marketplace listings: Vanta, Drata, Secureframe; Secureframe pricing

Ken Hayashi

Technology consultant with 10+ years in the Japanese tech industry. Specializing in SaaS evaluation, workflow automation, and B2B tool integration.