You just got the email. A prospect — probably your biggest deal in pipeline — wants to see your SOC 2 report before they can move forward. You don't have one. You don't have a security program. And you just realized that every solution you're finding online costs $15,000 or more per year.
Here's the thing most compliance vendors won't tell you: you don't need a platform to get SOC 2 ready. Not at your stage. What you need is structure — the right policies, the right evidence, and enough operational proof that an auditor can sign off on your controls.
This guide walks you through exactly how to do that. No compliance platform required. No consultant. Just a focused CTO or founder who can dedicate 10–15 hours a week for about 90 days.
- What SOC 2 Type I actually requires
- Choosing the right scope (and avoiding over-engineering)
- The 10 policies auditors expect — and why
- Building your evidence foundation
- The technical controls that matter most
- A realistic 90-day timeline
- Common mistakes that delay audits
- When you actually need a platform
1. What SOC 2 Type I actually requires
SOC 2 is not a certification. It's a reporting framework developed by the AICPA (American Institute of Certified Public Accountants) that evaluates how your company manages customer data. An independent CPA firm examines your controls and issues a report — that report is what your prospects are asking for.
There are two types:
- Type I assesses whether your controls are appropriately designed at a specific point in time. Think of it as a snapshot: "Do you have the right controls in place today?"
- Type II assesses whether those controls operated effectively over a period of time (usually 3–12 months). This is the ongoing proof.
If you're an early-stage SaaS company that just got asked for SOC 2, Type I is your starting point. It's faster, cheaper, and gives your prospect enough assurance to move the deal forward while you build toward Type II.
For Type I, you need to show that your controls exist and are well-designed. You don't need months of operating history. One well-documented instance of each control operating is typically sufficient.
2. Choosing the right scope
SOC 2 is built around five Trust Services Criteria (TSC):
- Security (required for every SOC 2 audit)
- Availability (optional)
- Processing Integrity (optional)
- Confidentiality (optional)
- Privacy (optional)
Security is mandatory. The others are elective and should be included only if your product and customer contracts specifically require them.
For most early-stage B2B SaaS companies, the right scope is Security only, with natural overlap into Availability and Confidentiality where your existing controls already address them. Do not add Processing Integrity or Privacy unless you process financial transactions or handle significant personal data under GDPR/CCPA.
Including all five TSC categories because it "looks more thorough." This dramatically increases your control count, evidence burden, and audit cost — with no corresponding benefit at your stage. Start narrow. Expand later.
The Security TSC is implemented through the Common Criteria (CC series), which breaks down into nine categories:
| Category | What it covers |
|---|---|
| CC1 | Control Environment — governance, leadership, accountability |
| CC2 | Communication — internal and external security communications |
| CC3 | Risk Assessment — identifying and evaluating risks |
| CC4 | Monitoring — ongoing evaluation of control effectiveness |
| CC5 | Control Activities — policies and procedures in action |
| CC6 | Logical and Physical Access — who has access to what |
| CC7 | System Operations — incident detection and response |
| CC8 | Change Management — how changes reach production |
| CC9 | Risk Mitigation — vendor management, business continuity |
CC6 (Access Controls) and CC8 (Change Management) are the most heavily tested categories. If you focus your preparation energy anywhere, focus there.
3. The 10 policies auditors expect
Policies are the governance backbone of your SOC 2 posture. An auditor uses your policies as the "should" against which they test the "is." Without written policies, there's nothing to audit.
Here are the 10 policies that are realistically required for a first-time SOC 2 Type I engagement, and why each one matters:
Information Security Policy
Your foundational document. Establishes who owns security, what principles guide your program, and how policies are enforced. Without this, auditors have no governance anchor for the rest of your controls.
Access Control Policy
Defines who gets access to what, how access is provisioned and revoked, MFA requirements, and quarterly review procedures. This is the single most-tested control area in any SOC 2 audit.
Change Management Policy
Governs how changes to production systems are reviewed, approved, and deployed. For SaaS companies, this usually maps directly to your PR-based code review and CI/CD pipeline — you may already be doing most of this.
Incident Response Policy
Defines how you detect, respond to, and recover from security incidents. Even if you've never had an incident, auditors expect a documented plan and evidence you've tested it (a tabletop exercise is sufficient).
Risk Assessment Policy
Describes how you identify, evaluate, and manage risks. You need a risk register — a spreadsheet listing your top 10–15 risks with likelihood, impact, ownership, and mitigation status.
Vendor Management Policy
Defines how third-party vendors are evaluated and monitored. Auditors want a vendor inventory and evidence that you've reviewed SOC 2 reports from your critical vendors (AWS, identity provider, payment processor).
Data Classification & Handling Policy
Establishes categories for data sensitivity (Restricted, Confidential, Internal, Public) and handling rules for each. Shows auditors you know what data you hold and treat it appropriately.
Business Continuity & Disaster Recovery Policy
Documents your backup procedures, recovery targets (RTO/RPO), and how you'd recover from a disruption. Doesn't need to be enterprise-grade — but you need defined targets and evidence of a backup restoration test.
Acceptable Use Policy
Sets expectations for employee use of company systems. Auditors use this to verify employees understand their security responsibilities. Key evidence: signed acknowledgment from each employee.
Human Resources Security Policy
Covers background checks, onboarding security training, and offboarding procedures. Auditors will specifically test that terminated employees had access revoked promptly.
Every policy needs: a named owner, an approval date, a review frequency (annual), and language that describes what you actually do — not aspirational enterprise controls. A policy that says "quarterly access reviews" when you've never done one is worse than not having the policy at all.
4. Building your evidence foundation
A policy without evidence is a document. A policy with evidence is a control. Here's what "evidence" actually looks like at an early-stage company — it's less intimidating than most people think.
| Control Area | What auditors expect | What you can actually provide |
|---|---|---|
| Access Controls | User access lists, MFA configuration, quarterly review documentation, offboarding evidence | Screenshot of MFA enforcement in Google Workspace/Okta. Quarterly access review spreadsheet. Offboarding checklist showing access removed within 24 hours. |
| Change Management | PR approvals, deployment logs, change approval records | GitHub PR history showing required reviews. CI/CD pipeline config requiring approval gates. Deployment logs from the past quarter. |
| Incident Response | Incident response plan, incident log, evidence of testing | Your IR policy. An incident log (even if it only contains false positives). One completed tabletop exercise. |
| Risk Assessment | Risk register, methodology, periodic review evidence | Risk register spreadsheet with 10–15 risks, reviewed quarterly. Meeting notes from risk review sessions. |
| Vendor Management | Vendor inventory, risk assessments, SOC 2 reports on file | Vendor inventory spreadsheet with tiers. SOC 2 reports from your top 5 vendors. |
| Training | Security awareness training records | Training completion log. Even a recorded Loom walkthrough with completion tracking counts. |
| Monitoring | Alerting configuration, log review evidence | CloudWatch/Datadog alert rules screenshot. Brief quarterly log review summary. |
The pattern is clear: screenshots, spreadsheets, and brief documents. You don't need a compliance platform to collect this. You need a structured folder in Google Drive or Notion and the discipline to take screenshots as you implement controls.
5. The technical controls that matter most
If you're a cloud-native SaaS company on AWS or GCP, many of these controls are things you should already have — or can implement in hours, not weeks.
Non-negotiable (implement before audit)
- MFA enforced on all systems. Identity provider, cloud console, GitHub, every SaaS tool that supports it. No exceptions. This is the single most common audit finding.
- Required PR reviews in GitHub. Branch protection rules requiring at least one approval before merge. Direct commits to main/production branches disabled.
- Automated backups with a tested restoration. RDS/Cloud SQL automated backups configured. At least one documented restoration test proving the backups actually work.
- Encryption at rest and in transit. TLS 1.2+ for all connections. AES-256 encryption on databases and object storage. Both AWS and GCP make this straightforward.
- Centralized logging. CloudTrail (AWS) or Cloud Audit Logs (GCP) enabled. You don't need a SIEM — you need to be able to answer "who did what, when?" if asked.
Important (implement during preparation)
- Monitoring and alerting. Basic alerts for: failed login attempts, unauthorized API calls, billing anomalies, infrastructure changes. CloudWatch alarms or Datadog monitors are sufficient.
- Offboarding automation. A documented checklist that removes access across all systems within 24 hours. Auditors will specifically test your most recent terminations.
- CI/CD pipeline with test gates. Automated tests that must pass before deployment. This is both good engineering and a change management control.
Can wait (defer until Type II)
- SIEM or managed detection and response
- Automated provisioning/deprovisioning (SCIM)
- Privileged access management (PAM) solution
- Continuous control monitoring dashboards
- Formal penetration test (recommended but not required for Type I)
6. A realistic 90-day timeline
This assumes a solo CTO or founder dedicating 10–15 hours per week. Adjust based on your starting point — if you already have MFA and PR reviews enforced, you're ahead of schedule.
Weeks 1–2: Policy foundation
Write (or customize from templates) all 10 policies. Replace every placeholder with your company's specifics. Remove anything aspirational — only document what's true. Collect signed acknowledgments from all employees.
Weeks 3–4: Risk and vendor inventory
Build your risk register with 10–15 genuine risks. Complete your vendor inventory with tier classifications. Collect SOC 2 reports from critical vendors (AWS, Google, Stripe all publish these — you just need to download them).
Weeks 5–6: Technical controls
Enforce MFA everywhere. Configure branch protection in GitHub. Verify backup configurations. Document encryption settings. Screenshot everything as you go.
Weeks 7–8: Operational proof
Complete your first quarterly access review. Run a tabletop incident response exercise. Deliver security awareness training. These three activities generate evidence for the most heavily tested control areas.
Weeks 9–10: Monitoring and pipeline
Set up basic monitoring alerts. Document your CI/CD pipeline. Perform a backup restoration test and document the results.
Weeks 11–12: Compile and review
Organize all evidence into a structured repository. Review all policies for internal consistency. Begin drafting your System Description (the narrative document auditors require).
Week 13: Engage auditor
Contact a CPA firm for a readiness assessment. This pre-audit review identifies gaps before the formal examination. Budget $3,000–$8,000 for readiness plus $8,000–$15,000 for the Type I audit itself.
Skip the 60+ hours of research
The SOC 2 Readiness Toolkit gives you all 10 policies, the evidence mapping table, a complete Notion workspace, and the 90-day implementation plan — ready to customize and ship.
7. Common mistakes that delay audits
These are the patterns that cause first-time SOC 2 audits to stall, based on what auditors consistently flag:
Claiming controls you don't have. If your policy says "monthly vulnerability scans" but you've never run one, that's a finding. Auditors test claims against evidence. Only document what actually happens.
Skipping access reviews. This is the most common gap. The fix is simple: export user lists from every system, verify each person's access is appropriate, document the review. It's a spreadsheet exercise that takes 2–3 hours quarterly.
No terminated employee evidence. Auditors will find your most recent departures and check whether access was revoked within your stated timeframe. If your last termination has active accounts, that's a finding you can't talk your way past.
Generic copy-pasted policies. Auditors recognize boilerplate immediately. A policy that references "the CISO" when you don't have one, or "the security team" when it's just you — these undermine credibility. Write policies that describe your actual company.
Over-scoping. Including all five TSC categories, adding controls for a 500-person company, or building enterprise-grade processes you can't maintain. Lean and honest beats comprehensive and fictional.
Waiting until the audit to collect evidence. Evidence should be collected as you implement controls, not reconstructed afterward. Take screenshots. Save exports. Document decisions in real-time.
8. When you actually need a compliance platform
Vanta, Drata, Secureframe, and similar platforms are good products. They're just not necessary at every stage. Here's when each approach makes sense:
| Approach | Best for | Cost |
|---|---|---|
| DIY with templates | 5–30 employees, first SOC 2, one CTO who can own it | $349 (toolkit) + $8–15K (audit) |
| Compliance platform | 30–100+ employees, recurring audits, multiple frameworks | $15–25K/year + audit fees |
| Consultant | No internal bandwidth, complex architecture, regulated industries | $20–50K + audit fees |
The honest guidance: if you're under 30 employees and this is your first SOC 2, a platform adds cost and complexity you don't need yet. Build the foundation manually, get your Type I report, and evaluate platforms when you're scaling to Type II or adding headcount to the security function.
If you're over 50 employees, already have Type I, and need to maintain Type II annually — that's when continuous monitoring and automated evidence collection start saving real time. That's the platform sweet spot.
Getting started today
The gap between "we don't have SOC 2" and "we're actively preparing for our SOC 2 Type I" is smaller than most founders think. It starts with written policies, a handful of technical controls you probably half-have already, and the discipline to document what you do.
The prospect who asked for your SOC 2 report doesn't need perfection. They need confidence that you take security seriously and have a structured approach to managing it. That's what a readiness posture gives you — even before the formal audit.
Start with your Access Control Policy and MFA enforcement. Those two moves alone address the most heavily tested area in any SOC 2 examination and give you something concrete to point to when the prospect follows up.
The complete SOC 2 readiness foundation
10 audit-grade policies, control-to-evidence mapping, Notion workspace with 5 databases, and a 90-day implementation plan. Built for early-stage SaaS founders who need to move fast.