SOC 2 Checklist (2026): A Founder's Field Guide to Your First Audit (+ Free Template)

If you're reading this, one of two things is probably happening. Either an enterprise prospect just asked for your SOC 2 report and you don't have one — and now there's a million-dollar deal sitting in limbo while you figure out what that means. Or your board has flagged it as table-stakes for the next funding round, and someone (likely you) has been deputized to make it happen.

Both versions of that conversation tend to start the same way: how hard can it be?

Honest answer: not technically hard, but operationally heavy. SOC 2 isn't a cybersecurity test you pass or fail. It's a months-long project that touches every team in the company, generates hundreds of pages of documentation, and ends with a CPA firm writing a report your customers will read. The good news is that the path is well-worn — the AICPA framework is stable, the cost curves are predictable, and there are exactly three or four decision points that actually matter.

This guide is the version we wish we'd had when we started our own. What SOC 2 is. What it costs in 2026. How long it really takes. The 64 control areas auditors test against. And the readiness checklist we now use to scope every engagement. Two free downloads at the bottom — a working XLSX readiness tracker and a printable evidence request list you can hand straight to your team.

• Get the Free SOC 2 Toolkit – SOC 2 Readiness Checklist (XLSX) — all 64 Common Criteria controls, status tracking, evidence mapping, gap-analysis tab –

Download Free SOC 2 Toolkit – SOC 2 Readiness Checklist →

• Evidence Request List (DOCX) — the artifacts your auditor will actually ask for, organized by department owner

Download Evidence Request List (DOCX) →

What SOC 2 actually is (the version that fits in a sentence)

SOC 2 is a report — not a certification — issued by a licensed CPA firm that evaluates how a service organization protects customer data against the AICPA's Trust Services Criteria.

A few precise things to internalize from that sentence:

It's an attestation, not a certification. Nobody "issues" you a SOC 2. A CPA firm examines your controls, writes a report describing what they found, and you share that report with customers. There is no badge, no certificate, no plaque. There is a PDF. The PDF is the deliverable.

