SOC 2 for Engineers: Controls, Evidence & Type II

SOC 2 & Security Compliance

SOC 2 is not a law. It's an attestation report produced by an independent auditor, and you get one because enterprise customers won't sign without it. That distinction shapes everything about how to approach it: there's no regulator, no fine, and no fixed checklist — there's an auditor forming an opinion about whether the controls you described were designed appropriately and, for Type II, whether they actually operated over a period of months.

The engineering reality is that SOC 2 rarely asks you to do anything unreasonable. Access reviews, change management, encryption, logging, backups, vulnerability management, and incident response are things a competent team does anyway. What it demands is evidence that they happened — and that's where unprepared teams lose weeks screenshotting dashboards and reconstructing who approved what.

The single highest-leverage insight: automate evidence collection at the same time you implement the control. A control that produces its own audit trail costs nothing at audit time. One that doesn't means a person manually assembling proof for a twelve-month period.

TL;DR

SOC 2 is an attestation, not a certification or a law. Customers demand it; no regulator enforces it.
Five trust services criteria: Security (always), Availability, Confidentiality, Processing Integrity, Privacy.
Type I = controls designed correctly at a point in time. Type II = they operated over 3–12 months.
Type II is what customers actually want; Type I is a stepping stone.
You define your own controls against the criteria — then you must follow them, exactly.
Evidence is the work. Automate its collection, or spend weeks assembling it manually.
The controls auditors sample most: access reviews, change management, and onboarding/offboarding.
ISO 27001 overlaps heavily — roughly 70–80% of the same underlying controls.

Core Concepts

The trust services criteria

Most SaaS companies scope Security + Availability + Confidentiality. Adding criteria expands the audit meaningfully, so scope deliberately: including Privacy when your customer contracts don't require it adds cost for no commercial return.

The Security criterion itself decomposes into nine Common Criteria series (CC1 through CC9) covering control environment, communication, risk assessment, monitoring, control activities, logical access, system operations, change management, and risk mitigation.

Type I vs. Type II

The important consequence of Type II: a control that failed once during the observation period appears as an exception in the report. Customers read those. A control you can't consistently execute is worse than one you didn't claim — so scope your control set to what you'll actually do every time.

Defining your controls

This surprises people: SOC 2 doesn't hand you a checklist. You write control statements against the criteria, and the auditor tests what you wrote.

Two failure modes here. Over-claiming — writing an aspirational control you don't consistently execute — produces exceptions. Under-claiming produces a report customers find thin. Write what you actually do, then improve it.

The control set that matters

The three most commonly failed: access reviews (nobody does them consistently), offboarding (an access token left live for three weeks after someone left), and restoration testing (backups taken religiously, never restored).

Evidence

Evidence is the product of the audit, and gathering it manually is where the cost lives.

The pattern: every control emits its own evidence automatically, into an append-only store with timestamps. At audit time you export rather than reconstruct.

Compliance automation platforms (Vanta, Drata, Secureframe, Sprinto) do exactly this — integrate with your cloud provider, identity provider, and code host, monitor control status continuously, and package the evidence. They're expensive and generally worth it for a first audit, because they encode which evidence auditors actually want.

The timeline

The observation period is where discipline is tested. A quarterly access review skipped in month 6 is an exception in the report, visible to every customer who reads it, and not fixable retroactively.

SOC 2 vs. ISO 27001

They overlap heavily — commonly cited at 70–80% of the same underlying controls. Companies selling globally often pursue both, and the second is substantially cheaper because the control work is done. HIPAA, PCI DSS, and FedRAMP are the other frameworks that recur, each adding domain-specific requirements on a similar foundation.

Best Practices

Automate evidence collection when you implement the control

Not at audit time. A control that writes its own timestamped evidence to an immutable store costs nothing later; one that doesn't means someone reconstructing twelve months of history from Slack threads.

Write controls you will actually execute

An aspirational control statement becomes an exception in the report. It's better to claim a quarterly access review you genuinely complete than a monthly one you'll skip twice. Tighten the control after you've demonstrated you can hold it.

Enforce change management in the tooling

Branch protection requiring review and passing CI is a control that cannot be bypassed and produces perfect evidence automatically. A policy saying "all changes are reviewed" without technical enforcement produces exceptions the moment someone pushes to main at 2 a.m.

Test restores, not just backups

The most commonly failed availability control. Schedule a quarterly restore into an isolated environment, verify integrity, and record the result. Backups nobody has restored are a hypothesis. See Database Backups.

Make offboarding a single automated flow

Deprovisioning triggered from the HR system, revoking SSO, cloud access, database roles, API keys, and third-party tools in one action, with a log. Manual offboarding checklists get partially completed, and the gap surfaces as a sampled exception months later.

Keep the scope tight

Add trust services criteria only where a customer contract requires them. Each one expands testing, evidence, and cost. Security plus Availability plus Confidentiality covers the overwhelming majority of SaaS buyer requirements.

Assign an owner per control

A named person accountable for each control operating and its evidence existing. Controls owned by "the team" are owned by nobody, and that's what produces the month-6 lapse.

Treat exceptions honestly

If a control lapsed, document what happened, the impact, and the remediation. Auditors respond far better to a documented exception with a corrective action than to one they discover during sampling — and customers reading the report do too.

Common Mistakes

Starting evidence collection at audit time

Over-claiming in control statements

Change management by policy alone

Slow or partial offboarding

Untested backups

Treating it as a one-time project

FAQ

Do we need SOC 2?

Only if customers ask, which for B2B SaaS typically starts the first time you sell to a company with a procurement function or a security review. It's a sales enabler rather than a legal requirement, and pursuing it before any customer has requested it is usually premature. When it does become necessary, it's usually blocking a specific deal on a specific timeline, which is why Type I exists.

How much does it cost?

Audit fees typically run $20k–60k for a Type II depending on scope and firm, plus a compliance platform at $10k–30k a year if you use one, plus internal engineering time — commonly the largest cost, at 2–4 months of meaningful effort for a first audit. Subsequent years are substantially cheaper if the controls are automated and stayed operational.

Type I or Type II?

Customers want Type II; Type I proves only that controls were designed appropriately on one day. Type I is worth doing when a deal is blocked and you need something now, as a bridge to a Type II covering the following period. Some companies skip it entirely and go straight to a 3-month Type II observation window.

How long does the observation period need to be?

Three months is the practical minimum and covers the shortest defensible window; six to twelve months is more common and more credible. Customers occasionally specify a minimum. Longer periods give the auditor more to sample, which is fine if your controls actually operate consistently and painful if they don't.

SOC 2 or ISO 27001?

Follow your customers. North American buyers typically ask for SOC 2; European and Asian buyers more often ask for ISO 27001. The underlying control work overlaps by roughly 70–80%, so the second certification is considerably cheaper than the first. Companies selling globally frequently end up with both.

Does SOC 2 mean we're secure?

No, and the distinction matters. It means an auditor verified that the controls you described operated as described. You choose those controls, so a narrow scope with weak controls can produce a clean report. It's meaningful evidence of process maturity and it is not a security assessment — penetration testing, threat modeling, and a genuine security program are separate work that SOC 2 does not replace.