SOC 2 Type 2: what twelve months of observation actually looks likePremium

Practitioner reference for SaaS founders, CISOs, controllers, compliance leads, and the engineering manager who has just been told they own a SOC 2 control · 2026-05-25 · Written from twelve years of either preparing companies for SOC 2 Type 2, being the customer demanding it from a vendor, or sitting opposite the CPA firm during the audit

Why this guide exists

Most of what is written online about SOC 2 is about getting started — what SOC 2 is, why customers want it, how to begin a programme. Almost nothing is written about what month seven feels like.

Month seven is where most SOC 2 Type 2 engagements quietly go off the rails. The kick-off was clean. The system description got drafted. The initial set of controls got picked. The first three months of the observation period went smoothly because everybody was paying attention. Then a control failed in month four and the team did not realise that meant something. Then a second control failed in month six because somebody changed a process without telling the compliance lead. By month seven the auditor has reviewed the first interim sample and started asking pointed questions, the controller has discovered evidence is incomplete for two control objectives, and somebody is calculating whether the report will land in time for the enterprise renewal that was the entire reason this programme exists.

This guide is what I tell people when they are about to start a SOC 2 Type 2 engagement and want to know what they are actually signing up for. It is also what I send when somebody asks me, in month seven, why everything is suddenly on fire.

The two reports, briefly

A SOC 2 Type 1 report is a point-in-time assessment. The auditor verifies that the controls described in the system description are suitably designed and in place on a specific date. It takes six to ten weeks; the audit work is concentrated in the last two; it produces a report dated as of a specific point. Customers accept it, sometimes grudgingly, as evidence of programme establishment.

A SOC 2 Type 2 report is an over-time assessment. The auditor verifies that the same controls were operating effectively across an observation period — typically six months for a first-year report, twelve months for subsequent years. The audit work spans the entire period; the field work is concentrated in the last six weeks; the report is dated as of the end of the observation period. Customers prefer it, often strongly, because it answers a different question: not whether your controls existed at a moment, but whether they actually worked for a year.

Most companies skip Type 1. They run a readiness period internally, then start the Type 2 observation immediately. Some run Type 1 first to demonstrate programme establishment to customers, then start the Type 2 observation on the report date. The second pattern adds two months of elapsed time and ten to twenty percent of audit fees; the first pattern saves the cost but loses the interim deliverable. Both work. The decision depends on whether customers are demanding evidence now or are willing to wait twelve more months.

There is no Type 3. SOC 3 exists but is a different artefact — a public-facing version of SOC 2 designed for general use, prepared from a Type 2 engagement. Most companies who think they want SOC 3 actually want SOC 2 Type 2 with a customer-friendly summary.

What “observation period” actually means

The phrase “observation period” gets used as though it is a calendar window during which controls are observed. It is more specific than that. The observation period is the period over which the auditor will sample evidence of the operating effectiveness of each control. The auditor selects samples from the period; the auditee produces evidence for the sampled instances; the auditor evaluates whether the evidence demonstrates that the control operated as designed.

This has three operational consequences that many first-time SOC 2 programmes miss.

Controls must operate continuously. Not “we did this control in month one and then we are good.” If the control is “quarterly access reviews,” the auditor expects four reviews across a twelve-month observation, each with the same rigour and the same evidence package. If the control is “code changes require ticket and approval,” the auditor expects every code change across the observation period to have a ticket and approval, and they will sample fifteen or twenty to verify.

Evidence must be available for the entire period. Not just the last quarter before the audit. If your logging was misconfigured for two months in the middle of the period, you have an evidence gap for the controls that depended on those logs. The auditor will note it and it becomes either an exception (a documented failure of the control to operate effectively) or a qualified opinion (if the evidence gap is material).

Process changes during the period count. If you changed your change-management process in month four, the auditor will sample both before and after the change and evaluate each against the control as it was operating. Two operating models in one period is workable but it requires documentation.

The shorthand that works: during an observation period, the auditor is going to ask whether the control operated effectively over the entire window, and “effectively” means as designed, evidenced, and consistent.

Trust Services Criteria — picking the right ones

SOC 2 reports are organised around the AICPA’s Trust Services Criteria. There are five categories:

• Security — the baseline. Always included. Covers logical and physical access, system operations, change management, risk mitigation. Roughly forty-five common criteria.

• Availability — included where the service has uptime commitments. Backup and recovery, monitoring, capacity planning.

• Processing Integrity — included where the service performs processing that customers rely on for accuracy (financial systems, billing platforms, data processing services). Verification, monitoring of processing.