It's governed by the AICPA. Specifically, the 2017 Trust Services Criteria with Revised Points of Focus 2022. The criteria themselves haven't changed since 2017 — only the "points of focus" (the AICPA's interpretive guidance) were updated in 2022 to reflect newer risks like cloud, supply chain, and AI. Anyone telling you SOC 2 was "updated in 2024 or 2025" is selling you something.

It evaluates a service organization. That's the legal term for any company that processes data on behalf of another company. Most B2B SaaS companies are service organizations. Your customers are the "user organizations" relying on your controls.

It's voluntary. No law requires SOC 2. It becomes effectively mandatory the moment a customer makes it a condition of contract — which, for most B2B SaaS above ~$50K ACV, happens quickly. SOC 2 unblocks revenue; it doesn't create it.

The five Trust Services Criteria, demystified

SOC 2 evaluates against five categories. You don't have to include all of them in your report. You scope based on what your service actually does and what your customers expect.

Security (mandatory). Also called the Common Criteria. This is in every SOC 2 report and structured as nine sub-categories: CC1 (Control Environment), CC2 (Communication & Information), CC3 (Risk Assessment), CC4 (Monitoring), CC5 (Control Activities), CC6 (Logical & Physical Access), CC7 (System Operations), CC8 (Change Management), CC9 (Risk Mitigation). About 33 individual criteria total under Security alone.

Availability. System uptime and operational resilience. Include this if you sell uptime SLAs to your customers — which most SaaS companies do. About 3 additional criteria.

Processing Integrity. Data is processed completely, accurately, and on time. Include this if you do something computational with customer data where wrong outputs cause real harm — payments, payroll, analytics, billing. About 5 additional criteria.

Confidentiality. Protection of information designated as confidential (NDAs, IP, business data). About 2 additional criteria.

Privacy. Handling of personally identifiable information against the AICPA's Generally Accepted Privacy Principles (GAPP). About 18 additional criteria. Many companies handle this through GDPR/CCPA programs and skip Privacy in their SOC 2.

For a typical first-time B2B SaaS report, the answer is Security + Availability + Confidentiality. That's the most common scope, and it covers the questions enterprise buyers actually ask. Adding Privacy or Processing Integrity should be deliberate — each one means more controls, more evidence, more audit hours, and a bigger bill.

SOC 2 Type 1 vs Type 2: which one do you actually need?

Two report types, and most first-time founders pick the wrong one because their auditor doesn't fully explain the tradeoff.

Type 1 is a point-in-time snapshot. The auditor looks at your controls as designed on a single date. They confirm you have a password policy, an access review process, an incident response plan, and so on. They don't test whether those things actually run. Type 1 takes 3-4 months from kickoff and the audit fee runs around $5,000 to $20,000.

Type 2 evaluates whether your controls actually operated effectively over an observation period of 3 to 12 months. The auditor pulls samples — show me 25 access requests from the last six months and prove each one was approved — and tests them. Type 2 takes 6-12 months total and the audit fee runs $7,000 to $100,000 depending on scope and firm.

Which to pick. If you have a deal blocked right now and you need something in 90 days, Type 1 is the bridge. Most enterprise buyers will accept it as proof you're serious, with a written commitment that Type 2 follows in the same year. If you have 9-12 months of runway and your buyers are large enterprises, skip Type 1 entirely. Go straight to Type 2. Most buyers ultimately demand it, and you'll save money by not paying for two audits.

The most common pattern in 2026: a Type 1 report in month 4, then a 6-month observation period, then a Type 2 report in month 10-11. The Type 1 unblocks deals; the Type 2 keeps them. Some auditors bundle both for a 10-20% discount.

What SOC 2 actually costs in 2026

This is the section every founder skips to. Real numbers, current as of Q2 2026, triangulated across published quotes from Sprinto, Drata, Secureframe, Scytale, StrongDM, and direct quotes our customers have shared with us.

Realistic totals:

• Lean startup, Type 2 only, automation-heavy: $25,000-$40,000 first year
• Standard SMB SaaS, Type 1 → Type 2, mid-tier audit firm: $45,000-$80,000 first year
• Mid-market with enterprise buyers, Big 4 audit: $80,000-$200,000+ first year
• Annual maintenance from year 2: $15,000-$40,000

A few cost-control tactics that actually work:

Don't go Big 4 unless a buyer requires it in writing. A specialist firm (Johanson Group, Sensiba, Schellman, A-LIGN, BARR Advisory, Insight Assurance) gives you the same SOC 2 report for 30-40% less. The deliverable is identical.

Use an automation platform. The math on Vanta/Drata/Secureframe/Sprinto/Scytale isn't subtle. They cost $5K-$30K/year and they save you 100-200 hours of evidence collection. A senior engineer's time at fully loaded cost makes the platform pay for itself inside the first quarter.

Negotiate. Compliance automation is a brutally competitive market right now. Secureframe is currently price-leading at around $5K-$7K/year for startups to win share. Vanta and Drata will match. Quote three, take the best, send the screenshot.

Don't skip the readiness assessment if you're starting from zero. Auditors charge $5K-$15K per remediation cycle when they find gaps mid-audit. A $10K readiness assessment that surfaces those gaps in advance pays for itself many times over. If you don't have a security lead on payroll yet, a fractional CISO or boutique advisory firm can run the readiness for you. Our sister firm YSecurity is one of the shops that does this kind of advisory work — same founders as Cyberbase, different motion (services rather than software). Disclosure aside, there are plenty of good ones, and you should get two or three quotes before signing.

The realistic timeline (with the parts nobody warns you about)

A clean Type 2 timeline looks like this. Add 1-2 months at the front if you're starting from a true zero.

Month 0 — Decision and scope. Pick your TSCs. Pick Type 1 vs Type 2 (or both, sequenced). Pick your audit firm. Pick your automation platform if you're using one. Assign a single owner — someone senior enough to cut through company politics, technical enough to be efficient with engineering's time. This is rarely the CTO. It's often the head of security, or in early-stage companies, the COO or a senior eng manager. If nobody on the team fits that profile, this is the moment to bring in a fractional CISO or services partner (YSecurity is one option — it's our sister services firm, same founders as Cyberbase) rather than try to wing it from internal headcount alone.

Months 1-2 — Readiness. Gap analysis against the criteria. Draft or update your policies (information security, acceptable use, access control, change management, incident response, business continuity, vendor management, data classification — at minimum). Implement missing controls. The big rocks: SSO, MFA enforcement everywhere, EDR on every endpoint, centralized logging, vulnerability scanning, employee onboarding/offboarding workflow.

Months 2-3 — Evidence baseline. Start the evidence machine. Access reviews. Change management tickets. Vulnerability scan reports. Backup test results. Employee training completion. Vendor risk assessments. If you're using a compliance platform, this is when its integrations earn their cost — pulling evidence from AWS, GitHub, Okta, Jira, MDM, and your HRIS automatically.

