Ask an engineering lead what SOC 2 involves and the honest answer is a backlog, not a binder. The report is issued under the AICPA’s SSAE 18 attestation standard — an opinion on controls, not a certificate to frame on a wall — and earning it means enforcing MFA, centralizing logs, gating deploys behind pull request review, running vulnerability scans on a schedule, and reviewing who has access to what, then proving it happened rather than just that it was written down. The roadmap below sequences that work into six phases, from scoping the criteria through the audit itself.
SOC 2 as an Engineering Project, Not a Paperwork Exercise
It helps to be precise about what SOC 2 actually is. It is a System and Organization Controls report produced under the AICPA’s SSAE 18 attestation standard — an independent opinion that a company’s controls are designed appropriately and, for a Type II, that they operated effectively over a period. It is not a certification in the way ISO 27001 is; there is no certificate, no logo, no pass or fail badge, just a lengthy report an auditor signs and prospective customers read.
That distinction changes what “doing SOC 2” means day to day. A certification exercise can sometimes be satisfied by a document review; an attestation cannot, because the auditor tests evidence that controls existed and, for Type II, ran continuously. SOC 2 has real engineering line items: access management, encryption, log retention, change management in the deploy pipeline, vulnerability scanning, backup testing, and vendor due diligence. Treat it as a paperwork exercise and the gap shows up where it is most expensive to find: mid-audit, when the evidence is not there.
| Phase | What Happens | Owner |
|---|---|---|
| Phase 0 — Scope | Pick criteria beyond mandatory Security; decide Type I or II | Leadership + Compliance |
| Phase 1 — Gap Assessment | Compare current state to criteria; build a backlog | Compliance + Engineering |
| Phase 2 — Remediation | Build and operate controls: access, MFA, encryption, logging, vendors | Engineering |
| Phase 3 — Policies and Evidence | Document policies; capture evidence continuously | Compliance + Engineering |
| Phase 4 — Readiness Assessment | Independent dry run before the auditor arrives | Compliance / Assessor |
| Phase 5 — Audit and Observation | Tests design (Type I) or effectiveness over 3–12 months (Type II) | Auditor + Engineering |
Phase 0 — Scope the Criteria and Choose the Report Type
Before any control work starts, two decisions set the shape of everything that follows. The first is which Trust Service Criteria apply. Security — the Common Criteria — is mandatory; a company cannot opt out of it. Availability, Confidentiality, Processing Integrity, and Privacy are optional, and the right call depends on what the business actually promises customers. Scoping too broadly adds unnecessary control work; scoping too narrowly means the report does not answer the questions the biggest prospects are asking. A deeper walkthrough lives in the Trust Service Criteria breakdown.
The second decision is Type I versus Type II. Type I is a point-in-time opinion that controls are suitably designed; Type II tests whether those same controls operated effectively across an observation window, typically three to twelve months. The fuller comparison covers the tradeoffs, but the practical implication is simple: Type II is almost always the report the market wants, so the sequencing that follows should treat Type II as the destination even if a Type I is used as an interim milestone.
Phase 1 — Gap Assessment
With scope fixed, Phase 1 compares the company’s current state against the chosen criteria, control by control. This is not a survey of intentions — it is a factual check: is MFA actually enforced on every system touching customer data, or only some? Is there a documented process for revoking access when someone leaves, or does it happen informally? Are logs centralized and retained long enough to matter, or scattered with a two-week window? The output is a gap list, each item mapped to a control, prioritized by risk, and assigned an owner.
The gap assessment is also where a realistic timeline takes shape. Some gaps close in days, like enabling an existing MFA feature; others take much longer, like standing up centralized logging where none existed. There is no fixed number of weeks that fits every company — a Type I becomes realistic once the highest-priority gaps are closed and the remaining controls are operating, and a Type II adds the observation window on top of that.
Phase 2 — Build and Operate the Controls
Phase 2 is where most of the engineering hours go, because an auditor is not grading intentions. A representative slice of the work:
- Access reviews — a recurring review of who has access to what, logged as evidence each time.
- MFA and SSO — enforced across internal systems, centralized through an identity provider so offboarding revokes access everywhere at once.
- Encryption — data encrypted at rest and in transit, with keys managed deliberately, not left at provider defaults.
- Centralized logging — logs aggregated somewhere durable, with alerting tuned to catch anomalies rather than just accumulate.
- Change management — production changes gated behind pull requests, review, and automated CI tests, leaving a traceable approval trail.
- Vulnerability management — regular scanning of code and dependencies, with patching against a defined timeline.
- Backups — not just scheduled but periodically restored, to prove they would work in an incident.
- Vendor reviews — a documented process for assessing vendor security posture before onboarding, not after a customer asks.
Can someone point to evidence it ran last month, not just that it is configured correctly today? If not, it is not a control yet — it is a setting.
None of these are exotic; most teams already have pieces of several. What SOC 2 adds is consistency and a paper trail — the control has to run every time, on a defined cadence, and leave evidence behind. More on how each maps to the criteria is in SOC 2 controls explained.
Phase 3 — Policies and the Evidence Pipeline
Controls need policies behind them — written, approved, and communicated to the people expected to follow them. A password policy no one has read is not a control; it is a document. Phase 3 is where the company writes down what Phase 2 built: access control, change management, incident response, vendor management, and the rest of the standard set, each describing what the team already does rather than an aspirational version of it.
Policies describing an aspirational future rather than current practice are the most common reason gap assessments and audits come back with findings. Write down what the team actually does, then fix what needs fixing — not the other way around.
The other half of Phase 3 is starting the evidence pipeline early, well before the audit period begins. Every access review, deploy approval, and vulnerability scan needs to leave a record, because a Type II auditor is not asking whether a control exists today; they want proof it ran every month of the observation window. Teams that wait until the audit is scheduled lose months they cannot get back. Automating that collection turns evidence gathering into a byproduct of normal operations, the approach covered in automating SOC 2 compliance.
Phase 4 — Readiness Assessment: the Dry Run
Before the real auditor arrives, Phase 4 runs an internal or third-party readiness assessment that walks the criteria the same way the actual audit will. Its purpose is to surface findings while they are still cheap to fix — a missing evidence artifact, a control that quietly stopped running, a policy that drifted from what the team actually does. Every gap caught here is a gap the real auditor never sees.
A readiness assessment also reveals whether the observation window has run long enough and cleanly enough to support a Type II. If controls only started operating consistently a few weeks ago, no amount of documentation fixes that — the honest move is to extend the window rather than hand an auditor a control history with holes in it.
Phase 5 — the Audit and the Observation Window
The audit itself is an independent CPA firm examining the evidence against the chosen criteria. For a Type I, that means confirming the controls are suitably designed as of a specific date. For a Type II, it means testing whether those controls operated effectively across the observation window — typically three to twelve months — by sampling evidence from throughout the period, not just the end of it.
The compromise of SolarWinds’ Orion software, disclosed in 2020, illustrates why this distinction is not academic. Attackers slipped malicious code into a routine software update, and the intrusion went undetected for months while, on paper, monitoring controls existed. A point-in-time review taken on almost any single day in that window would likely have looked fine, because the failure was in whether controls kept working continuously, not in how they were designed. That is exactly the gap a Type II observation window is built to close.
This is why the earlier phases matter so much: an audit does not create evidence, it only examines what already exists. A control switched on the week before the audit period started will not have a period’s worth of history behind it — the entire reason Phase 2 and Phase 3 need to start running long before Phase 5 is scheduled.
Final Thought
Six phases sound sequential, but in practice they overlap — the evidence pipeline in Phase 3 should be running while Phase 2 controls are still being finished, and Phase 4’s readiness check often sends a team briefly back to Phase 2. What stays fixed across every phase is the same test: not whether a control exists, but whether someone can produce evidence it ran, on schedule, for as long as the report needs it to have run.
Teams that treat SOC 2 as a paperwork exercise discover the gap at the worst possible time, mid-audit, with no time left to close it. Teams that treat it as what it actually is — an engineering project with a compliance layer on top — arrive at the audit with nothing left to do but hand over evidence that was already being collected. The roadmap does not get shorter by skipping steps; it gets shorter by starting the evidence pipeline earlier than feels necessary.
Frequently Asked Questions
No. SOC 2 is an attestation report under the AICPA’s SSAE 18 standard, an auditor’s opinion on a company’s controls, not a certificate. There is no pass or fail badge, just a report describing the controls in place and, for a Type II, whether they operated effectively over a period. ISO 27001, by contrast, is a certification.
It varies and cannot be reduced to a fixed number of weeks. A Type I typically takes a few months once the priority gaps from Phase 1 close and the core controls are operating. A Type II adds the observation window on top, usually three to twelve months of controls running and generating evidence before the audit can test them.
The Phase 1 gap assessment happens at the start and compares current practice against the chosen criteria to build a remediation backlog. The Phase 4 readiness assessment happens near the end and walks the same criteria the real auditor will, to catch anything that slipped before the audit does.
Security, also called the Common Criteria, is mandatory for every SOC 2 report. Availability, Confidentiality, Processing Integrity, and Privacy are optional, added in Phase 0 based on what the business promises its customers, not by default.
Because a SOC 2 audit, especially a Type II, tests evidence that controls operated, not just that they were documented. A policy describes intent; the audit looks for proof, such as access tickets, deploy approvals, and backup restore tests, collected over the observation window. Skipping straight to policy writing leaves nothing to sample.