Most founders approaching SOC 2 for the first time face the same problem: they know they need it, they know it takes time, but they have no idea what to actually do each week to get there. They read about the Trust Service Criteria and immediately feel like they need a compliance consultant just to decode the jargon.

You don’t. SOC 2 Type 1 readiness is 90 days of structured, sequential work — not 90 days of scrambling. This guide breaks it down week by week: what to do, what “done” looks like, and which ShieldDocs template covers each phase.

At the end, you’ll have policies ready for auditor review, technical controls in place, and evidence systems running. If you already have solid engineering practices or use pre-built templates, you can compress this to 45–60 days.

The 90-Day Overview

Before diving into weeks, it helps to understand what each phase is actually building toward. SOC 2 Type 1 readiness is essentially three things: documented controls, implemented controls, and evidence that they exist. The 90 days are structured to deliver all three in the right order.

Phase Weeks Focus Output
Foundation 1–2 Policies + access controls Written, approved policies; IAM baseline configured
Technical 3–4 Encryption, logging, monitoring Technical controls documented and verified
Process 5–8 Vendor mgmt, change control, training Operational processes running, training complete
Audit Prep 9–12 Gap assessment, evidence, auditor Audit-ready evidence package, auditor engaged

One thing that trips up almost every startup: they start with technical controls and ignore documentation. Auditors care about both. A perfectly configured S3 bucket with no encryption policy document is an audit finding. Always lead with documentation.

For a full picture of the end-to-end timeline and what follows the 90-day readiness phase, see How Long Does SOC 2 Take? A Realistic Timeline for Startups.

Stop drafting from scratch. Start from proven templates.

The ShieldDocs Starter Kit includes every policy template you need for Weeks 1–2 of this roadmap — written to SOC 2 Trust Service Criteria standards. $147, one-time, instant download.

Get the Starter Kit →

Weeks 1–2: Foundation — Policies + Access Controls

The first two weeks are about building the paper foundation your technical controls will stand on. Auditors review documentation before they look at your infrastructure. If your policies don’t exist, the controls they describe don’t exist — as far as the audit is concerned.

This phase is the most front-loaded with writing work. Most startups underestimate it. 12 SOC 2-required policy documents, each 3–8 pages, written to a specific standard. From scratch, that’s 40–80 hours. With templates, it’s 8–15 hours of customization.

Week 1

📄 Core Policy Documentation

Days 1–7

What to do:

  • Write or customize your Information Security Policy — the foundational document that defines your overall security program, scope, roles, and commitments
  • Write your Access Control Policy — covers RBAC, least-privilege principles, provisioning, deprovisioning, and quarterly access review requirements
  • Write your Incident Response Plan — detection, containment, eradication, recovery, and post-incident review procedures
  • Get all three reviewed and formally approved by your security or engineering lead (approval signature required for audit evidence)
✓ What “done” looks like

Three policy documents exist, are dated, and have a named approver. They live in a shared location (Google Drive, Notion, Confluence) that you can point an auditor to. They are not drafts.

Week 2

🔒 Access Control Implementation

Days 8–14

What to do:

  • Enforce MFA across all systems: GitHub, AWS/GCP/Azure, Slack, Google Workspace, any admin panels. No exceptions for engineers.
  • Implement SSO where possible (Okta, Google Workspace, or Entra ID). All SaaS tools should authenticate through it.
  • Audit current user access: run a full user list export from every critical system. Identify and remove any inactive accounts, ex-employees, and overly permissive roles.
  • Document your RBAC model: who has admin access, who has read-only, how roles are assigned and reviewed. This is the evidence your Access Control Policy requires.
  • Set a calendar reminder for your first quarterly access review (3 months out).
✓ What “done” looks like

MFA enabled and enforced (no bypass). A dated screenshot or export showing all current users and their roles in each critical system. No orphaned accounts. RBAC documented in your Access Control Policy or a linked spreadsheet.

ShieldDocs templates for Weeks 1–2: Information Security Policy, Access Control Policy, Incident Response Plan. Each is pre-structured to SOC 2 requirements and takes 2–4 hours to customize. Start here.

Weeks 3–4: Technical Controls — Encryption, Logging, Monitoring

With your foundation documents in place, Weeks 3–4 move to technical implementation. This is where most engineering-led startups are strongest — but the documentation discipline from Weeks 1–2 still applies. Every control you implement needs a matching policy document.