Month 3-4 — Type 1 audit (if doing one). Auditor reviews your controls as designed. Walks through evidence samples from one point in time. Issues the Type 1 report. You can hand this to prospects.

Months 4-9 — Observation period. This is the part founders forget. The auditor needs to see your controls running over time. You can't shortcut it. What you can do is make the evidence collection painless — which is the entire point of a compliance automation platform.

Months 9-10 — Type 2 fieldwork. Auditor pulls samples from the observation period. Show me 25 random access changes. Show me your last quarter's vulnerability scans. Show me three terminated employees and prove their access was removed within SLA. Findings get raised, you remediate, the report gets drafted.

Month 10-12 — Report issuance. Auditor issues the Type 2 report. You publish it (carefully — most SOC 2 reports are confidential and shared under NDA, not posted publicly). You add it to your Trust Center. You start using it in sales cycles.

Month 13+ — Ongoing. Annual re-audit. Continuous evidence collection. Quarterly access reviews. New control rollouts as the business changes. SOC 2 isn't a project. It's an operating mode.

The 64-point SOC 2 controls checklist (Common Criteria)

This is the substance of what auditors test against. Each item below maps to a specific AICPA criterion and represents a control you'll need to design, implement, and produce evidence for. The full mapping with status tracking is in the downloadable XLSX; the abbreviated version below is what we use in initial scoping calls.

CC1 — Control Environment (5 controls)

• Documented commitment to integrity and ethical values (Code of Conduct)
• Board or executive oversight of internal control
• Organizational structure with defined reporting lines and authority
• Documented commitment to attracting, developing, and retaining competent staff
• Accountability assigned for internal control responsibilities

CC2 — Communication & Information (3 controls)

• Information identification and quality processes (data classification scheme)
• Internal communication of objectives and responsibilities (security awareness)
• External communication including incident notification to affected parties

CC3 — Risk Assessment (4 controls)

• Documented entity-level objectives clear enough to identify risks
• Formal risk identification and analysis process (annual at minimum)
• Fraud risk assessment as a distinct exercise
• Process for identifying and responding to changes that could impact controls

CC4 — Monitoring Activities (2 controls)

• Ongoing or separate evaluations of internal control effectiveness
• Process for evaluating and communicating control deficiencies

CC5 — Control Activities (3 controls)

• Selection and development of control activities to mitigate identified risks
• Selection and development of general technology controls
• Deployment of control activities through documented policies and procedures

CC6 — Logical & Physical Access (8 controls)

• Logical access provisioning, modification, and removal procedures
• User registration and authorization process (joiner/mover/leaver)
• Authentication mechanisms — MFA enforced, password complexity, session management
• Privileged access controls including JIT and approval workflows
• Termination/role-change access removal within documented SLA
• Restriction of physical access to facilities and protected information assets
• Disposal procedures for physical media and printed information
• Encryption of data at rest and in transit (TLS 1.2+ minimum)

CC7 — System Operations (5 controls)

• Vulnerability management program with severity-based remediation SLAs
• Detection of unauthorized or anomalous activity (SIEM/EDR)
• Documented incident response plan with defined roles and escalation
• Incident communication to affected internal and external parties
• Recovery procedures and tested business continuity / disaster recovery

CC8 — Change Management (1 control)

• Authorized changes to infrastructure, data, software, and procedures, with documented approval, testing, and rollback procedures

CC9 — Risk Mitigation (2 controls)

• Vendor and business partner risk management program (third-party risk)
• Business continuity and disaster recovery, with tested recovery objectives

Plus, if scoped:

A1 — Availability (3 controls). Capacity monitoring, environmental protections, recovery testing.

C1 — Confidentiality (2 controls). Identification and protection of confidential information, secure disposal.

PI1 — Processing Integrity (5 controls). Inputs, processing, outputs, and stored data accuracy.

P1-P8 — Privacy (18 controls). Notice, consent, collection, use/retention/disposal, access, disclosure, quality, monitoring.

For a typical first-time SOC 2 scoped to Security + Availability + Confidentiality, you're looking at about 38 distinct control areas, each requiring documented design, implementation, and evidence. The downloadable checklist tracks all 38 (and the additional 23 if you scope in Privacy and Processing Integrity).

The evidence collection problem (and how to solve it)