• Confidentiality — included where the service handles confidential information beyond personal data (intellectual property, customer business data subject to NDA). Information classification, handling.

• Privacy — included where the service collects or processes personal data and the auditor evaluates against the privacy notice. Privacy notice, choice and consent, collection, use, retention, disclosure, quality, monitoring.

Most SaaS companies start with Security only. Some add Availability immediately. A few add Confidentiality. Privacy is rarely included in first-year SOC 2 because privacy programmes typically lag security programmes by eighteen to thirty months in maturity.

The cost difference matters. Each additional category adds roughly fifteen to twenty-five percent to audit fees, and a similar fraction to internal preparation time. The marginal value of adding a category depends entirely on whether customers are demanding it. If three enterprise customers in your last quarter have asked for “SOC 2 with Confidentiality,” the addition is worth it. If no customer has asked, the addition is over-engineering.

Trust Services Criteria are not a la carte. You cannot include “the parts of Security that are easy and skip the hard ones.” Within a category you take the full criteria set. The optionality is at the category level.

The system description — what most people get wrong

Every SOC 2 report opens with a System Description. This is the company’s narrative description of the service being audited: what it does, who uses it, how it is delivered, what infrastructure supports it, what controls operate, and where the boundary of the audit sits. The system description is prepared by management; the auditor verifies it is fairly stated.

The system description is the document people spend the least time on and that the auditor reviews the most carefully. Three common failures:

The scope is sloppy. The system description names the service being audited and the supporting infrastructure. If your company sells three products and the audit is over one of them, the system description has to make that clear. If your shared infrastructure (single sign-on, monitoring, customer support tooling) supports multiple products, the system description has to be specific about whether those shared services are in scope. I have seen first-time SOC 2 reports where the system description was written so loosely that the audit effectively covered everything, including business units the company did not intend to include, leading to a chaotic field work phase and a delayed report.

The subservice organisations are mishandled. If you run on AWS, GCP, or Azure, your cloud provider is a subservice organisation under SOC 2 conventions. You have two options: carve-out (you describe what the subservice provider does, exclude it from your audit, and indicate that customers should review the subservice provider’s own SOC 2) or inclusive (you include the subservice provider’s relevant controls in your audit scope and the auditor verifies them). Almost everyone carves out AWS / GCP / Azure; the inclusive method is impractical because the cloud provider’s controls are tested in their own SOC 2 and replicating that work is wasteful. The system description has to be explicit about which subservice providers are carved out and what controls they perform that your customers rely on. Common omissions: managed database services, managed Kubernetes, managed email, managed SSO providers, payment processors.

The system description and the control matrix drift. The system description names controls that the control matrix does not, or vice versa. The auditor will flag this. The fix is mechanical: both documents must align, and the alignment must be maintained through the observation period as controls change.

A useful test: print the system description and the control matrix side by side and verify that every control mentioned in the description is in the matrix and every control in the matrix has a mention in the description. Boring; effective.

The first ninety days — what to do

If you are kicking off a SOC 2 Type 2 engagement, the first ninety days are setup. The observation period has not started yet (you will pick the start date during this phase). Five workstreams operate in parallel.

One. Scope and category decision. Which products, which infrastructure, which Trust Services Criteria. Document the rationale. This decision is hardest to change later.

Two. Auditor selection. Get proposals from three to five CPA firms. Big Four (Deloitte, EY, KPMG, PwC) for the audit signal value if you are selling to large enterprise; mid-tier firms (Schellman, Crowe, A-LIGN, BDO, Grant Thornton) for the bulk of the SaaS market — same audit quality, lower cost, more responsive engagement teams; boutique firms (Prescient, Linford, Sensiba) for smaller engagements or specialised industries. The audit firm signal matters in some sales conversations but matters less than people think. The audit firm relationship matters considerably more than the audit firm logo. Pick the firm whose engagement team you actually want to work with for five years.

Three. Control selection and the system description. Draft both. The control selection should map every Trust Services Criteria common criterion to one or more controls operating in your environment. There is no fixed number; typical first-year SOC 2 reports have somewhere between seventy and a hundred and twenty controls.

Four. Evidence collection infrastructure. This is where continuous-monitoring platforms (Drata, Vanta, Secureframe, Sprinto, Hyperproof, OneTrust) earn their cost. They automate evidence collection for many common controls — terminations propagated within twenty-four hours, code changes have associated tickets, MFA enforcement is universal, backups are completing successfully. The platforms do not replace the underlying controls; they instrument the evidence trail. Companies running SOC 2 without continuous monitoring spend two-to-three times the internal effort during the audit phase. If you are doing this without one, plan accordingly.