Week 3

🔐 Encryption + Data Protection

Days 15–21

What to do:

  • Verify encryption at rest: all databases (RDS, Postgres, Mongo) must have encryption enabled. S3 buckets: default encryption on. Check every data store.
  • Verify encryption in transit: TLS 1.2+ enforced on all endpoints. No HTTP. Check your load balancer, API gateway, and any internal service-to-service communication.
  • Audit secret management: are API keys and credentials stored in environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault, 1Password)? Eliminate hardcoded secrets in code.
  • Write and approve your Encryption & Data Protection Policy: documents your encryption standards, key management approach, and data classification scheme.
✓ What “done” looks like

Every data store has encryption at rest confirmed (screenshot/config export). TLS enforced sitewide. Zero hardcoded secrets in the codebase (verified via a scan). Encryption policy document approved.

Week 4

📊 Audit Logging + Monitoring

Days 22–28

What to do:

  • Enable audit logging on all critical systems: AWS CloudTrail, GCP Audit Logs, GitHub audit logs, database access logs. Logs must capture who did what, when.
  • Centralize logs: route them to a SIEM or log aggregation tool (Datadog, Splunk, CloudWatch Logs). Logs that live only on individual servers are not audit evidence.
  • Set up alerting for critical security events: failed logins (especially on admin accounts), privilege escalation, unusual data exports, infrastructure changes.
  • Document your log retention policy: SOC 2 expects logs retained for at least 12 months. Confirm your retention settings.
  • Write and approve your Vulnerability Management Policy: scanning cadence (monthly minimum), patching SLAs by severity, and penetration testing schedule.
✓ What “done” looks like

Audit logs enabled and verified in all critical systems (with a dated evidence screenshot). Logs flowing to a central aggregator. At least one security alert configured and tested. Log retention set to 12+ months. Vulnerability Management Policy approved.

ShieldDocs templates for Weeks 3–4: Encryption & Data Protection Policy, Vulnerability Management Policy. Both include the specific control requirements your auditor will check against.

Weeks 5–8: Process — Vendor Management, Change Control, Training

Weeks 5–8 are the most overlooked phase — and the most common source of audit findings. Technical teams nail the encryption and logging. Then an auditor asks for your vendor risk assessments and change management records, and there’s nothing to show.

Process controls don’t require new technology. They require discipline and documentation. Four weeks is enough to get all three operational processes running.

Weeks 5–6

🏢 Vendor Risk Management

Days 29–42

What to do:

  • Create a vendor inventory: list every third-party service that has access to customer data or your production environment. This includes cloud providers, SaaS tools, payment processors, analytics platforms, and contractor access.
  • Classify each vendor by risk tier: High (processes customer data), Medium (accesses production systems but not data), Low (no production access).
  • For High and Medium vendors: document their SOC 2 report status (do they have one?), their data processing agreement, and your internal security review findings.
  • Write and approve your Vendor Risk Management Policy: defines your vendor classification criteria, review frequency (annually for High, biannually for Medium), and how new vendors get approved.
  • Execute Data Processing Agreements (DPAs) with any vendor that processes personal data.
✓ What “done” looks like

A documented vendor inventory with risk tier classifications. SOC 2 reports or security questionnaire responses on file for all High-tier vendors. DPAs signed. Vendor Risk Management Policy approved.

Week 7

⚙️ Change Management

Days 43–49

What to do:

  • Formalize your code review process: every production change requires a PR reviewed by at least one other engineer before merge. No direct pushes to main. Enforce this via branch protection rules in GitHub.
  • Document your deployment approval process: who can approve production deployments, how hotfixes are handled, how rollbacks are executed.
  • Set up a change log: a lightweight record of significant production changes (can be a GitHub label + spreadsheet or your existing ticketing system). Auditors will pull a sample of changes and ask to see the associated approvals.
  • Write and approve your Change Management Policy: covers SDLC standards, code review requirements, deployment approval, and emergency change procedures.
✓ What “done” looks like

Branch protection rules configured in your repository (screenshot). The last 10 production changes have associated PRs with approval records. Change Management Policy approved and linked to your evidence folder.

Week 8

🎓 Security Training

Days 50–56

