How does the three-lines model apply to a modern engineering organisation, and what goes wrong when the second line is staffed by people who cannot read the systems?

The model

First line — the teams that own and operate the systems, and therefore own the risk. Second line — risk and compliance functions setting policy and monitoring adherence. Third line — internal audit, independently assuring that the first two work.

The intent is sound: those closest to the work manage the risk, a specialist function sets standards, and an independent function verifies.

What goes wrong in engineering contexts

The second line frequently cannot read the systems it governs. A risk function whose members cannot assess a deployment pipeline, a Kubernetes configuration or an access model produces policy that is either unimplementable or trivially satisfiable, and engineers learn that compliance is a documentation exercise disconnected from actual risk.

The consequences are specific:

• Policy written in terms the systems do not have, so compliance is asserted rather than demonstrated.
• Controls that address the documented process rather than the real one, missing where the risk actually is.
• Engineers routing around the second line, which then loses visibility of what is happening.
• The second line's credibility exhausted, so its genuine findings are discounted along with the rest.
• Assurance activity that consumes engineering time without reducing risk — the outcome that makes the whole function resented.

What makes it work

• Technical capability in the second line. People who can read a pipeline configuration, evaluate an access model and understand a deployment mechanism. This is the single determining factor, and it is a staffing decision rather than a process one.
• Policy expressed as code where possible, so adherence is evaluated continuously and automatically rather than asserted in a document — which also forces the policy to be precise enough to be executable.
• Evidence generated by the systems, not assembled by engineers for an audit.
• The first line genuinely owning the risk, with the second line enabling rather than approving — an approval gate transfers ownership to the approver, which is exactly the wrong direction.
• The second line embedded early, at design time where judgement changes the outcome, rather than at release time where it can only approve or obstruct.
• The third line testing the controls and the monitoring, rather than re-testing the population — which is a smaller, deeper and more valuable engagement.

The reframing that helps

The objective is that risks are understood, owned and controlled — not that a function has reviewed something. Where automated gates, progressive delivery and continuous control monitoring achieve that objective better than a review, the second line's contribution is designing and verifying those mechanisms rather than performing the reviews manually.

A second line that builds the guardrails is a multiplier; one that operates the gates is a bottleneck — and which of those it becomes is determined almost entirely by whether it has the technical capability to build.