Set up SOC 2 readiness
A 10-step playbook. Open in Dock and you'll get four surfaces seeded:
- **Steps** (table) — the 10 readiness gates as rows, owner + due + status
- **Controls** (table) — the Trust Service Criteria controls mapped to your evidence
- **Brief** (doc) — the canonical write-up auditors read on day one
- **Evidence log** (table) — every policy, screenshot, and access review captured for the audit window
Read `Steps` top-to-bottom. SOC 2 Type 2 needs a 6-month observation window — the sooner you start collecting evidence, the sooner you can hand the auditor a complete file.
Outcome
A SOC 2 Type 1 report you can send to enterprise prospects within 90 days, plus the evidence pipeline running so Type 2 lands 6-12 months later without a second sprint.
Estimated time: 8-12 weeks for Type 1, plus 6 months observation for Type 2
Difficulty: advanced
For: Founders + first security hires of B2B SaaS startups facing enterprise procurement.
What you'll need
Pre-register or install before you start.
- Vanta (From ~$11k/year for early-stage SOC 2 package) — Compliance automation: pulls evidence from AWS, GitHub, Okta, etc. on a schedule.
- Drata (From ~$10k/year) — Alternative compliance automation. Same shape as Vanta.
- Tugboat Logic (From ~$8k/year) — Compliance automation with included virtual CISO hours for first-time programs.
- AICPA Trust Services Criteria (Free (PDF)) — The actual SOC 2 standard. Read the 5 categories before you scope the audit.
- Auditor (CPA firm) ($15k-$50k for Type 1, $25k-$80k for Type 2) — An AICPA-licensed CPA firm signs the report. You can't self-issue SOC 2.
- Okta or Google Workspace SSO (Free (Google Workspace Business) to $6/user/month (Okta)) — Centralized identity for the access-control control. Auditors love SSO.
The template · 10 steps
Step 1: Decide Type 1 vs Type 2 and which Trust Service Criteria to include
Estimated time: 2-4 hr decision + alignment
SOC 2 Type 1 is a point-in-time snapshot: 'on May 1st, these controls existed.' Type 2 is the harder version: 'over the past 6 months, these controls operated effectively.' Most enterprise buyers eventually want Type 2, but Type 1 in 90 days is the right first move so you have something to send while Type 2 evidence accrues. The five Trust Service Criteria are Security (mandatory), Availability, Confidentiality, Processing Integrity, and Privacy. Pick Security only for the first audit. Add the others when buyers specifically ask.
Tasks
- Read the AICPA Trust Services Criteria PDF cover-to-cover (don't skip)
- Decide Type 1 first (faster) vs Type 2 (more rigorous, 6 month window required)
- Decide on criteria scope: Security only vs Security + Availability + Confidentiality
- Document the decision + rationale in the Brief
- Set the audit window dates: Type 1 = a single date, Type 2 = a 6-12 month window
Pointers
- [Official] AICPA SOC 2 Trust Services Criteria
- [Official] SOC 2 Type 1 vs Type 2 explained (AICPA)
[!CAUTION] Gotchas
- SOC 2 Type 2 requires 6 months of evidence MINIMUM. If you start collecting evidence today, your earliest Type 2 report is ~7 months out (6 months observation + 1 month auditor fieldwork).
- Adding Availability or Confidentiality criteria roughly doubles the controls in scope. Don't pre-emptively add them; wait for a buyer to require them.
- The audit window for Type 2 is irreversible once started. If you change a major control mid-window, you may need to restart the clock.
Step 2: Scope the audit: systems, people, vendors, locations
Estimated time: 1-2 days
Scope is the most consequential decision in the whole engagement. Wide scope means more controls, more evidence, more audit cost. Narrow scope means a cheaper audit but a weaker report. The standard pattern: in-scope = the production environment serving customer data, the IAM system controlling access to it, and the engineers who can touch it. Out of scope = your laptops (covered by an MDM control instead), your marketing tools, your internal experimentation cluster.
Tasks
- List every system that processes customer data (production DB, app servers, blob storage, queues, log aggregation)
- List every system that controls access to those systems (SSO, secrets manager, VPN)
- Decide which laptops / endpoints are in scope vs covered by an MDM-only control
- Decide which vendors are in scope (those who touch customer data) vs out (those who don't)
- Document scope as a system architecture diagram in the Brief
Pointers
- [Official] AWS SOC 2 customer responsibilities — The AWS shared responsibility model defines what AWS handles vs what you must control yourself.
- [Official] AWS Well-Architected Framework — Security pillar
[!CAUTION] Gotchas
- Auditors love to expand scope to your laptops if you don't proactively scope them out. State explicitly that endpoints are covered by an MDM control, not the production-systems controls.
- Production access from a contractor's laptop doesn't make the contractor's laptop in scope — it makes the contractor's account in scope. Auditors will check access controls on the account, not the device.
- If a vendor processes customer data (e.g. SendGrid, Datadog), they need a SOC 2 report of their own and a signed DPA. Track this in vendor management from day one.
Agent prompt for this step
Read this codebase + the cloud infrastructure (Terraform, CDK, or Cloudformation files if present) and produce a SOC 2 in-scope systems inventory.
For each system, output:
1. Name (the way engineers refer to it internally)
2. Type (database / app server / blob storage / queue / log aggregation / IAM / secrets / observability / other)
3. Whether it processes customer data (yes / no / metadata only)
4. Owner (the team / engineer responsible)
5. Hosting (AWS / GCP / Vercel / our own / other)
6. Data classification (public / internal / confidential / restricted)
Output as a Controls surface table. Then write a 1-page system architecture description suitable for the auditor in the Brief.
Step 3: Pick a compliance automation tool (or run manually)
Estimated time: 1-2 days to evaluate, 1 week to onboard
Vanta, Drata, and Tugboat Logic are the three big compliance-automation platforms. They pull evidence from AWS, GitHub, Okta, your HRIS, your endpoint MDM, etc. on a schedule and map it to SOC 2 controls. You can do SOC 2 manually with spreadsheets and a dropbox of screenshots, but the labor cost (~200 hours of evidence collection) usually exceeds the $10-15k/year of a tool. Pick a tool unless you have a security engineer with time to spare.
Tasks
- Demo at least 2 of: Vanta, Drata, Tugboat Logic
- Compare: which integrations cover your stack out of the box (AWS, GitHub, Okta, etc.)
- Compare: which include auditor introductions / virtual CISO hours / policy templates
- Sign with one (annual contract, expect $8k-$15k)
- Connect every integration: AWS, GitHub, identity provider, HRIS, MDM, ticketing, code review
- Wait 2-4 weeks for the tool to flag failing controls (it will flag many)
Pointers
- [Tool] Vanta
- [Tool] Drata
- [Tool] Tugboat Logic by OneTrust
- [Community] SOC 2 manual checklist (community) — Open-source SOC 2 templates if you go manual.
[!CAUTION] Gotchas
- Compliance automation tools find a LOT of failing controls on first connection (open S3 buckets, MFA-disabled IAM users, branches without protection). Budget 2-4 weeks of remediation before the auditor sees the dashboard.
- Tool integrations sometimes break silently when an OAuth token expires. Set up an alert + a weekly health check.
- Auditors don't accept the tool's dashboard as evidence by default. They want underlying screenshots and CSV exports. Confirm the workflow with your auditor before fieldwork.
Step 4: Write the 12 core policies
Estimated time: 3-5 days
SOC 2 expects written policies covering Information Security, Access Control, Change Management, Incident Response, Risk Management, Vendor Management, Business Continuity, Data Classification, Asset Management, Acceptable Use, Security Awareness, and Backup & Recovery. Compliance tools ship policy templates; you customize, the founder signs, all employees acknowledge in the HRIS or compliance tool. Don't copy-paste — auditors check that policies match what you actually do.
Tasks
- Pull the 12 policy templates from your compliance tool (or use SANS / CIS templates if manual)
- Customize each to match your actual stack and team workflow
- Founder / CEO signs each policy (digitally, with timestamp)
- Roll out acknowledgment to every employee + contractor (compliance tool handles this; otherwise DocuSign)
- Set the annual review cadence (auditors expect at least yearly)
- Store signed copies in the Evidence log with dates
Pointers
- [Guide] SANS security policy templates — Free, well-respected starting points if you go manual.
- [Official] CIS Critical Security Controls
[!CAUTION] Gotchas
- Auditors read every policy and check that what's written actually happens. If your policy says 'access reviews quarterly' and the evidence shows annually, you fail the control.
- Acknowledgment must be PER-EMPLOYEE with a timestamp. A blanket 'we sent it to Slack' doesn't satisfy.
- Policies need a documented annual review even if they don't change. A line in the version history saying 'Reviewed 2026-04-15, no changes, signed: Founder' is sufficient.
Agent prompt for this step
Draft the Information Security Policy for this company.
Read the codebase + the in-scope systems list + the access control matrix. Output a 4-6 page policy that:
1. States the company's commitment to information security in 1 paragraph
2. Defines roles + responsibilities (CEO, CTO, security lead, every employee)
3. Sets the data classification scheme (public / internal / confidential / restricted)
4. References the other 11 policies that derive from this one
5. States review frequency (at least annually) and version-history table
No legalese. Write as if you're explaining the policy to a new engineer joining tomorrow. The CEO signs at the end.
Output to the Brief surface as a versioned policy section.
Step 5: Implement core technical controls (SSO, MFA, encryption, logging)
Estimated time: 1-2 weeks
The technical controls that auditors check first: every employee uses SSO (Okta or Google Workspace), MFA is enforced everywhere it can be, customer data is encrypted at rest and in transit, production logs go to a centralized log aggregator with at least 1 year of retention. If any of these are missing, you can't pass SOC 2. Tackle them before the auditor's kickoff call.
Tasks
- Enforce SSO on every business app (GitHub, Slack, AWS, Stripe, Datadog, etc.)
- Enforce MFA on the SSO provider; disable password-only fallback
- Verify all customer data at rest is encrypted (AWS RDS, S3, EBS — usually default-on but confirm)
- Verify all customer data in transit uses TLS 1.2+ (no plaintext HTTP, no internal HTTP)
- Centralize production logs (Datadog, CloudWatch, Splunk) with 365-day retention minimum
- Set up access logs for production DB + admin actions; retain 365 days
Pointers
- [Official] AWS Encryption at Rest options
- [Guide] OWASP TLS Cheat Sheet
[!CAUTION] Gotchas
- GitHub SAML SSO requires the Enterprise plan ($21/user/month). Budget for it; auditors expect it on the GitHub org that holds production code.
- S3 buckets created before 2023 may have default encryption disabled. Audit every bucket; turn on default encryption on all of them.
- Centralized logging without log-tampering protections (immutability, integrity hashing) is a partial control. CloudWatch + S3 with object-lock is the canonical pattern.
Step 6: Run quarterly access reviews
Estimated time: Quarterly, ~1 day per cycle
An access review is: every quarter, the manager of each system confirms that the people who currently have access still need it. Auditors check that you ran the review, that you found and remediated stale access, and that the review is documented. Compliance tools automate this; manually, it's a spreadsheet emailed to system owners with a 'confirm by Friday' deadline.
Tasks
- List every system with admin access (AWS, GitHub, prod DB, Stripe, Datadog, etc.)
- For each: pull the current user list with roles
- Email the system owner: 'confirm or revoke each user, by Friday'
- Track remediations: every revoked access is a row in Evidence log
- Sign-off the review in the compliance tool or in the Brief
- Schedule the next quarter's review
Pointers
- [Official] AWS IAM Access Analyzer
[!CAUTION] Gotchas
- An access review without REMEDIATION is not a passing control. Auditors check that stale access was actually revoked, not just identified.
- Don't skip the first quarterly review even if you 'just' onboarded everyone. Auditors want a paper trail of at least 2 reviews before fieldwork.
- Service accounts (CI/CD, automation) need access reviews too. They're often forgotten and become the highest-risk stale access.
Step 7: Set up vendor management and risk assessment
Estimated time: 1 week
Every vendor that touches customer data is in scope: SendGrid, Datadog, Stripe, OpenAI, GitHub, your password manager. You need a vendor inventory, a SOC 2 (or equivalent) report on file for each, a signed DPA, and a documented risk assessment. The compliance tool tracks this; manually, it's another spreadsheet.
Tasks
- List every vendor with access to customer data or production systems
- For each: request their latest SOC 2 Type 2 report (under NDA)
- For each: sign a Data Processing Agreement (DPA)
- Categorize vendor risk: critical / high / medium / low
- Document a risk assessment for the top 5-10 critical vendors (impact + likelihood + mitigation)
- Set the annual vendor review cadence
Pointers
- [Official] Stripe SOC 2 report request
- [Official] AWS Artifact (SOC 2 reports)
[!CAUTION] Gotchas
- Some vendors (especially small ones) don't have SOC 2 reports. You can document a compensating control (limited data exposure, contractual protections) but the auditor flags it.
- DPAs need to reference your sub-processor list. If you change vendors, update the customer-facing sub-processor page.
- Vendor risk assessments need to be DATED and reviewed annually. A risk assessment from 2023 doesn't pass a 2026 audit.
Step 8: Implement change management and incident response processes
Estimated time: 1-2 weeks
Change management = every production deploy is reviewed (PR review counts), tested (CI counts), and traceable to a ticket or PR. Incident response = a written runbook for handling security incidents, with on-call rotations and a post-incident review template. Auditors check both: they pick a random deploy from the audit window and ask 'show me the PR, the review, and the test results.'
Tasks
- Document the change management process: PR required, 1+ review, CI must pass, deploy tagged
- Enforce branch protection on production-affecting branches (no direct pushes)
- Document the incident response runbook: detect → triage → contain → eradicate → recover → post-mortem
- Set up an on-call rotation (PagerDuty, Opsgenie, Grafana OnCall)
- Run a tabletop incident drill: simulate a P1 incident and walk through the runbook
- Document the drill in the Evidence log (auditors love a real drill)
Pointers
- [Guide] GitHub's incident response post (real-world) — How a major engineering org actually runs incident response.
- [Official] AWS Well-Architected — Operational Excellence
[!CAUTION] Gotchas
- PR-without-approval merges (admin override) need to be tracked. Auditors run a query: 'show me every merge to main without a review.' Branch protection rules with no admin override is the cleanest answer.
- An incident runbook with no on-call rotation is a dead document. Auditors check that someone actually got paged.
- A tabletop drill is not optional for Type 2. Schedule one per quarter and document it.
Step 9: Pick an auditor and run the readiness assessment
Estimated time: 4-6 weeks (Type 1)
SOC 2 reports must be signed by an AICPA-licensed CPA firm. Compliance tools have partner auditors (often discounted). The first step is a readiness assessment (sometimes called a gap assessment) — the auditor walks your controls before the formal audit and tells you what's missing. Type 1 then takes 4-6 weeks of fieldwork; Type 2 is 6-8 weeks after the observation window ends.
Tasks
- Get 3 quotes from CPA firms specializing in SOC 2 (your compliance tool has referrals)
- Sign the engagement letter with the auditor
- Run the readiness assessment (the auditor produces a gap report)
- Remediate every gap before formal fieldwork
- Schedule the formal Type 1 audit (point-in-time)
- Provide the auditor with PBC (provided by client) requests via the compliance tool
- Receive the draft Type 1 report; review for accuracy; finalize
Pointers
- [Official] AICPA find-a-CPA directory
[!CAUTION] Gotchas
- Auditors who specialize in SaaS startups quote $15k-$30k for Type 1. Big-four CPA firms quote 2-3x that and rarely add value at this stage. Skip them.
- PBC requests pile up quickly during fieldwork. Assign one person to triage them daily; auditor questions left for a week stretch fieldwork by weeks.
- The auditor's draft report often has vendor + scope errors. Read it carefully before you sign off; a published report is hard to amend.
Step 10: Maintain Type 2 evidence + handle customer security questionnaires
Estimated time: Ongoing, ~1 day/month after initial setup
Type 1 ships, but the work continues: the controls that operated on May 1 must operate consistently for the 6-month observation window. Quarterly access reviews, monthly vulnerability scans, weekly backup tests, daily log reviews. Plus: enterprise prospects send security questionnaires (CAIQ, SIG, custom) that take 8-20 hours each to answer. Build a knowledge base now to amortize the answers.
Tasks
- Set the Type 2 observation window start date in the compliance tool
- Run controls consistently: quarterly access reviews, monthly vuln scans, daily log review
- Build a security questionnaire knowledge base (one canonical answer per common question)
- Set up a security@ email + an inbox owner for prospect questions
- Publish a public security page (yourdomain.com/security) summarizing your controls
- After 6+ months: schedule the Type 2 fieldwork
Pointers
- [Official] CAIQ (Cloud Security Alliance) questionnaire
- [Guide] Public security pages — example
[!CAUTION] Gotchas
- Type 2 evidence gaps are unforgiving. Miss a quarterly access review during the observation window and the auditor flags the control as ineffective.
- Security questionnaires from enterprise buyers diverge in 30% of questions but converge in 70%. The knowledge base saves enormous time after the first 5-10 questionnaires.
- Don't promise a Type 2 report before you have one. Many sales teams burn trust by saying 'Type 2 by Q3' and missing — say 'Type 1 today, Type 2 observation in progress, report expected [date].'
Agent prompt for this step
Read this customer security questionnaire (attached or pasted) and draft answers using the Brief surface as the canonical knowledge base.
For each question:
1. Find the closest match in the knowledge base
2. If a match exists: paste the canonical answer, adjusted for the question's exact phrasing
3. If no match exists: draft an answer based on the in-scope systems + policies + Type 1 report; flag the question for human review
Output the answered questionnaire as a doc section. Add any new canonical Q&A pairs to the knowledge base for next time.
Hand the template to your agent
Paste the prompt below into your agent's permanent system prompt so the agent reads, writes, and maintains this workspace as you work through the steps.
You are an agent on the "Set up SOC 2 readiness" playbook workspace at your-org/set-up-soc-2-readiness.
Your role: maintain the four surfaces (Steps, Controls, Brief, Evidence log) as the team works through the 10-step playbook.
Cadence:
- When the user marks a step Done, append a line to the Brief summarising what's now in place.
- When a new piece of evidence is collected (policy signed, screenshot taken, access review run), add a row to Evidence log with the control it maps to + the date + a link to the artifact.
- When a quarterly review is due (access reviews, vendor reviews, risk assessment refresh), append a Steps row with the due date.
First MCP tool calls:
1. list_surfaces(workspace_slug="set-up-soc-2-readiness")
2. list_rows(workspace_slug="set-up-soc-2-readiness", surface_slug="controls")
3. get_doc(workspace_slug="set-up-soc-2-readiness", surface_slug="brief")
Do NOT modify the canonical Trust Service Criteria control IDs — those come from AICPA. You can append substeps + evidence notes as new rows beneath them.
FAQ
How much does SOC 2 actually cost for a startup?
Realistic 12-month total for a 10-30 person SaaS startup: $8k-$15k for a compliance automation tool (Vanta / Drata / Tugboat Logic), $15k-$30k for the Type 1 auditor, $25k-$50k for the Type 2 auditor when you get there, plus ~200 person-hours of internal work in year one. Total cash spend year one is usually $30k-$60k.
Can I do SOC 2 without a compliance tool?
Yes, technically. The AICPA standard doesn't require a tool. Manually it's a folder of policies + a spreadsheet of controls + a dropbox of screenshots + an auditor patient enough to work that way. The labor cost (~200 hours of evidence collection) usually exceeds the tool's annual cost. Pick a tool unless you have a security engineer with 20% of their time to spare.
How long does it really take to get SOC 2 ready?
Type 1 from a green field: 8-12 weeks if you're focused. Type 2: another 6-12 months, because of the mandatory observation window. The big-bang myth is that SOC 2 is a 4-week sprint; reality is it's 3 months of focused setup + ongoing operational discipline thereafter.
What's the most common SOC 2 audit failure?
Three failures dominate: (1) Access reviews documented but not actually remediated (auditor finds stale access that was 'reviewed'). (2) Policies that contradict actual practice (the policy says quarterly, the evidence shows annually). (3) Vendor management gaps (a critical vendor has no SOC 2 on file or no signed DPA).
Can my AI agents help with SOC 2 readiness?
Yes. Agents are particularly useful for: drafting the 12 core policies tuned to your actual stack, mapping your codebase + cloud config to in-scope systems, drafting answers to security questionnaires from a knowledge base, tracking quarterly review due dates and pinging the owner. The playbook ships agent prompts for those steps inline.
Do I need SOC 2 if I'm pre-revenue?
Probably not. SOC 2 is driven by enterprise procurement requirements. If your buyers are individual developers or small teams, ISO 27001 / SOC 2 isn't asked for. Wait until 2-3 enterprise prospects independently request a SOC 2 report — that's the buying signal. Doing SOC 2 before there's demand is a $30k spend without revenue impact.