What to do:

  • Deliver security awareness training to all employees: covers phishing recognition, password hygiene, data handling, and incident reporting. A 30-minute recorded session with a completion quiz works fine for Type 1.
  • Document completion: a spreadsheet logging who completed training and on what date. Auditors will sample this.
  • Update your employee onboarding checklist to include security training as a mandatory Day 1 item with a sign-off.
  • Write and approve your Employee Security Training Plan: defines training topics, frequency (annual), new-hire requirements, and how completion is tracked.
✓ What “done” looks like

All current employees have completed security awareness training (completion records on file). New-hire training documented in the onboarding process. Employee Security Training Plan approved.

ShieldDocs templates for Weeks 5–8: Vendor Risk Management Policy, Change Management Policy, Employee Security Training Plan, Privacy Policy & DPA. These four templates cover everything the Process phase requires.

Weeks 9–12: Audit Prep — Gap Assessment, Evidence Collection, Auditor Selection

The final phase is the one most startups rush — and the one that determines whether the audit actually goes smoothly. Weeks 9–12 are about verifying everything you built, collecting evidence in auditor-ready format, and selecting and engaging your auditor.

Week 9

🔎 Internal Gap Assessment

Days 57–63

What to do:

  • Run a full gap assessment against the SOC 2 Trust Service Criteria using the SOC 2 compliance checklist. Every control should be in one of three states: Implemented, Partially Implemented, or Not Implemented.
  • For every Partially or Not Implemented item: create a remediation ticket with an owner and a target date. There should be zero Not Implemented items before you engage an auditor — they become findings.
  • Write and approve your Risk Assessment: a documented review of your risk environment, likelihood and impact ratings, and how you’ve addressed each risk. SOC 2 requires this annually.
✓ What “done” looks like

Completed gap assessment with all controls rated. Zero “Not Implemented” items remaining. Risk Assessment document approved. Remediation plan for any remaining partial controls, with owners assigned.

Weeks 10–11

📋 Evidence Collection

Days 64–77

What to do:

  • Create a central evidence folder (Google Drive or SharePoint) organized by control area: Access, Encryption, Logging, Change Management, Vendors, Training, Business Continuity.
  • For each control, collect dated evidence: configuration screenshots, access review records, log exports, training completion records, vendor documentation.
  • Specifically collect: MFA enforcement screenshots (user-level, not just setting), TLS configuration evidence, encryption status for each data store, the last three PRs with approval records, and quarterly access review records.
  • Write and approve your Business Continuity Plan: covers RTO/RPO targets, backup testing procedures, disaster recovery runbooks, and communication protocols.
  • Test and document at least one backup restore: pull a backup, restore it, verify data integrity. Document the test date and results.
✓ What “done” looks like

Evidence folder with a document for every control area, all items dated. Business Continuity Plan approved. Backup restore test documented. The evidence package could be handed to an auditor tomorrow.

Week 12

📝 Auditor Selection + Engagement

Days 78–90

What to do:

  • Get quotes from at least 3 CPA firms that perform SOC 2 audits. Pricing varies significantly: budget $10K–$25K for a Type 1. Ask specifically about their startup experience — not all firms are calibrated for early-stage companies.
  • Evaluate firms on: experience with companies your size, turnaround time (6–8 weeks is typical from kickoff to report), clarity on what they need from you, and references from similar startups.
  • Sign an engagement letter. Get a kickoff date on the calendar. Provide your evidence package to the auditor at kickoff.
  • Prepare for auditor fieldwork: expect 4–8 hours of your team’s time answering questions, granting system access, and providing additional evidence. This is normal.
✓ What “done” looks like

Auditor engaged with a signed engagement letter. Kickoff date set. Evidence package delivered. You’re in the audit queue.

ShieldDocs templates for Weeks 9–12: Risk Assessment Framework, Business Continuity Plan, SOC 2 Audit Readiness Checklist. The Readiness Checklist is particularly useful here — it maps every control to Trust Service Criteria and doubles as your evidence organization guide.

Know exactly where your gaps are before Week 9

Download the free 27-point SOC 2 readiness checklist. Score your current controls in 15 minutes — before you engage an auditor.

Download Free Checklist →

Fast Track: How to Compress to 45–60 Days

The 90-day plan assumes you’re starting from scratch. Most startups aren’t. Here’s what compresses the timeline:

⚡ Fast Track: With pre-built templates, most startups compress this roadmap to 45–60 days. The ShieldDocs Starter Kit eliminates the 40–80 hours of policy drafting that makes Weeks 1–2 the bottleneck for most teams. You’re customizing, not writing from scratch — that’s the difference between 2 weeks and 1 week per phase.