Five. Readiness assessment. Run a mock audit against your controls before starting the observation period. The auditor will often do this as a paid readiness review; an independent advisor can do it instead. The readiness assessment surfaces controls that look fine on paper but do not have evidence, controls that are misconfigured, and controls that have not actually been implemented. Fix everything surfaced before the observation period starts. Fixing during the observation period is more expensive and creates exception narratives.

What goes wrong during the observation period

The five common findings, in order of how often I have seen them.

One. The terminated user who stayed active. Somebody left the company; their primary system access was revoked; their access in three other systems was not. The control “access is revoked within twenty-four hours of termination” failed. The auditor finds it by sampling terminations. The fix is process-level: the joiner-mover-leaver workflow has to cover every system, not just the primary identity store. The remediation is to extend automated deprovisioning or to add the missing systems to the manual checklist; either way, the gap is identified by the time the audit happens. Some companies absorb a small number of these as exceptions; others miss too many and get qualified opinions.

Two. The change without a ticket. A small change, urgent fix, somebody pushed it to production without going through the normal change management workflow. The control “production code changes require ticket and approval” failed for that change. The auditor finds it by sampling production deployments and reconciling against tickets. The remediation is to add the missing ticket retrospectively (which works if you do it within hours and document why) or to acknowledge the exception and describe the compensating action (which works if it is a small number of exceptions). The fail mode is when there are many of these and the company is not aware until the auditor surfaces them.

Three. The logging gap. Logging was misconfigured for a period; logs that should have existed do not. The controls that depend on logs (monitoring, incident detection, audit trail) have an evidence gap. The auditor finds it because the requested logs are not available. The remediation is essentially impossible — you cannot reconstruct logs you did not capture — so the gap becomes either an exception or a qualified opinion depending on severity and duration. The mitigation is preventive: continuous monitoring of logging coverage so the gap is detected and fixed within hours, not months.

Four. The failed penetration test that did not get re-tested. A pen test surfaced findings; the findings were remediated; the re-test was not performed. The control “pen test findings are remediated and re-tested within agreed SLA” failed. The auditor finds it by sampling pen test reports and asking for re-test evidence. The remediation is to actually do the re-test; if it has been long enough that the original finding is stale, a fresh pen test with the original findings re-validated may be required.

Five. The backup that was not tested for restoration. Backups are running. Backups have never been tested. The control “backups are tested for restorability at least quarterly” failed. The auditor finds it by asking for restoration test records. The remediation is to run a restoration test, document it, and ideally surface a process for ongoing tests. The exception narrative is straightforward if the gap is recent and the fix is in place.

These findings are not a comprehensive list. They are the recurring ones. They all share a common shape: a control was defined; the control was operating most of the time; a specific failure occurred during the observation period; the failure was either not noticed in time to prevent its inclusion in the sample, or was noticed but not documented as an exception with a remediation narrative.

Exceptions versus qualified opinions

A SOC 2 Type 2 report can include exceptions. An exception is a documented instance in which a control did not operate as designed. The auditor describes the exception, the auditee provides a management response (what happened, what is being done about it), and the report still issues with an unqualified opinion.

Many SOC 2 Type 2 reports include some exceptions. The first-year reports of even mature companies typically have three to ten exceptions. Customers reading SOC 2 reports look at exceptions, evaluate whether they materially affect the customer’s reliance on the service, and usually accept the report unless the exceptions are severe.

A qualified opinion is different. The auditor issues a qualification when one or more controls failed materially or pervasively in ways that limit the auditor’s ability to conclude that the controls operated effectively. A qualified SOC 2 Type 2 is significantly harder to use commercially; many enterprise customers will not accept it.

The line between “many exceptions, unqualified” and “qualified” is judgement-based and varies by audit firm. The signal to watch: if the same control category (access management, change management, monitoring) has multiple exceptions across multiple control activities, the auditor is likely to consider pervasiveness and may qualify.

The way to avoid qualified opinions is to surface and remediate failed controls during the observation period, not at the end. The continuous monitoring platforms exist partly for this reason: surface the control failure within twenty-four hours, remediate, document the remediation, and the auditor sees a single exception with a clear remediation narrative rather than a pattern of recurring failure.

The audit firm relationship

Five years of SOC 2 reports with the same audit firm is the operating model that most companies eventually settle into. The first audit takes the longest because the auditor is learning your environment. Years two through five run faster because the engagement team knows the system description, the controls, the people. Year six often brings a new partner, a new manager, sometimes a new firm, and a temporary spike in effort.

