The three lines of defence model still leaves analysts answering alone

The question three lines of defence should be asking

A three lines of defence model assigns risk accountability across three distinct functions, each with a different relationship to the decision being examined.

The first line is whoever makes the operational call under pressure, typically a security analyst or SOC team member deciding in real time whether an alert warrants escalation. The second line is risk and security governance, whose job is to review whether that call was reasonable given the information available at the time, not to relitigate it with the benefit of hindsight. The third line is internal audit, which checks independently, after the fact, whether the first and second lines actually did what they were supposed to do.

The distinction that gets lost in board-level framing is this: a gap and a bad decision are not the same finding. A gap means something was missed. A defensible decision that turned out badly means the analyst weighed the available evidence reasonably and the outcome was still wrong, which is a different problem with a different fix. A three lines structure that only hunts for gaps will keep finding process fixes for what is actually a judgment problem, and it will keep leaving the person who made the original call to carry that judgment alone.

What happens when the first line carries the decision alone

When second line review does not genuinely test the reasonableness of a first-line call, and only checks that a process was followed, the analyst who made the original judgment becomes the only person who ever actually assessed it. That gap shows up clearly whenever a first-line decision gets made under time pressure with incomplete information and no meaningful second or third line check follows.

A vulnerability disclosed this month across seven AI coding agents is a useful live illustration of exactly this pattern, even though it sits outside a traditional SOC context. The flaw let a malicious repository hijack an AI coding agent's git operations, and the practical exposure depended entirely on split-second judgment calls: whether to trust an agent's autonomous actions inside a live repository, made by whoever was running that agent at the time, with no independent second line checking whether that trust was warranted before or immediately after the fact. The specific technology is different from a SOC alert queue, but the accountability structure is identical: a single person's in-the-moment judgment stood in for a review process that, on paper, existed to test it.

This is the pattern the three lines model is designed to prevent, not by adding another approval step before the first-line decision, since that would defeat the purpose of having a first line at all, but by making sure the second and third lines actually interrogate the reasonableness of the call afterward, rather than confirming a checklist was followed.

What a functioning three lines structure looks like in practice

A three lines model that works does not just have three functions named. It has a second line that can reconstruct what the first line actually knew at decision time, and a third line that can verify, independently, that the second line's review was substantive rather than procedural.

How one audit firm unified its three lines of defence shows what that looks like when the structure is built around a single, traceable line of evidence connecting a first-line decision to the second-line review of it and the third-line check on that review, often described as a golden thread running through all three lines. Rather than three functions each keeping separate records that a decision was reviewed, the evidence itself connects the original judgment call to the review of its reasonableness, which is what makes the second-line check verifiable rather than assumed.

That connective structure is the practical difference between a three lines model that exists on an org chart and one that actually changes what happens after a difficult call gets made. Without it, second line review tends to default to checking that a process step occurred, because there is no accessible record of what the first line actually knew to test the reasonableness of the decision itself.

The reframe that matters

Three lines of defence software and process design is usually sold on coverage: does every risk have an assigned owner across all three lines. Coverage is necessary but it is not the test that matters. The test that matters is whether the second line can answer, for any first-line call under scrutiny, whether it was defensible given what was known at the time, and whether the third line can verify that this review genuinely happened rather than being recorded as complete.

An organization that can only ask "was there a gap" after an incident is still leaving its analysts to carry every real-time judgment call alone. An organization whose three lines can ask "was this defensible" has built a structure that actually does what the model is supposed to do.