SOC 2 audit timeline: from kickoff to the report

A SOC 2 timeline has two different clocks. The first is the readiness and examination clock: define scope, implement controls, collect evidence, complete fieldwork and approve the report. The second applies to Type II: controls must operate throughout an observation window before the auditor can conclude on operating effectiveness. Confusing those clocks is why startups promise a report in eight weeks when the customer actually needs six months of evidence.

The timeline at a glance

Phase 1: customer request and scope decision

The first week is not administrative overhead. Ask the customer what “SOC 2” means in their procurement process: Type I or Type II, report age, criteria, observation period, bridge-letter requirements and any auditor or report-format constraint. Ask when the report is needed for contract signature, production access and renewal; these may be different dates.

Define the system boundary with the auditor and your technical team. List production accounts, applications, repositories, pipelines, support tools, offices, people and subprocessors. Identify the data processed and hosting regions. A report can cover a deliberately narrow service, but the boundary must be honest. Excluding a system that can change production or access customer data merely to shorten the timeline creates a scope problem later.

Choose Security, which is mandatory, and optional criteria based on the service and buyer. Availability may be appropriate when uptime and resilience are contractual promises. Confidentiality is common for sensitive customer information. Privacy and Processing Integrity require additional work and should be included for a genuine business reason. The SOC 2 guide explains the criteria and how they differ from ISO 27001.

Phase 2: readiness assessment and remediation

Readiness begins with a current-state review, not a policy download. Check whether your team actually has MFA enforced, privileged access limited, joiner-mover-leaver records, quarterly access reviews, vulnerability remediation SLAs, approved changes, tested backups, vendor reviews, incident response and security training. Mark each control as designed, implemented, operating or unsupported by evidence.

Weeks one to three usually produce a scope document, control matrix, evidence map, risk register and remediation plan. The plan should name one owner per control and a due date. Founders often underestimate the coordination required: engineering must make cloud and deployment changes, operations must run reviews, HR must preserve training and leaver records, and leadership must approve risk decisions.

Readiness is complete when the team can explain each control, demonstrate it in the live environment, show evidence from the relevant period and repeat the process without a consultant in the room. A gap report that only lists missing policies is not readiness.

Phase 3: implementation and evidence setup

Weeks three to ten commonly cover policy tailoring, control implementation and evidence workflows. Policies should state what your company does, who owns it, how often it occurs and what record proves it. Do not write a quarterly access review policy if no one has a calendar reminder or a system export to perform it.

Automate collection where it reduces repetitive exports: identity-provider users and MFA, cloud configuration, repository settings, endpoint status and vulnerability scans. Keep human judgement where it matters: approving risk, reviewing vendors, assessing a change, deciding incident severity and confirming that a control operated as intended. A platform can organise evidence; it cannot make an unowned process effective.

Run a mock auditor request before fieldwork. Pick samples, follow links, check timestamps and redact secrets. If the same evidence is stored in three places, choose one source of truth. The evidence checklist provides a category-by-category starting point.

Type I: kickoff to final report

Once readiness is stable, the audit firm holds a kickoff and issues a prepared-by-client (PBC) list or information request list. The team confirms the system description, criteria, control owners and examination date. Fieldwork may last two to six weeks for a small, clear scope, but the elapsed time depends on how quickly questions are answered.

Auditors conduct walkthroughs with control owners, inspect configurations and supporting records, and test that controls are designed and implemented. They may ask for revised system-description wording, additional samples, evidence of management review or explanations for exceptions. Respond with a clear answer and source link; sending a large unindexed folder makes the auditor’s work and your own harder.

After testing, the firm prepares a draft. Allow time for factual accuracy review: system name, dates, subservice organisations, data locations and control descriptions must be correct. Do not edit an auditor’s opinion to remove an uncomfortable fact. Discuss factual corrections and remediation with the firm, then agree report issuance and distribution under the customer’s NDA process.

Type II: the observation window

For Type II, the period starts only when the agreed controls are in operation and evidence can be retained. A three-month window may meet a particular buyer’s policy; six months is common for an early enterprise report; twelve months provides the broadest history and aligns well with annual renewal. The window is not automatically extended because a startup would prefer more time. Confirm dates in the engagement letter.

During the window, maintain a control calendar. Complete access reviews on time, record who reviewed and what changed, attach approvals to production changes, log vulnerability exceptions, review suppliers, test backups and run an incident exercise. If a control is missed, record the event, impact and corrective action. Backfilling a spreadsheet at the end of the window is weak evidence and can itself become an exception.

Hold monthly evidence health checks. Review upcoming cadences, inspect a sample of completed evidence and ask owners what has changed in the system. A new cloud account, acquisition, office, subprocessor or production workflow may require a scope review. Keep the auditor informed about material changes rather than discovering them during final fieldwork.

Final Type II fieldwork and report

At the end of the period, the auditor selects samples across the window and tests operating effectiveness. Fieldwork often takes four to ten weeks, depending on scope and response speed. The auditor may sample access reviews from different quarters, changes from different months, leavers, vulnerabilities, incidents, vendors and backup tests. Evidence should show date, owner, population, selection, action and outcome.

Exceptions are discussed with the control owner and management. A single missed review is not automatically fatal, but repeated failures or an ineffective control can affect the opinion. Remediate what you can, document the root cause and ensure the final report describes the situation accurately. After factual review, the final report is issued and shared with approved customers.

What usually causes delays?

• Unclear customer acceptance: discovering after fieldwork that the customer needed Type II or an additional criterion.
• Scope changes: adding an application, production account, region or subprocessor after testing begins.
• Auditor availability: waiting for a firm with the right independence, experience or report date.
• Untested controls: policies exist, but access reviews, backups, vulnerability remediation or vendor reviews have not operated.
• Evidence scattered across tools: owners cannot find source records or timestamps do not cover the relevant period.
• Founder dependency: every approval waits for one executive who is travelling or closing a funding round.
• Engineering release pressure: changes bypass the approval trail, or the deployed environment no longer matches the documented system.
• Slow PBC responses: the audit team waits days for answers, turning a two-week review into a month.

Prevent delay by reserving owner time, freezing the boundary before the examination, agreeing response SLAs and reviewing evidence monthly. If a customer is driving the project, share an honest milestone plan rather than a single optimistic report date.

How to plan backwards from a customer deadline

Start with the date the customer needs the final report, then reserve four to ten weeks for Type II fieldwork and report production. Work backwards through the observation period, then add eight to twelve weeks for readiness and auditor scheduling. For a six-month Type II window, that commonly means starting readiness roughly ten to twelve months before the final report date. Type I can be materially shorter because there is no observation window, but fieldwork and auditor availability still need room.

If the deal cannot wait, ask whether a Type I, a bridge letter, a penetration test, a security questionnaire pack or an audit-in-progress statement will unblock the next stage. These are not interchangeable with a Type II report; use the customer’s written acceptance. The Type I vs Type II guide gives a decision framework, and our SOC 2 readiness service can turn the schedule into an owned plan.

FAQs

Can a SOC 2 Type II report be completed in three months?

Some auditors and buyers accept a three-month observation window, but that is not universal. Confirm the required period before starting. Readiness, auditor scheduling, fieldwork and reporting are additional time.

Does the audit start at kickoff?

The engagement may start at kickoff, but a Type II observation period starts on the agreed date when controls are ready to operate. Readiness work before that date helps prepare; it is not automatically part of the period.

Can we speed up the report with Vanta or Drata?

Platforms can automate collection and reduce manual work, but they do not resolve scope, ownership, design gaps or missed controls. Choose a platform based on your environment and evidence needs rather than treating it as a shortcut.