The relationship matters in three specific ways.

Pre-audit conversations. A good audit firm has a quarterly check-in with the auditee — not formal audit work, just a touch-base on programme status, regulatory developments, anticipated changes. The check-ins surface issues early so the year-end field work does not produce surprises. A firm that goes radio-silent between audits and reappears six weeks before the report deadline is operating below the standard.

Interpretive flexibility. Trust Services Criteria are written at a level of abstraction that requires interpretation. A good audit firm will work with the auditee on reasonable interpretations of how a control maps to a criterion; a poor firm will impose rigid interpretations and refuse to engage with the operational context. The flexibility is valuable when the company is moving fast and controls evolve; rigidity makes the audit a friction-generating exercise rather than an evidence-gathering one.

Field work coordination. During field work the auditor requests evidence on a rolling basis. A good audit firm consolidates requests, gives the auditee time to respond, and works the engagement coherently. A poor firm sends requests piecemeal, requires same-day turnaround, and consumes the auditee’s bandwidth unnecessarily. Picking a firm whose engagement team operates well is more important than picking a brand.

The fee question is the one I get asked most. First-year SOC 2 Type 2 audit fees, in 2026, run from roughly $30,000-50,000 USD for a smaller engagement with a boutique firm, to $80,000-150,000 USD for a mid-tier firm with multiple criteria, to $200,000+ for Big Four engagements with broader scope. Renewal fees typically drop fifteen to twenty-five percent in years two and three because the engagement team’s startup cost is amortised. Indian companies engaging US-based firms pay USD; engaging Indian CPA firms (or Big Four India entities) for SOC 2 work runs roughly half the US rates with comparable audit quality, though the customer-side recognition of Indian audit firms varies.

The bridge letter — a small artefact that does heavy lifting

A SOC 2 Type 2 report covers an observation period that ends on a specific date. Customers reviewing the report after that date have a gap question: what happened between the report date and now?

The bridge letter answers it. The bridge letter is a management-issued attestation, sometimes counter-signed by the audit firm, that confirms the controls described in the SOC 2 report continue to operate as described, from the report date to a stated current date. It is a single page. It usually covers a quarter or two.

Customers ask for bridge letters constantly. The CISO or controller who has a template ready and issues bridge letters within a week of request runs a smoother sales cycle than the one who treats each request as a fresh project. The audit firm can provide a template; if they cannot, draft your own and use it consistently.

A bridge letter is not the same as continuous monitoring evidence; it does not substitute for the next year’s SOC 2 report. It is a stopgap that customers accept for two or three months past the report date, occasionally longer for sophisticated customers who understand what they are accepting.

The mid-observation check

About six months into a twelve-month observation period, the audit firm should perform an interim check. This is not always a contractual deliverable — sometimes it is built into the engagement, sometimes it is a separate fee. Either way, the interim check is valuable.

At the interim check, the auditor reviews a sample of controls operating to date, surfaces any concerns about evidence sufficiency, and identifies issues that need remediation before the end of the observation period. The interim check is the difference between discovering a problem in month six (when it can be fixed) and discovering it in month thirteen (when the period is over and the failure is locked into the report).

The companies that operate SOC 2 Type 2 well treat the interim check as the most important checkpoint of the year. The companies that operate it poorly skip it.

Customer evidence requests during the year

Enterprise customers will ask for SOC 2-related evidence during the observation period — not the report itself, which doesn’t exist yet, but interim documentation. Common requests: the system description, a list of in-scope controls, evidence that the observation period is running, the bridge letter from the previous year’s report.

These requests are workable as long as the materials are organised. They get hard when the requests are bespoke (“can you map your SOC 2 controls to our specific security questionnaire?”) or when the customer is asking for evidence that the company has not been producing in a sharable format.

The pattern that works: a customer evidence package, prepared once per quarter, that anticipates the common requests. System description (current). Controls list (current). Vendor SOC 2 reports for major subservice providers (current). Bridge letter (current). Penetration test executive summary (current; the full report is rarely required). Insurance certificate. This package can be sent in response to most customer requests without bespoke work each time.

The annual gap problem

A twelve-month SOC 2 Type 2 observation, plus four to six weeks of field work, plus two weeks of report drafting and review, means the new report drops fourteen to fifteen months after the previous observation period started. The next observation period begins the day after the previous one ends, so observation is continuous; but the report production lags. Customers receiving the report receive an artefact that covers a period ending three months ago.

