What SOC 2 Type II actually asks of an engineering team

The first thing worth saying is that SOC 2 is not a security standard. It is an auditing framework, and it tests whether you consistently do the things you have said you do. That distinction explains almost everything engineers find strange about the process.

A Type I report says your controls were designed sensibly on a particular day. A Type II report says they operated as described across a window, usually three to twelve months. The second one is the one enterprise buyers ask for, and it is the reason preparation cannot be compressed into the fortnight before the audit.

What auditors are actually testing

An auditor samples. They will take a handful of items from your window and ask you to prove that the control operated for each one. In practice that means the following questions, repeated across categories.

• Who approved this change, and can you show that the approval happened before it reached production?
• Who has access to this system, when were they granted it, and who reviewed the list?
• When this person left, how long did it take for their access to be removed, and how do you know?
• This alert fired. Who saw it, what did they do, and where is that recorded?
• This vendor holds your customer data. What review did you do before signing, and when did you last repeat it?

Notice how little of that is security engineering. It is mostly evidence that a process ran, which is why the burden falls on your tooling rather than your defences.

The evidence that hurts to produce late

Some evidence can be reconstructed after the fact. Some cannot, and if you are missing it the only remedy is to restart the observation window. This is the list worth caring about.

1. 1Change approvals. If your pull requests were merged without a recorded reviewer, there is no way to manufacture that later. Turn on branch protection now, not in month five.
2. 2Access reviews. A quarterly review that never happened cannot be backdated. Run the first one this month, keep the export, and put a recurring calendar entry against a named owner.
3. 3Offboarding records. Auditors love this sample because it is unambiguous. A ticket per departure, with timestamps, closes it.
4. 4Log retention. If your window is twelve months and your logs roll off at thirty days, the evidence for month two is simply gone.
5. 5Security awareness training. Cheap, quick, and universally forgotten until the auditor asks for completion records.

What to put in place before the window opens

If you do nothing else, do these six things. They cover most of what a first Type II will sample, and they are all achievable inside a sprint or two.

• Branch protection with a required reviewer on every repository that reaches production.
• Single sign-on for every system holding customer data, with multi-factor authentication enforced and no shared accounts.
• A joiners, movers and leavers process with a ticket per event and an owner who is not the person leaving.
• Centralised logging with retention that comfortably exceeds your observation window.
• A vendor list with an owner, a data classification and a review date against each entry.
• One documented incident response plan, plus one exercise you actually ran, with notes.

Where engineering time genuinely goes

In our experience the technical work is roughly a fifth of the effort. The rest is instrumenting your existing processes so they produce evidence automatically, and writing down what you already do in a form that survives being sampled.

That is worth knowing before you start, because teams who expect a security project and receive an evidence project tend to lose two months to the surprise. Approach it as plumbing, automate the collection early, and the audit itself becomes uneventful, which is exactly what you want from an audit.