SOC 2 Type II Readiness: A 90-Day Implementation Guide

Last updated: April 2026

Lead

You've decided to pursue SOC 2 Type II compliance. Good. Now you need to actually get there—and you probably have 90 days or less to make it happen. This guide is for the compliance teams, engineering leads, and founders at startups and mid‑market companies who are preparing for their first SOC 2 Type II audit. It covers the full arc: from understanding what you're signing up for, to running a gap analysis, implementing controls, collecting evidence, and picking the right auditor. Follow this sequence. Skip the theory. Get audit‑ready.

What SOC 2 Type II Is — and Why Organizations Struggle With It

SOC 2, the System and Organization Controls framework developed by the AICPA, evaluates the design and operational effectiveness of your security controls over a period of time. SOC 2 Type II is the operational effectiveness track — auditors don't just check that you have controls; they check that those controls worked every day for the audit period, typically six to twelve months.

The common misconception: companies think they need a year of "running clean" before they can even start an audit. That's not accurate. You can start an audit the day your controls are in place, but the audit period begins on the day your controls go live. So the practical move is to implement everything, then engage the auditor immediately. The clock starts ticking when you say it starts.

The two areas where organizations consistently struggle:

Evidence collection is the biggest time sink. Auditors need continuous evidence — logs, access reviews, vulnerability scans, change management records — not screenshots once at the end. If you haven't been collecting evidence systematically, you'll spend weeks reconstructing it or, worse, paying the auditor to issue findings.

Control ownership gets muddied. Someone needs to own every control. Not conceptually — operationally. In organizations under 200 people, it's common for one person to "own" a dozen controls and have no idea what evidence lives where. Auditors flag this. It surfaces during the observation phase when they ask to see who reviewed access in March.

The 90-Day Roadmap

Days 1–20: Scope and Gap Analysis

Step 1: Define your scope and trust services criteria.
SOC 2 audits are built around the AICPA Trust Services Criteria (TSC), previously the Trust Services Principles. For most SaaS companies, you'll include Security as a baseline. Common additional criteria:

Availability — if you make SLA commitments, auditors will evaluate uptime and incident response
Confidentiality — if you handle sensitive customer data beyond what your security policy covers
Processing Integrity — relevant for companies where data processing accuracy is contractually critical

Most companies start with Security only. You can always expand scope on a future audit. Keep scope tight on your first one.

Step 2: Conduct a gap analysis against your target criteria.
Map your existing controls against each TSC. This means going through every control description in the AICPA's 2017 Trust Services Criteria (the version most auditors use as their baseline — it added several new criteria around data privacy and vendor risk) and checking:

Do we have this control?
Is it documented?
Is it operating? (Meaning: someone is actually doing it, not just that the policy exists)
Do we have evidence?

Use a control mapping matrix. It doesn't need to be complex — a spreadsheet with columns for TSC criterion, control description, current state (design/operating/not in place), evidence owner, and remediation owner works fine.

Step 3: Identify your audit period start date.
Your audit period is the window during which controls must be operating. The minimum is typically six months — most auditors will push for twelve. Choose a start date that gives you enough time to implement gaps but isn't so far out that you're burning months doing nothing. A practical choice: pick a date 45–60 days out, use that time for implementation, then start your audit clock when controls are live.

Days 21–50: Control Implementation

This is where most of the actual work happens. Implement controls in this order — the items at the top are prerequisites for everything below.

Step 4: Access management controls.
Logical access controls are the foundation of every SOC 2 audit. You need:

Role‑based access control (RBAC) with documented role definitions — who has access to what, and why
Quarterly access reviews — a designated owner reviewing who has elevated access, with documented sign‑off
Provisioning and deprovisioning procedures — how access is granted when someone joins and revoked when they leave (same day, not next week)
Multi‑factor authentication (MFA) enforced for all internal systems — not optional, not "recommended"

If you use AWS, Azure, or GCP, enable their native audit logging and ensure logs are being shipped to a centralized location. GCP Command Center, AWS Security Hub, and Azure Defender cover the centralized view.

Step 5: Change management and software development lifecycle controls.
Auditors look for evidence that code changes go through a documented review process. You need:

A documented SDLC policy that covers development, testing, and production environments
A ticketing or workflow system (Jira, Linear, GitHub Projects) where every change has a ticket
A code review requirement — no direct pushes to production branches
A segregation of duties acknowledgment: developers don't deploy to production; release engineers or automated pipelines do

Step 6: Incident response and vulnerability management.
These two controls are paired because they overlap operationally:

Documented incident response plan (IRP) — a runbook that defines what happens when a security event occurs, who is notified, and what the escalation path looks like
Vulnerability scans — at minimum quarterly for external‑facing systems, with evidence of scan results and remediation tracking
Penetration testing — not always required for a first audit, but increasingly expected by customers. If you haven't done one in 12 months, schedule one now

Step 7: Vendor risk management.
If you're processing any customer data through third‑party services, auditors will ask about your vendors. You need:

A vendor inventory — every third‑party system that handles, stores, or transmits customer data
Security questionnaires or SOC 2 reports (Type II, not just Type I) for critical vendors
Documented offboarding procedures for vendors when contracts end

Days 51–70: Evidence Collection and Monitoring