Here's what nobody tells you in the sales pitch from a compliance automation vendor: about 70% of SOC 2 effort is evidence collection. The auditor doesn't take your word for anything. Every control needs an artifact — a screenshot, a config export, a log sample, a signed policy, a ticket, a meeting note.

A few categories of evidence the auditor will absolutely ask for:

• Policies (signed, dated, with version history) — Information Security, Access Control, Change Management, Incident Response, Business Continuity, Vendor Management, Data Classification, Acceptable Use, Code of Conduct, Risk Management, Data Retention. About 11 policies minimum.
• Procedures for joiner/mover/leaver, change approval, incident response runbooks, access reviews, vulnerability remediation
• Configuration evidence — SSO, MFA enforcement screenshots, encryption settings, logging configuration, backup configuration
• Operational evidence (samples from the observation period) — access review records, change tickets with approvals, terminated user access removal, completed training, vulnerability scan reports, pen test reports, vendor risk assessments
• HR records — background check confirmations, signed NDAs, completed security training (with completion dates)
• Vendor records — current SOC 2/ISO 27001 reports for your critical sub-processors, signed DPAs

The full evidence list — what you need, who in your company owns it, and what file format the auditor expects — is in the downloadable evidence request list. It's the same document we hand to engineering, HR, IT, and legal at kickoff. Saves about three weeks of "wait, who has that?"

Where automation actually helps (and where it doesn't)

Honest read on the SOC 2 tooling market in 2026:

Where the platforms (Vanta, Drata, Secureframe, Sprinto, Scytale, etc.) are genuinely useful:

• Continuous evidence collection from your cloud infrastructure (AWS configs, EDR coverage, SSO/MFA enforcement, MDM compliance)
• Pre-built policy templates you can adapt instead of writing from scratch
• A control inventory mapped to AICPA criteria so you don't have to build the spreadsheet
• Auditor portal integrations that hand evidence directly to your audit firm
• Continuous monitoring for control drift between audits

Where they don't help much:

• The actual decisions — scope, TSCs, audit firm choice, Type 1 vs Type 2
• Negotiating with the auditor
• Documenting things that don't have an API integration (board minutes, formal risk assessments, policy approvals, training completion when you don't use their LMS)
• Anything involving humans agreeing to do things differently — which is most of CC1 and CC2

The honest math: for a first-time SOC 2 at a 20-100 person company, an automation platform pays for itself. For a 5-person company doing the bare minimum Type 1, you can probably get away with a spreadsheet, a good auditor, and a long weekend. For an enterprise with mature security tooling, the platform is essential because manual evidence collection at that scale is unworkable.

The 7 mistakes founders make on their first SOC 2

A non-exhaustive list, in rough order of how often we see them:

1. Picking Type 1 when Type 2 is what the buyer actually needs. Read the contract clause. If it says "current SOC 2 Type 2 report," Type 1 doesn't satisfy it.

2. Scoping in too many TSCs. Privacy adds 18 controls, a full process for handling data subject requests, and a separate evidence stream. Unless a customer has explicitly asked for it in writing, leave it out of year one.

3. Hiring a Big 4 firm by reflex. Unless a buyer requires it, you're paying 30-40% more for the same report.

4. Treating it as an engineering project. SOC 2 is a cross-functional project. HR, Legal, Finance, IT, Engineering all have evidence to produce. If engineering owns it alone, the HR controls (background checks, training, NDAs) get neglected and the audit slips.

5. Underestimating the observation period. The auditor cannot compress time. If your audit window is "the last six months," it has to actually be six months. Plan accordingly.

6. Posting the SOC 2 report publicly. Most reports are confidential and meant to be shared under NDA. Public-share the SOC 3 (the general-use version) and gate the SOC 2 in a Trust Center.

7. Treating the report as the finish line. Year two starts the day year one ends. The annual re-audit comes around fast, and the controls you nailed at audit time tend to drift if nobody's watching.

After you have the report: how to actually use it in sales

A SOC 2 report is a piece of leverage, not a deliverable. The companies that get the most out of it treat it as raw material for a much larger trust motion:

Publish the SOC 3. It's the general-use version of the same audit, designed to be shared publicly. Most companies forget to ask their auditor for it. It costs almost nothing extra and gives you something to put on your website without distributing the full Type 2.

