Fast facts
SOC 2 is not a certification and there is no pass mark. It is an attestation report in which a licensed CPA firm expresses an opinion on whether your controls are suitably designed — and, in a Type II report, whether they operated effectively over a defined period.
The report covers one or more of five Trust Services Criteria. Security, the common criteria, is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional and should be added only where a customer commitment or contract genuinely requires them, since each expands scope and cost.
The distinction that matters commercially is Type I versus Type II. Type I is a point-in-time opinion on design; Type II covers operating effectiveness over an observation period of typically three to twelve months. Enterprise buyers almost always want Type II, and many will accept a Type I only as an interim while the observation window runs.
Who it applies to
The commercial and regulatory argument, rather than a restatement of the text. If none of these apply to you, the honest answer is that this framework is not your priority.
For SaaS and services businesses selling into the United States, a SOC 2 report is requested so consistently that its absence functions as a disqualification rather than a negotiating point.
A Type I opinion covers design at a point in time. Type II covers whether controls actually operated across a period, which is why enterprise risk teams accept Type I only as an interim.
Control overlap is typically 70–80%. Organisations holding ISO 27001 find SOC 2 costs 40–60% less than a standalone effort, provided evidence is indexed by control rather than by framework.
Scope is the decision that sets the cost, and it is usually made in week one when the team knows least. Both columns matter equally.
In scope
Out of scope
How the boundary is decided: Include Security only unless a contract commits you to more. Every additional criterion expands scope, cost and the surface on which a deficiency can be reported. Availability is the most commonly justified addition; Privacy is usually better served by ISO 27701.
Stated as the duty rather than the clause number, because clause numbers do not tell an engineering team what to build.
Demonstrated integrity and ethical values, board oversight, organisational structure, commitment to competence and accountability.
Internally and externally communicated objectives, responsibilities and security commitments, supported by quality information.
Specified objectives, identified and analysed risks including fraud risk, and assessment of significant change.
Ongoing and separate evaluations of control operation, with deficiencies communicated to those responsible for corrective action.
Logical and physical access, system operations, change management and risk mitigation controls that address the identified risks.
Where in scope: availability commitments and recovery, confidentiality handling and disposal, processing integrity of system inputs and outputs, and privacy across the information lifecycle.
The areas your teams will actually be building in, with control counts where the framework defines them.
Mandatory in every SOC 2. Protection against unauthorised access, disclosure and damage across the system.
System availability against commitments — capacity, monitoring, incident handling and disaster recovery.
Protection of information designated confidential, from identification through to disposal.
System processing that is complete, valid, accurate, timely and authorised.
Collection, use, retention, disclosure and disposal of personal information in line with your privacy notice.
Phases overlap deliberately. Design begins before assessment closes, so the programme does not stall waiting for a document to be signed off.
Weeks 1–3
Choose the Trust Services Criteria genuinely required by customer commitments, then define system boundaries and draft the system description.
Weeks 3–6
Assess against the selected criteria, identify design gaps and close them before the auditor engages.
Weeks 5–9
Wire evidence collection to version control, CI, identity, cloud and ticketing so the observation period generates its own artefacts.
3–12 months
Operate the controls across the defined window. Exceptions are surfaced and remediated as they occur rather than discovered at fieldwork.
4–6 weeks
Auditor selection, PBC list management and fieldwork support, through to issued report and bridge letter planning.
Named artefacts, listed in the statement of work. If something is not on this list, we will tell you before you sign rather than after.
Type I typically 10–16 weeks from start to report. Type II adds the observation window — a three-month window is the usual starting point, extending to twelve months for mature programmes.
Readiness
Weeks 1–9
Criteria selected, system described, gaps closed and evidence instrumented. This must finish before the window opens.
Observation window
3–12 months
Three months is the usual starting point. The controls must actually operate throughout.
Fieldwork
3–4 weeks
Auditor testing. Engineering involvement stays low where evidence was instrumented.
Report issuance
1–2 weeks
Report delivered, followed by bridge letters covering the gap until the next period.
The sequence we follow, and the parts where first-time implementations most often lose time.
Select the Trust Services Criteria genuinely required by your customer commitments, and no more.
Define system boundaries and prepare the system description that anchors the report.
Run a readiness assessment against the criteria and close design gaps before the auditor engages.
Instrument continuous evidence collection so the observation period generates its own artefacts.
Manage auditor selection, the PBC list and fieldwork so your engineers are not the bottleneck.
Maintain the control environment between reports so each subsequent Type II is routine.
Certification without the eighteen-month scramble.
Readiness, implementation and audit support for ISO 27001, ISO 27701, ISO 42001, SOC 2 and PCI DSS — run as a project with dates, owners and a definition of done.
Explore capabilityYour compliance programme, run continuously — not rediscovered annually.
We operate your control environment day to day: evidence collection, control testing, audit coordination, questionnaire response and reporting, across every framework you hold.
Explore capabilitySecure the control plane, not just the workloads.
Landing-zone design, identity hardening, posture management and Kubernetes security across AWS, Azure and Google Cloud — with guardrails engineers do not route around.
Explore capabilityThe choice is decided by who is buying, not by which framework is better. A practical decision guide, plus why sequencing ISO first makes the SOC 2 cheaper and the reverse is not true.
Most SOC 2 reports are filed unread, which makes them a compliance ritual rather than assurance. Five checks any procurement or risk reviewer can run, and what each one catches.
Compliance programmes fail in engineering organisations when they add steps. Make the existing pull-request workflow the control instead, and the evidence collects itself.
Sequencing matters. Running these together off one control library costs meaningfully less than running them apart.
Including the questions where the honest answer is less convenient than the marketing one.
Ask a practitioner directly. First responses come from the person who would run your engagement, within one business day.
Ask a question
