A SOC 2 audit takes as long as readiness, the observation window for a Type 2 report, fieldwork and report drafting add up to. The AICPA sets no minimum window, so the window is agreed with the auditor. The article covers scope, Type 1 versus Type 2, the dry run, bridge letters, five causes of delay, backward planning from a customer deadline and the AICPA exposure drafts for 2027.
- A SOC 2 audit is four phases: readiness, the observation window (Type 2), fieldwork, and report drafting and review.
- The AICPA sets no minimum window length; agree the window and the evidence format with your auditor before it opens.
- Type 1 covers design at one date; Type 2 also tests operation over a period and is what most procurement teams request.
- A bridge letter is management's statement for the gap since the period ended, not an opinion from the CPA firm.
- Plan backward from the date the report must be in hand, and treat the dry run as the gate that opens the window.
A SOC 2 audit takes as long as its four parts add up to: readiness work before the window opens, an observation window for a Type 2 report, and fieldwork plus report drafting after the window closes. You choose the window and your auditor sets the rest, so plan the calendar backward from the date a customer needs the report.
SOC 2 is an attestation report issued by a licensed CPA firm, not a certification. The AICPA describes the SOC suite as assurance reports that CPAs provide so users can assess the risks of outsourcing a service. This article explains each phase, what stretches it, how Type 1 and Type 2 differ in time, what a bridge letter covers, and how to build a calendar you can defend to a customer.
How long does a SOC 2 audit take?
The elapsed time is the sum of four phases: readiness, the observation window (Type 2 only), fieldwork, and report drafting and review. The AICPA standards do not set a minimum window length, so no single number is correct for every company. Your auditor and the customers who will read the report shape the choice, and the auditor's engagement letter is the document to plan against.
The table below shows where the time goes and what controls each phase.
| Phase | What happens | What sets its length | Who owns it |
|---|---|---|---|
| Scoping and readiness | Pick the trust services categories, define the system boundary, write the system description, assign control owners, close gaps. | How many controls already operate, how many are undocumented, and how many systems sit in scope. | Compliance lead with control owners |
| Observation window (Type 2) | Controls run and generate evidence: access reviews, change approvals, incident records, vendor reviews. | The period you and the auditor agree, plus how often each control occurs within it. | Control owners |
| Fieldwork | The auditor samples evidence, interviews owners, tests design and operation, and raises exceptions. | Sample sizes, evidence quality, and how fast owners answer requests. | Auditor with the compliance lead |
| Report drafting and review | The auditor drafts the opinion and test results; management reviews the system description and responses to exceptions. | Number of exceptions, review rounds, and auditor queue. | Auditor and management |
Which trust services categories belong in scope?
The AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022) cover five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is the category every SOC 2 report includes. Each category you add brings more criteria to test, so scope is the first lever on the timeline.
A practical way to scope: start from the questions your customers actually ask in their security reviews. If buyers ask about uptime commitments, add Availability. If they ask how you protect their contract data, add Confidentiality. If nobody asks, a Security-only first report is a legitimate starting point, and you can add categories in the next period.
Type 1 or Type 2: which one first?
A Type 1 report describes the design of your controls as of a single date. A Type 2 report covers design and also tests whether the controls operated effectively over a period. Type 1 is faster because there is no window; Type 2 is what most procurement teams ask for because it shows controls running, not only existing.
| Question | Type 1 | Type 2 |
|---|---|---|
| What does the auditor test? | Whether controls are suitably designed at one date. | Whether controls are suitably designed and operated effectively across the period. |
| Is there an observation window? | No. | Yes, agreed with the auditor before it starts. |
| What does the evidence look like? | Policies, configurations and a snapshot of each control. | Samples drawn from the whole period: tickets, approvals, review records, logs. |
| When does it fit? | A customer needs something in hand now and accepts a first-step report. | The customer's security team, or your own, wants proof of operation over time. |
Some teams issue a Type 1 first to answer an urgent request, then run the Type 2 window that follows. That path costs two engagements, so confirm with the customer that a Type 1 satisfies the request before you commit to it.
How long should the observation window be?
The window should be long enough that every control has operated enough times to be sampled, and no longer than your first customer deadline allows. An annual control, such as a yearly policy review or penetration test, may occur only once in a short window, which leaves the auditor little to sample. A control that runs daily gives many samples in a month.
The AICPA's SOC suite page links a Journal of Accountancy article from 30 April 2026 titled "The risks of quick-turn SOC engagements and what CPAs should know". It is a journal article, not AICPA standards guidance, but it is worth reading before you accept an offer to compress the work: a short calendar is a decision about the evidence you will have, and your customers' reviewers can see the period on the face of the report.
Questions to settle with the auditor before the window opens:
- Which controls occur less often than monthly, and how will they be sampled?
- What is the exact start date, and what evidence must exist from day one?
- Which systems and vendors are in scope, and which are carved out?
- What happens to the window if a control fails in month two?
What does readiness involve before the window opens?
Readiness turns what your team does into controls an auditor can test. Most of the elapsed time here goes to gaps that need a decision, not to writing: a missing access review, an undocumented change process, a vendor list nobody owns.
- Write the system description: services, infrastructure, software, people, procedures and data in scope.
- Map each control to the criteria it supports, so that one control can cover several criteria without duplication.
- Name an owner for every control and agree how often it runs and where its evidence is stored.
- Run each control once as a dry run and fix what fails before the window starts.
- Agree the evidence format with the auditor, so fieldwork does not stall on screenshots nobody can date.
The step that most often adds weeks is the dry run, because it shows which controls exist only in people's habits. Treat the dry run as a gate: the window opens only after every control that failed the dry run has been fixed or has a documented remediation date agreed with the auditor.
What happens during fieldwork and report issuance?
After the window closes the auditor requests evidence for the samples they selected, tests each control, and records exceptions. Exceptions are not an automatic failure: the report states what was tested, what was found and how management responded. A clean evidence trail shortens fieldwork, and a scattered one lengthens it.
Two habits keep this phase short. Store evidence in one place with the control, the date and the owner attached, and answer auditor requests inside a stated number of working days. Both are process decisions you can make in readiness, long before an auditor emails you.
What is a bridge letter and when do customers ask for one?
A bridge letter, sometimes called a gap letter, is a statement from your management that covers the days between the end of the report's period and the date the customer is reading it. It is management's own representation, not an opinion from the CPA firm, so customers treat it as supporting information beside the report and not as a replacement for the next one.
Customers usually ask for a bridge letter when the report period ended several months ago and their own review calendar needs coverage up to today. Plan for it by keeping a record of changes to controls, incidents and scope since the last period ended, because that is what the letter has to be able to state truthfully. Ask your auditor how they expect the letter to be worded before you send one.
What stretches a SOC 2 timeline?
Five causes explain most slips, and each can be settled before the window opens.
- Scope that grows during the audit. Adding a system or a category mid-window restarts evidence collection for it.
- Controls with no named owner. Fieldwork stops when nobody can answer for a sample.
- Evidence held in chat threads and inboxes. The auditor cannot test what cannot be dated and attributed.
- Annual controls timed badly. An annual review scheduled for the day after the window closes leaves nothing to test.
- Vendor dependencies left until fieldwork. Subservice organization reports must be collected and reviewed, and vendors answer slowly.
How do you build the calendar backward from a customer deadline?
Start with the date the customer needs the report in hand, subtract the auditor's stated reporting time, subtract the observation window, and the remainder is your readiness budget. The example below is arithmetic for illustration, not a benchmark: the durations are placeholders to replace with your auditor's figures.
| Step | Placeholder | Working backward from a report-in-hand date |
|---|---|---|
| Report in customer's hands | Fixed by the customer | Day 0 |
| Report drafting and review | Auditor's figure | Day 0 minus that figure |
| Fieldwork | Auditor's figure | Window end date |
| Observation window | Agreed length | Window start date |
| Readiness | Whatever remains | Today |
If the readiness budget is negative, you have two honest options: ask the customer whether a Type 1 report satisfies the request, or move the deadline. Compressing the window is the third option; the April 2026 Journal of Accountancy article on quick-turn SOC engagements, linked above, discusses its risks.
SmartSuite's Compliance Management solution centralizes policies, obligations, controls, testing and evidence, and maps controls to frameworks including SOC 2, which gives each control one owner, one evidence trail and one calendar.
What is changing in SOC 2 for 2027?
On 26 October 2026 the AICPA posted exposure drafts of the proposed 2027 SOC 2 Trust Services Criteria and Description Criteria, listed on its SOC suite page. They are drafts, so nothing in them is final and the 2017 criteria with revised points of focus remain the ones in use until the AICPA says otherwise. Teams planning a window that straddles 2027 should ask their auditor which criteria version the report will cite.
For the wider picture of how SOC 2 sits beside your other obligations, see SOC 2 compliance as a connected workflow, SOC 2 compared with ISO 27001 and NIST, and the glossary entry on SOC 2 compliance.
Final thought
The timeline question is really three decisions: how much scope, which report type, and how long a window. Make those decisions with your auditor and your customer's reviewer in the room, work backward from the date the report must be in hand, and treat the dry run as the gate that opens the window. A calendar built that way holds up when a customer asks how you arrived at it.
Linked Articles
Learn how SOC 2 compliance works in Connected GRC by linking Trust Services Criteria, controls, evidence, issues, vendors, cyber risk, privacy, and audit readiness.
Learn the difference between SOC 2, ISO 27001, and NIST, where controls overlap, and how Connected GRC helps build a common control framework.
Learn the difference between SOC 2 and SOX, where controls overlap, where they diverge, and how Connected GRC reduces duplicate testing and evidence requests.
Frequently Asked Questions
Answers to the questions readers ask most about this topic.
It takes the sum of readiness, the observation window for a Type 2 report, fieldwork and report drafting. The AICPA standards set no minimum window length, so the window is agreed with your auditor. Ask the auditor for their fieldwork and reporting time, then work backward from the date the customer needs the report.
No. SOC 2 is an attestation report issued by a licensed CPA firm after it examines your controls against the AICPA Trust Services Criteria. The AICPA describes its SOC services as assurance reports that CPAs provide, so say "SOC 2 report" or "attestation" and never "certified".
A Type 1 report covers whether controls are suitably designed at a single date. A Type 2 report covers design and also tests whether controls operated effectively across an agreed period. Type 1 is faster; Type 2 is what most procurement teams request because it shows controls running over time.
A bridge letter, sometimes called a gap letter, is management's statement about the days between the end of the report period and the date a customer reads it. It is not an opinion from the CPA firm. Keep a change and incident record since the period closed so the letter can be accurate, and ask your auditor how to word it.
The AICPA posted exposure drafts of proposed 2027 SOC 2 Trust Services Criteria and Description Criteria on 26 October 2026. They are drafts. The 2017 criteria with revised points of focus (2022) remain in use until the AICPA says otherwise, so ask your auditor which version your report will cite.

Put Connected GRC into action with SmartSuite
Map controls, collect evidence, run assessments, manage remediation, and report readiness - all from a single connected system.