What actually creates the fast track

Pre-built policy templates cut Weeks 1–2 from 10–14 days to 5–7 days. This is the single biggest lever. Writing 12 SOC 2 policies from scratch is the task that stalls most SOC 2 projects. Starting from a template that already maps to Trust Service Criteria means you’re filling in blanks, not building structure.

Existing engineering hygiene compresses Weeks 3–4. If you already enforce MFA, use a secrets manager, have audit logging running, and never push directly to main, Week 4 is mostly documentation and evidence collection, not implementation. Teams with solid CI/CD and infrastructure-as-code can complete this phase in 5–6 days.

Existing vendor relationships compress Weeks 5–6. If you’ve already signed DPAs with your major vendors and have their SOC 2 reports on file, vendor management is a classification exercise, not a discovery exercise.

Parallelizing phases. The phases above are sequential because they have logical dependencies, but some items can run in parallel. You can start your vendor inventory (Week 5) while finishing encryption documentation (Week 4). You can begin auditor outreach (Week 12) in Week 9.

Team bandwidth. The 90-day plan assumes compliance is a part-time project. If you dedicate one engineer full-time to compliance readiness for 6 weeks, you can compress significantly — particularly the technical phases.

See the Type 1 vs Type 2 comparison for how the fast-track affects your overall Type 1 → Type 2 journey.

ShieldDocs Templates: Mapped to Each Phase

Here’s the full breakdown of which ShieldDocs Starter Kit templates cover each phase of this roadmap.

Phase ShieldDocs Template What It Covers
Weeks 1–2 Information Security Policy Overall security program scope, roles, commitments
Weeks 1–2 Access Control Policy RBAC, provisioning, deprovisioning, access reviews
Weeks 1–2 Incident Response Plan Detection, containment, recovery, notification
Weeks 3–4 Encryption & Data Protection Policy At-rest, in-transit, key management, data classification
Weeks 3–4 Vulnerability Management Policy Scanning cadence, patching SLAs, pen testing
Weeks 5–6 Vendor Risk Management Policy Vendor classification, review frequency, approval process
Weeks 5–6 Privacy Policy & DPA Data handling, processing agreements
Week 7 Change Management Policy SDLC, code review, deployment approval, emergency changes
Week 8 Employee Security Training Plan Training topics, frequency, onboarding, completion tracking
Week 9 Risk Assessment Framework Annual risk assessment methodology, risk register
Weeks 10–11 Business Continuity Plan RTO/RPO, backup testing, disaster recovery, communications
Week 9+ SOC 2 Audit Readiness Checklist Control-by-control tracker, evidence guide, auditor prep

All 12 templates are included in the ShieldDocs Compliance Starter Kit at $147 one-time. They’re written to SOC 2 Trust Service Criteria requirements and formatted as auditors expect. The alternative is a compliance consultant billing $250–$500/hour to produce the same documents.

For context on what SOC 2 compliance costs at each stage — audit fees, tooling, internal time — see How Much Does SOC 2 Cost? A Breakdown for Startups.

Get Every Template in This Roadmap

12 professional SOC 2 policy templates mapped to Trust Service Criteria. Skip weeks of policy drafting. One purchase, instant download.

Get the Starter Kit — $147 →

The Bottom Line

SOC 2 Type 1 readiness is 90 days of structured work, not chaos. Foundation first (policies + access controls). Technical controls second (encryption, logging, monitoring). Process third (vendor management, change control, training). Audit prep last (gap assessment, evidence, auditor selection).

The two biggest mistakes: starting with technical controls while ignoring documentation, and underestimating how long policy writing takes. Fix the second problem with templates. Avoid the first by following this sequence.

If you’re still deciding between Type 1 and Type 2, read SOC 2 Type 1 vs Type 2: Which Does Your Startup Need? before committing to a timeline. And if you want a broader picture of the compliance landscape before you start, the SOC 2 compliance checklist gives you the full 27-point control inventory that this roadmap is designed to satisfy.

Start with Week 1. Don’t try to do this all at once. Ninety days of consistent forward motion beats a sprint-and-stall every time.

Ready to start your 90-day roadmap?

12 professional SOC 2 policy templates — covers every phase of this roadmap. Instant download.