The SOC 2 Timeline Problem
Organizations approaching SOC 2 for the first time consistently underestimate how long the process takes. The audit itself is not the bottleneck. The preparation is. You will spend more time building policies, implementing controls, collecting evidence and remediating gaps than you will spend working with the auditor. If you plan for three months and it takes nine, your sales team loses deals and your enterprise prospects move on.
This guide breaks down the SOC 2 timeline month by month. It covers both Type I and Type II paths, identifies where delays happen and explains how to schedule penetration testing within the audit window so findings do not derail your report.
Decision Point: Type I vs. Type II
Before you build a timeline, you need to decide which report type to pursue. This decision affects everything that follows.
SOC 2 Type I evaluates the design of your controls at a specific point in time. The auditor examines whether your controls exist and are designed appropriately. There is no observation period. A Type I can be completed in 2-3 months if your security program is reasonably mature. Many organizations use Type I to get a report into the hands of their sales team quickly while building toward Type II.
SOC 2 Type II evaluates the operating effectiveness of your controls over a period, typically 3 to 12 months. The auditor needs evidence that your controls were not just designed well but were consistently operating throughout the observation window. Type II is what most enterprise buyers and partners ultimately require. Plan for 6-12 months from start to finish.
The most common path: complete a Type I first, then immediately begin the Type II observation period. This gives your sales team something to show prospects within 90 days while you accumulate the operating history needed for Type II.
Month 1-2: Readiness Assessment and Gap Analysis
The first step is understanding where you stand. A readiness assessment compares your current security controls against the Trust Services Criteria you have selected. Security (Common Criteria) is required for every SOC 2 audit. Availability, Confidentiality, Processing Integrity and Privacy are optional and selected based on your business and what your customers expect.
Scoping Your System Boundary
Define exactly which systems, infrastructure, applications and third-party services fall within your SOC 2 scope. This is the system boundary, and every control must be evaluated within it. Common scoping mistakes include:
- Excluding your cloud infrastructure (AWS, GCP, Azure) when your application runs on it
- Forgetting third-party services that process customer data (payment processors, email providers, analytics platforms)
- Including too much, which increases audit cost and complexity without adding value
Work with your auditor during scoping. They will tell you what needs to be included and what can reasonably be excluded. Getting the boundary right at the start prevents scope creep during fieldwork.
Gap Analysis
The gap analysis produces a list of every deficiency between your current state and SOC 2 requirements. Typical gaps for first-time organizations include:
- Missing policies
- Information security policy, access control policy, change management policy, incident response plan, risk assessment procedure and vendor management policy. Most organizations have some of these informally but lack formal documentation.
- Insufficient logging and monitoring
- SOC 2 requires evidence that you detect and respond to security events. This means centralized logging, alerting on anomalous activity and documented response procedures.
- No formal access reviews
- Auditors expect periodic access reviews, typically quarterly, where you verify that user access levels are still appropriate. If you have never done a formal access review, this is a gap.
- No penetration testing
- Common Criteria CC7.1 requires vulnerability detection procedures. Nearly every auditor interprets this as requiring a recent penetration test from a qualified third party.
Prioritize gaps by risk level and remediation effort. Some gaps (like writing a policy) take days. Others (like implementing a SIEM) take months.
Month 2-4: Remediation and Policy Development
This is the most labor-intensive phase. You are building or formalizing the security controls that the auditor will evaluate. How long this takes depends entirely on your starting point.
Policy Development
Every SOC 2 audit requires documented policies. At minimum, you need:
- Information Security Policy (overarching security governance)
- Access Control Policy (user provisioning, deprovisioning, least privilege)
- Change Management Policy (how code and infrastructure changes are reviewed and deployed)
- Incident Response Plan (how you detect, respond to and recover from security incidents)
- Risk Assessment Procedure (how you identify and evaluate risks)
- Vendor Management Policy (how you evaluate third-party security)
- Data Retention and Disposal Policy
Write policies that reflect what you actually do. Auditors will test whether your team follows the documented procedures. A policy that says you conduct quarterly access reviews means the auditor will ask for evidence of four access reviews during the observation period. Do not write aspirational policies. Write accurate ones.
Technical Remediation
Implement the technical controls identified during gap analysis. Common remediation items include:
- Configuring centralized logging (CloudTrail, CloudWatch, Datadog or equivalent)
- Enabling multi-factor authentication across all systems
- Implementing automated deployment pipelines with code review requirements
- Setting up vulnerability scanning on a regular schedule
- Encrypting data at rest and in transit where not already configured
- Establishing backup and recovery procedures with documented testing
Document every change. The auditor will want to see evidence that controls were implemented, not just that they exist today. Git commits, configuration change logs and deployment records all serve as evidence.
Penetration Testing: Timing and Scope
Schedule your penetration test during month 3 or 4. This timing is deliberate. You want the test to occur after initial remediation is complete (so you are testing your actual security posture, not a known-broken state) but early enough to leave time for remediating any findings before the observation period ends.
What the Pentest Should Cover
The penetration test scope must align with your SOC 2 system boundary. If a system is in scope for the audit, it should be in scope for the pentest. This typically includes:
- Production web application (all customer-facing functionality)
- API endpoints
- Authentication and authorization mechanisms
- Cloud infrastructure within the trust boundary
- Administrative interfaces and internal tools accessible from the network
A standard penetration test takes 8-12 business days. Add 2-4 weeks for report delivery and 4-8 weeks for remediation. This is why month 3-4 scheduling works: it gives you a full remediation window before the auditor reviews your controls.
After the Pentest
When you receive the penetration test report, triage findings immediately. Critical and high-severity vulnerabilities need remediation before the audit. Medium findings should have a documented remediation plan with timelines. Low findings can be accepted with documented justification.
Keep evidence of every fix: pull requests, deployment logs, configuration changes and retest confirmations. This remediation evidence is exactly what the auditor wants to see. It demonstrates that your vulnerability management process works.
Month 4-6: The Observation Period (Type II)
For Type II audits, this is the period where the auditor evaluates whether your controls are consistently operating. There is no shortcut. You need a minimum of three months, and most auditors prefer six.
During the observation period, your job is to operate your controls consistently and collect evidence. This means:
- Conducting access reviews on the schedule defined in your policy
- Following your change management process for every deployment
- Logging and responding to security events per your incident response plan
- Running vulnerability scans at the frequency defined in your policy
- Completing vendor security reviews for any new third-party services
- Documenting any control exceptions or deviations with root cause and corrective action
The biggest risk during the observation period is inconsistency. One missed access review or one deployment that bypassed code review creates a control exception the auditor must document. Build these activities into your team's recurring workflows so they happen automatically.
Common Delays and How to Avoid Them
After supporting hundreds of SOC 2 engagements on the penetration testing side, we have seen the same delays repeat across organizations of every size.
| Delay | Root Cause | Prevention |
|---|---|---|
| Evidence collection takes weeks instead of days | Evidence was never collected systematically during the observation period | Assign evidence collection responsibilities to specific team members and collect monthly |
| Policies do not match actual practice | Policies were written aspirationally, not based on current operations | Write policies that describe what you actually do, then improve iteratively |
| Pentest findings require extended remediation | Pentest was scheduled too late in the timeline | Schedule the pentest at month 3-4, not month 5-6 |
| Auditor availability pushes fieldwork back | Auditor was engaged too late or during busy season (Q4/Q1) | Engage your auditor at month 1 and lock in fieldwork dates early |
| Scope creep during audit | System boundary was not clearly defined at the start | Get written confirmation of scope from the auditor before remediation begins |
What the Final Report Includes
The SOC 2 report is produced by your auditor (a licensed CPA firm) and contains several sections. Understanding the report structure helps you prepare better evidence.
Section I: Independent Service Auditor's Report. The auditor's opinion on whether your controls are suitably designed (Type I) or suitably designed and operating effectively (Type II). This is the section your customers read first.
Section II: Management's Assertion. Your organization's statement that the system description is accurate and the controls are designed and operating effectively.
Section III: System Description. A detailed description of your system, its boundaries, infrastructure, software, people and procedures. This is the section that defines scope.
Section IV: Trust Services Criteria, Controls and Tests. The core of the report. Each Trust Services Criterion is listed with the controls you have in place and the auditor's test results. Any control exceptions are documented here.
Section V: Other Information (optional). Management's response to any identified exceptions or qualifications.
A "clean" report means no exceptions in Section IV. This is your goal. Every unresolved pentest finding, every missed access review and every undocumented incident becomes a potential exception.
How Sherlock Supports the Pentest Component
Sherlock Forensics has delivered penetration tests for hundreds of SOC 2 engagements since 2006. We understand what auditors require because we have seen their feedback across dozens of CPA firms.
Here is what we do differently for SOC 2 engagements:
- Scope alignment. We review your SOC 2 system boundary before testing begins and confirm scope with your auditor if needed. No wasted effort testing systems outside the trust boundary.
- Audit-ready reports. Our reports reference PTES and OWASP methodologies, include CVSS-scored findings with evidence and map results to relevant Trust Services Criteria. Auditors accept them without follow-up questions.
- Timeline coordination. We schedule the engagement to fit your audit window, with report delivery timed to give you a full remediation cycle before fieldwork begins.
- Remediation support. Our team is available to answer technical questions during remediation and provide retest validation once fixes are deployed.
- Certified testers. All engagements are led by CISSP, ISSAP and ISSMP certified consultants with direct SOC 2 experience.
Standard SOC 2 penetration tests start at $5,000 CAD with typical delivery in 8-12 business days. See our SOC 2 penetration testing page for scoping details, or order directly.
Frequently Asked Questions
How long does a SOC 2 Type II audit take from start to finish?
Plan for 6 to 12 months. This includes 1-2 months for readiness assessment and gap analysis, 2-3 months for remediation, a minimum 3-month observation period (most auditors require 6 months) and 4-6 weeks for the auditor to complete fieldwork and deliver the final report. Organizations with existing security programs can compress the preparation phases.
What is the difference between a readiness assessment and the actual audit?
A readiness assessment is a pre-audit evaluation that identifies gaps between your current controls and SOC 2 requirements. It produces a prioritized remediation list. The actual audit is a formal examination by a licensed CPA firm that produces the SOC 2 report. The readiness assessment prevents surprises. Skipping it is the single most common cause of audit delays and qualified opinions.
When should I schedule the penetration test?
Month 3 or 4 of your timeline. This gives you time to remediate findings before the observation period ends. A standard engagement at Sherlock Forensics takes 8-12 business days with report delivery within 5 business days of testing completion. Budget 4-8 additional weeks for remediation of any critical findings.
What causes the most common delays?
Incomplete evidence collection, policies that do not match actual practice and unresolved penetration test findings. Organizations that assign a dedicated SOC 2 project owner, build evidence collection into recurring workflows and schedule penetration testing early avoid most delays.
Can I start with Type I and move to Type II?
Yes. This is the standard approach for first-time SOC 2 organizations. Complete the Type I in 2-3 months to get a report for your sales pipeline, then immediately begin the Type II observation period. The Type II audit evaluates control effectiveness over 3-12 months, building on the controls you designed for Type I.