This is structural. The fix is the bridge letter; it cannot be eliminated entirely.

What can be optimised is the report production cycle. Audit firms that complete field work in four weeks and produce a report within eight weeks of period end are well-managed; firms that take twelve weeks or more are introducing delay that affects the customer-facing currency of the report.

When a company is asking customers to wait for the report, the gap matters. When customers are asking the company to provide the report, the gap matters more. The pacing of the audit firm relationship affects how this lands.

Common myths

“SOC 2 means we’re secure.” No. SOC 2 means an auditor verified that controls described in the system description were operating effectively over the observation period. The controls describe what the company says it does. If the company described controls that are insufficient for the threat model, the SOC 2 report attests to insufficient controls operating effectively. Customers should read SOC 2 reports as evidence of programme operation, not as evidence of security adequacy.

“AICPA dictates the controls.” No. The AICPA defines the Trust Services Criteria. The company defines the controls that map to those criteria. The auditor evaluates whether the controls suitably address the criteria and operate effectively. The same criterion can be addressed by many different control designs.

“Type 2 means a year of perfection.” No. A SOC 2 Type 2 report can include exceptions and still issue with an unqualified opinion. Customers expect imperfection at the margins; what they do not expect is pervasive or material failure.

“You need Big Four.” No. The Big Four name matters in some procurement processes for large public companies; mid-tier and boutique firms produce audits of equivalent quality at substantially lower cost and with better engagement responsiveness. The decision should be driven by customer expectations, not by perceived signal value.

“Continuous monitoring tools replace controls.” No. The tools instrument the evidence trail for controls that already operate. The underlying controls — joiner-mover-leaver, change management, access reviews, encryption configuration, logging configuration — still need to be designed and operated. The tool surfaces evidence; the tool does not create the control.

“ISO 27001 and SOC 2 are interchangeable.” Partially. ISO 27001 is a management-system certification with an Annex A controls baseline; SOC 2 is an attestation against Trust Services Criteria with a company-defined control mapping. ISO 27001 is more structural and process-heavy; SOC 2 is more evidence-based. Many companies pursue both because customer demand is bifurcated by geography (European customers often ask for ISO 27001; US customers often ask for SOC 2). The work overlaps materially — perhaps 70% — but neither substitutes for the other.

What to do this quarter — if you are starting

Month one. Decide scope and Trust Services Criteria. Get auditor proposals. Pick a firm. Decide on continuous monitoring tooling.

Month two. Draft the system description. Draft the controls list. Set up evidence collection infrastructure. Run a readiness gap analysis.

Month three. Remediate readiness gaps. Confirm observation period start date. Finalise engagement scope with the audit firm.

Months four through fifteen. Operate the controls. Surface failures within twenty-four hours. Maintain evidence continuously. Interim check at month nine. Field work in months fourteen and fifteen.

Month sixteen. Report issues. Send to customers. Begin next year’s bridge letter cadence.

What this guide does not cover

Three areas deliberately left out:

1. The detailed mapping of Trust Services Criteria to controls. Each company’s environment maps differently. The audit firm will work through the mapping with you during the engagement. A pre-built mapping is available from continuous monitoring vendors and from the AICPA itself; treat these as starting points, not as final.

2. The interaction with HIPAA, HITRUST, and SOC 1. SOC 2 sits adjacent to several other reporting frameworks. SOC 1 covers controls relevant to financial reporting (ITGC territory); HIPAA and HITRUST cover US healthcare. The integration of reporting across these frameworks is a separate engineering and evidence-design problem. Worth its own treatment.

3. The privacy criteria deep dive. SOC 2’s Privacy criteria are the least-used category and have specific complexities — privacy notice evaluation, consent mechanisms, monitoring against the privacy notice. If you are adding Privacy to your SOC 2 scope, that decision deserves dedicated preparation. The general SOC 2 playbook applies but the evidence requirements are materially different.

This is a practitioner reference, not audit advice. It reflects how SOC 2 Type 2 engagements typically work as of May 2026 under the AICPA’s 2017 Trust Services Criteria framework (with the 2022 updates), with reference to SSAE 18. Compliance teams should validate specific engagement scope and requirements against their selected audit firm’s methodology and applicable AICPA professional standards.

ControlForge maps SOC 2 Trust Services Criteria across ISO 27001, NIST CSF, RBI ITGRCA, SEBI CSCRF, and other security frameworks through cross-framework synthesis clusters covering access, change, monitoring, incident response, and vendor risk domains.