Step 8: Build your evidence repository.
Don't wait until the audit starts to gather evidence. Build your repository now — a shared drive, a Confluence space, or a purpose‑built tool. Every control needs continuous evidence, meaning evidence collected throughout the audit period, not just at the end.

Organize by TSC criterion, then by control. Label evidence with the date it was collected and the method (automated scan, manual review, system export). Auditors can't evaluate what they can't find.

Common evidence types by control:

Control Area	Evidence Type
Access management	User access lists (exported monthly), access review sign‑offs
Change management	GitHub/GitLab commit logs, Jira tickets with approvals
Incident response	Incident log, post‑incident review documents
Vulnerability management	Scan reports, patch remediation records
Vendor management	Vendor security questionnaires, SOC reports on file

Step 9: Implement continuous monitoring.
If you have the budget, a security monitoring tool (Drata, Vanta, Secureframe, etc.) automates evidence collection across most controls. These tools connect to your cloud environment, ticketing system, HRIS, and identity provider and pull evidence continuously. For a first‑time audit, they accelerate readiness significantly.

If you're doing this manually, assign an owner to each evidence collection task and set recurring calendar reminders. Monthly evidence collection is the minimum frequency auditors will accept — quarterly is better.

Days 71–90: Auditor Selection and Final Readiness

Step 10: Select your auditor.
Auditor selection matters more than most teams realize. Three things to evaluate:

Your industry's auditor — firms like Schellman, A‑LIGN, Coalfire, and Ryval have deep experience in specific verticals. A healthcare‑focused auditor will be more familiar with your customer requirements than a generalist firm.
Turnaround time — some auditors have 6‑week turnaround; others have 12+ weeks from fieldwork completion to report delivery. Ask directly.
Pricing structure — most auditors charge based on company size (employee count, revenue) and audit scope. First‑time audits at companies under 50 employees typically run $15,000–$30,000. Get quotes from at least three firms.

Request a readiness assessment call before you sign. Every reputable auditor offers this — it's a 30‑minute call where they review your current state and tell you whether you're ready to start. Use it.

Step 11: Conduct an internal pre‑assessment.
Before the auditor starts, do a dry run:

Pull evidence for every control for the full audit period
Ask a team member with no prior involvement to review it — if they can find everything without asking questions, your repository is ready
Check that all access reviews, vulnerability scans, and incident logs have been performed on schedule

Identify gaps. Fix them before the auditor engages. Gaps identified internally cost time; gaps found by auditors cost money and reputation.

Common Pitfalls

Starting without a clear scope. Beginning a SOC 2 project without defining which TSC criteria you're including leads to months of wasted effort implementing controls you don't need for your first audit.
Treating SOC 2 as an IT project. Security controls live in engineering, HR, and legal — not just in your infrastructure. If your compliance effort doesn't include these teams from day one, you'll hit gaps in access controls, employee offboarding, and vendor management that IT can't fix alone.
Skipping the evidence repository. Building evidence retroactively is painful, unreliable, and auditable. Auditors know the difference between a live repository and reconstructed evidence. Start collecting day one.
Underestimating the audit period. A SOC 2 Type II audit with a six‑month period will have less credibility with your customers than one with a twelve‑month period. If you have the time, run twelve months. It signals maturity.
Choosing the cheapest auditor. Price matters, but turnaround time, audit experience in your industry, and communication quality during the readiness phase matter more. A firm that's slow to respond before the audit will be slow during it.

Key Frameworks and Standards

SOC 2 Type II readiness intersects with several other frameworks:

NIST SP 800‑53 — if you operate in the federal space or handle government contracts, your SOC 2 controls map closely to NIST's moderate baseline.
ISO/IEC 27001:2022 — overlapping control objectives with a certification‑based structure; some companies pursue dual certification.
NIST CSF 2.0 — the Cybersecurity Framework maps directly to several SOC 2 TSC criteria; mapping your controls to NIST CSF before a SOC 2 audit simplifies the process.
CIS Controls v8 — a practical, prioritized set of cybersecurity controls that align with the Security TSC and provide an implementation checklist.

Your gap analysis should reference these frameworks if you anticipate needing compliance in multiple regimes.

Key Takeaways

Define a tight scope early and stick to the Security criterion for your first SOC 2 Type II audit.
Assign clear owners for every control; ownership is the difference between a smooth audit and a series of “who did what?” questions.
Start evidence collection on day one and keep it organized by TSC criterion; a well‑structured repository saves weeks of work.
Leverage automation (Drata, Vanta, Secureframe) where budget allows; it turns manual evidence gathering into a set‑and‑forget process.
Pick an auditor with relevant industry experience and a realistic turnaround time; a good fit reduces friction during fieldwork.

Conclusion

Reaching SOC 2 Type II compliance in 90 days is ambitious, but entirely doable when you follow a disciplined roadmap. Start by locking down scope and running a thorough gap analysis, then move quickly through access, change, incident, and vendor controls. Build a living evidence repository as you go, and consider a monitoring tool to keep the workload manageable. Finally, choose an auditor who understands your industry and run a pre‑assessment to catch any lingering gaps.

By treating SOC 2 as a cross‑functional, continuous effort rather than a one‑off IT project, you’ll not only pass the audit—you’ll embed security practices that protect your customers and your business for the long haul.