SOC 2 from the engineer's seat

Sooner or later a B2B deal stalls on one sentence: "send us the SOC 2 report." It doesn't much matter what a vendor sells — if an enterprise is going to pipe its data through that software, its vendor-risk team wants that report before it signs. The bigger the logo, the earlier the sentence arrives.

The instinct when it lands is to treat it as a security problem — go harden things. That's the wrong frame, and the expensive one. SOC 2 isn't a bar cleared by being secure; it's an evidence machine run continuously, and most of the evidence turns out to be a byproduct of doing engineering the way it should already be done. This is the engineer's read on what the gate actually asks engineering to produce.

This gate came the long way — a decade building an enterprise multi-tenant SaaS codebase. We weren't SOC 2 compliant, and it cost us: real opportunities stalled because we couldn't drop the report on the table when a bigger customer's vendor-risk team asked for it. The engineering underneath was solid; the attestation-shaped hole was the problem. That's the vantage here — not the framework in the abstract, but what its absence actually costs the people writing the code. And nothing about it is industry-specific — it's the same examination whether the product is payroll software, a scheduling API, or a data pipeline. Wherever customer data lands in the system, the report follows.

First correction to the SaaS instinct: nobody "passes" SOC 2. There's no cert on the wall. A licensed CPA firm examines the controls and writes an opinion — an attestation — that's shared with the customer under NDA. The framework comes from the AICPA; the criteria are the Trust Service Criteria, and the team maps its own controls to them. There is no fixed checklist, which is exactly why engineers find it slippery at first.

The split that matters to a builder is Type I versus Type II.

Type I says the controls are designed right on one date. Fast — a couple of months — and useful to unblock a nervous prospect. Type II says they operated effectively across an observation window, usually three to twelve months. That's the report enterprises actually respect, and the word doing the work is operated. Not "exists." Ran. Continuously. The whole window.

That distinction is the entire game, and it's the thing that bites engineers — more on that below.

The second relief. SOC 2 is built on five Trust Service Criteria, and only one is mandatory. The rest are opt-in based on what the product actually promises customers. Scope creep here is self-inflicted — every added criterion multiplies the evidence that has to be produced.

The pragmatic default for a first report: Security only. Add Availability if the product sells an SLA, Confidentiality if contracts demand it, and Processing Integrity if the product's whole value is computing something correctly on the customer's behalf. Each addition is a deliberate choice tied to a promise actually made — not a box ticked to look thorough.

Every added criterion is another stream of evidence to produce on every sampled date for the whole window. "To be safe" is how a three-month project becomes a nine-month one.

The Security criterion breaks into nine Common Criteria series (CC1–CC9). Most are governance — org charts, risk assessments, board oversight, vendor reviews — and they're not engineering's. Three of them are, and auditors sample them the hardest.

Read that figure again and notice what it isn't asking for. It isn't asking for a new firewall or a new architecture. CC6 is identity a team should already have — SSO, MFA with no exceptions, least privilege, access tied to the HR system so a leaver loses everything the same day. CC7 is detection a team should already run — logs shipped somewhere tamper-resistant, alerts, dependency scanning, an incident runbook. CC8 is the pipeline — every production change behind a reviewed pull request, tests gating the deploy, and the author not being the sole approver.

For a team that already works like that — feature branch, review, tested merge, promote — the substance of the three hardest series is already there. What's missing isn't controls. It's the paper trail that proves the controls ran.

Here's the gotcha the whole post has been walking toward. For Type II, the auditor samples dates across the observation window and asks for evidence the control operated on each one. Every access review that was due. Every offboarding, with the timestamp showing access died the day the person left. Every production change, with its review and approval attached.

And it cannot be backfilled. A control that lapsed for one month inside the window — the quarter the access review got skipped, the two weeks MFA was off for a contractor, the hotfix that went straight to prod without a PR — becomes a noted exception in the report. There's no reconstructing it after the fact; the timestamps give it away.

SOC 2 doesn't test whether the system is secure today. It tests whether it was secure on eleven random days over the last nine months — and whether that can be proved without touching a screenshot after the fact.

This is why the frame is "evidence machine," not "security project." Being secure is a state. Passing Type II is a habit with receipts. The engineering task isn't to harden the system once; it's to make the system emit proof of its own good behavior, continuously, so that when the auditor points at March 14th, the answer is a query, not a scramble.

There's a category of tool — Vanta, Drata, Secureframe, Sprinto and friends — whose entire job is to be the continuous-evidence machine so no one has to hand-roll it. They connect read-only to the cloud, the identity provider, the HR system, the code host and the laptops, then pull evidence automatically and turn red the moment a control drifts. Most bundle policy templates and a portal the auditor logs into directly.

For a small team this is the difference between a subscription and a second job. The rule of thumb on the split:

• Automate the high-frequency, machine-observable controls: cloud and IAM config, MFA and access state, on/offboarding, change-management history, vuln scans, endpoint compliance. This is the stuff that lapses silently and is miserable to reconstruct.
• Keep manual the low-frequency human artifacts: policy approvals, the annual risk assessment, procuring the pen test, actually running a backup-restore test, the management review. A platform can't do these for a team; it can only remind them.

Two non-obvious rules. First: start the integrations before the observation window opens — evidence only counts from when collection began, so wiring the tool up on day one of the window is worth months. Second: this is a hosted SaaS with read-only reach into production infrastructure, so vet it like any subprocessor before pointing it at production. (And, the standard caveat on this blog: every one of these is a paid platform. Worth it when a deal is waiting on the report — not a reflex purchase before one is.)

For a service that will face this gate — and any product selling to enterprise eventually does — the move is to treat the evidence as a build target from the first commit, not a scramble the quarter before the audit. Four things, all controls-as-code, all emitting their own proof.

01

Access as code · CC6

Identity and permissions defined in a reviewed repo, not clicked into a console. The grant history is the access-review evidence, and deprovisioning is a merged PR with a timestamp — not a memory of someone doing it.

02

A change trail that can't be routed around · CC8

Protected branches, required review, tests gating the deploy, and deploys stamped back to the merged PR. If there's no supported path to prod except through review, "every change was reviewed" stops being a promise and becomes a fact the pipeline enforces.

03

An immutable audit log on the sensitive path · PI / CC7

Append-only, tamper-evident logging on the operations that matter — whatever computes a result the customer relies on, or touches data they'd care about. It's the SOC 2 evidence for those actions, and in a regulated industry it's the record the regulator expects too. Build it once; if a second framework ever shows up, it's already covered.

04

A backup actually restored · CC7 / A

Backups nobody has restored are a rumor. A scheduled restore drill that writes its own log entry is the one piece of evidence teams most reliably fake and most reliably get caught faking. Automate the drill; keep the receipt.

None of that is a security purchase. It's a single instinct applied four ways — make the system produce the artifact as a byproduct of running correctly, so the audit becomes a report to generate rather than a fire to fight.

One honest caveat: this is the view from the side of the company that didn't clear the gate — a decade in enterprise multi-tenant SaaS where the missing report cost deals, and where the engineering discipline was largely there but never got turned into an attestation anyone could hand a customer. What it isn't is the view from owning a Type II end-to-end in the compliance chair: running the auditor relationship, arguing a specific exception, carrying the observation window as the person on the hook. For anyone in that seat, corrections welcome — what's heavier than this makes it sound, what's lighter, where the "it's just documenting what's already done" framing breaks down against a real audit.

Email or X. Building in the open is partly a learning project; the outside input is the point.

— Neil