Put it behind a Trust Portal, not an email request. When a prospect asks for your SOC 2, you don't want a salesperson scrambling to find legal to send an NDA to forward to a contact to download a PDF. You want them clicking a link, accepting an NDA inline, and downloading instantly. That's what a Trust Portal does. (We build one. It's free forever — that's not a bait-and-switch, Cyberbase Trust Centerl is genuinely zero-cost. Competitors charge $6K-$15K+/year for the same thing.)

Pre-load the answers to questionnaires that will reference it. Your SOC 2 report is going to be the source of truth for ~60% of every security questionnaire you receive going forward. An AI-native DDQ engine that draws answers from your report, your policies, and your evidence files turns a 200-question SIG from a two-week project into a 90-minute review. One of our customers, Augment Code, used this approach to cut 743 hours out of their security questionnaire and contract workload across 155 contracts in a single quarter — about 13:1 ROI on the platform.

Use it to shorten future audits. The work you do for SOC 2 maps directly to ISO 27001, HIPAA, FedRAMP Low, and most state privacy laws. The AICPA publishes official mappings to NIST 800-53 and CSA CCM. When you're ready for the next framework, you're starting from 60-70% completion, not zero.

Get the free SOC 2 toolkit

Two downloads. No email gate. Both work on day one.

SOC 2 Readiness Checklist (XLSX)

A working spreadsheet that tracks every control you need for a first SOC 2 audit. Built from real engagements, not theory.

What's inside (7 tabs):

• README — How to use it, scoping logic, abbreviations
• Scoping Decisions — TSC selection, Type 1/Type 2 decision, scope rationale
• Common Criteria Tracker — All 64 controls across CC1-CC9, with status, owner, evidence reference, and reviewer notes
• Optional TSCs — Availability, Confidentiality, Processing Integrity, Privacy controls (scope in as needed)
• Evidence Tracker — 47 standard SOC 2 artifacts with department owner and status
• Gap Analysis — Auto-calculated readiness score with conditional formatting
• Project Timeline — Phase-by-phase with milestone dates

Download the SOC 2 Readiness Checklist →

Evidence Request List (DOCX)

The single document we hand to engineering, HR, IT, legal, and finance at the start of every SOC 2 engagement. Lists every artifact your auditor will ask for, organized by department owner, with file format and naming conventions.

What's inside:

• 47 evidence artifacts across 8 categories (Governance, Access, Change, Operations, IR, Vendor, HR, Privacy)
• Department owner for each artifact
• File format expectations (auditors are picky)
• Naming conventions that survive an audit
• Sign-off block for each owner

Download the Evidence Request List →

Both downloads are free, both are unbranded enough to use inside your own program, and both are built from real audits we've helped customers run. Take them, modify them, send them around your team. If they save you a week, we did the job.

Two ways we can help

Getting a SOC 2 report is one project. Using it well is a much longer one. Depending on where you are, two different motions — software or services — usually fit best.

If you need humans: YSecurity

YSecurity is the cybersecurity services firm we co-founded alongside Cyberbase. Same founders, different motion. YSecurity is where to look if you need:

• A fractional CISO to own the SOC 2 project end-to-end
• A formal readiness assessment before you engage an auditor
• Gap remediation work — policy drafting, control implementation, evidence gathering
• A second opinion before signing an engagement letter
• Ongoing security advisory once your report is issued

If your team is small and you don't have a security lead on payroll, this is usually the more appropriate first call.

If you need software: Cyberbase

Cyberbase is the AI-native platform we built around the post-SOC 2 problem: turning the report into ongoing sales velocity. A SOC 2 PDF sitting in a Drive folder doesn't close deals. Buyers don't read 60-page attestation reports — they ask security questionnaires that reference them, and they want a Trust Portal where they can self-serve before sending one. That's where Cyberbase fits.

Three workflows in one workspace:

• Trust Portal (free forever) — publish your SOC 2, sub-processors, certifications, and standard answers behind an NDA gate so buyers self-serve before they ever send a questionnaire
• DDQ and Security Questionnaire Automation — answer incoming questionnaires from your SOC 2, controls, and policies in minutes, not weeks
• Vendor Risk Assessment — when you're the buyer, send and score questionnaires using the same engine

One workspace. Three workflows. No per-question pricing.

Open your Cyberbase workspace →

Book a 20-minute walkthrough →

Talk to YSecurity about advisory →

(Disclosure: Cyberbase and YSecurity share founders. We mention both because most companies running their first SOC 2 need help on both axes — humans for the audit, software for the years that follow. We're upfront about which one fits which problem.)