What SOC 2 is, precisely
SOC 2 is an attestation report produced by an accredited auditor about whether an organisation's controls meet the Trust Services Criteria, and — in a Type II report — whether those controls operated effectively over a period of time.
Two consequences follow, and nearly all engineering confusion comes from missing them.
It is not a checklist of required technologies. The criteria describe outcomes, not implementations. There is no clause requiring a particular vendor, tool or configuration. You describe how you achieve an outcome, and the auditor tests whether you actually do it.
It audits consistency, not strength. A control you described and follow every time passes. A stronger control you follow most of the time fails. This is counter-intuitive to engineers, who reasonably assume more security is better — but the report is an opinion on whether your stated controls operated as stated.
The practical implication is that over-promising in your control descriptions is the most common self-inflicted wound. Describe what you genuinely do.
Type I versus Type II
Type I assesses whether controls are suitably designed at a point in time. Type II assesses whether they operated effectively across an observation window, commonly three to twelve months.
Type I is achievable quickly and is worth substantially less to a buyer, because it says a control existed on one day. Most enterprise procurement asks for Type II. If a sales cycle is driving the work, confirm which one the customer actually requires before scoping — the difference is months.
The window matters for a reason engineers frequently discover late: evidence must exist for the whole period. You cannot retroactively produce access reviews for a quarter that has already passed. Starting the clock early, even with imperfect controls, is often better than delaying until everything is ideal.
The five criteria, and which apply
Security is mandatory. Availability, Processing Integrity, Confidentiality and Privacy are optional and included only if you scope them in.
Scope deliberately. Each additional criterion adds controls, evidence and audit effort, and buyers rarely ask for all five. Security alone satisfies most procurement requirements; adding Availability is common for infrastructure providers. Adding Privacy is a significant undertaking and should be a considered decision rather than a default.
What engineering is actually asked to produce
The controls that consume engineering time cluster in a few areas.
Access management. Who has access to what, granted through an approved process, reviewed periodically, and removed promptly when someone leaves. Offboarding evidence is where findings concentrate, because it is the step that happens when everyone is busy.
Change management. Changes reviewed and approved before reaching production. This is usually satisfied by an ordinary pull request workflow with required review and protected branches — provided the workflow is genuinely enforced rather than conventionally followed. An emergency path that bypasses review is fine if it is documented and its use is reviewed afterwards.
Logging and monitoring. Security-relevant events recorded, retained, and actually reviewed. The last part is where evidence is thin: alerts firing into a channel nobody reads is not monitoring, and auditors ask what happened to specific alerts.
Vulnerability management. Scanning, plus remediation within timeframes you defined. Note the second half — you set the timeframes, and you are audited against your own commitment. Setting aggressive ones you cannot meet creates findings that a realistic policy would not.
Backups and recovery. Backups taken and restores tested, with evidence of the test.
Vendor management. A register of subprocessors, their reports collected and reviewed. Tedious rather than difficult, and easier maintained continuously than reconstructed.
Risk assessment. A documented, periodic exercise. Often treated as paperwork; auditors ask to see it and ask what changed as a result.
Where engineering time really goes
Not the controls — the evidence.
Almost every control requires demonstrating it operated throughout the window, and that demonstration is far cheaper if the system produces it as a by-product than if a person assembles it later. Access reviews exported from the identity provider, change approvals visible in the repository, alert dispositions recorded in the ticket system: each of those is minutes if instrumented and days if reconstructed.
The teams that find SOC 2 painful are usually the ones producing evidence manually at the end of the window. The teams that find it routine made evidence a side effect of how work already happens.
What it does and does not tell a buyer
A clean Type II report says an auditor tested the controls the company described and found they operated. That is genuinely informative: it means the company can describe its practices accurately and follow them consistently, which many cannot.
It does not mean the company is secure, that its product is well engineered, or that it has not had incidents. A company can hold a clean report and suffer a breach — the report is about control operation, not about outcomes.
Read the scope section and any noted exceptions rather than the cover page. The scope tells you which systems were assessed, and it is frequently narrower than the buyer assumes.