An organisation adopts the three-lines model and it produces friction without assurance. What went wrong?

What went wrong

Usually one of three things:

• The second line reviews without authority or expertise, so it produces comments the first line absorbs or ignores, and the review adds delay rather than assurance.
• The first line believes risk is the second line's job, which removes accountability from the people who make the decisions — and the decisions are where the risk is created.
• The lines are treated as approval stages rather than as different accountabilities, producing a serial process where each stage waits for the previous one.

What the model actually says

The first line owns and manages the risk. They make the decisions and are accountable for the outcomes. The second line sets the framework and provides challenge. The third provides independent assurance that the first two are working.

None of them is an approval gate, and treating the second line as one is the most common misapplication — it converts challenge into a queue and accountability into compliance.

What makes it work in an engineering organisation

• Risk owned by the team that makes the decision, with the second line providing the framework, the standards and the tooling that make good decisions easy.
• The second line building the paved road rather than reviewing departures from it — a control in the pipeline is faster, more consistent and produces evidence as a by-product, and it scales where review does not.
• A narrow set of decisions requiring genuine second-line involvement, with a stated trigger, and explicit delegation of everything else.
• The third line testing whether the controls operate, including whether the second line's controls are running at all — since a control that stopped produces silence, and silence looks like success.

The failure the model is supposed to prevent

Risk decisions made with no accountable owner. A team ships something risky, nobody objected, and when it fails the question of who accepted the risk has no answer.

An accepted risk needs a named accepter at an appropriate level, a recorded rationale and a review date — without which "accepted" is indistinguishable from "ignored", and the distinction matters enormously when the risk materialises.