A platform team builds and operates the deployment pipeline's policy gate for 40 product teams. The gate blocks a deploy when the service has no named owner or no tested rollback command. A product team ships a change that breaks checkout for two hours; the gate passed it, because no rule in the set looks at what a change does. In the three-lines model, who owns this risk?

What is being tested

Whether you can separate owning a risk from operating a control. Teams conflate the two the moment a control becomes a shared platform service, and the conflation is what produces gates that nobody improves and incidents that nobody owns.

The reasoning

In the three-lines model the first line owns and manages the risk: it is the team whose objectives create the exposure. The product team's change broke its own service, and the risk did not move when a shared gate was placed in its path. The platform team is a first-line provider too, with a different risk: that the gate does what its specification says, is available, and fails in a defined direction.

The second line oversees and challenges - does the rule set address the risks that actually materialise - and the third provides independent assurance that both are working. The 2020 update to the model is explicit that management owns the risk; nothing a service provider automates takes that away.

The architectural consequence is the part people miss. A gate asserts exactly the rules it encodes, and a pass carries no information about anything else. This gate attests ownership and rollback. It never looked at correctness. So the useful artefact is two statements shipped with every gate: what the control asserts, and what it explicitly does not. The second one goes into the pipeline output, so a green result cannot be read as "safe to ship".

Why the other options fail

• "The platform team owns the risk." This is the common and expensive error. It makes the gate's owner accountable for 40 teams' outcomes, so they respond rationally by adding rules until the gate is slow and still cannot see correctness. Operating a control is a service; it is not an assumption of someone else's risk.
• "Automation moves ownership to the second line." A second line that writes rules and then owns the outcome of them has lost its independence, and it is the one position in the model that cannot also be an operator. Approving a rule set is oversight, not acceptance.
• "Nobody owns it until the risk function assigns an owner." Ownership follows the objective, not the register entry. A risk with no entry still has an owner, and a register that is the only source of ownership is a register that goes stale during every reorganisation.

What this changes in the architecture

Measure the share of incidents whose cause was within the gate's rule set. A gate of 9 rules covering ownership and rollback typically scores under 10% of incidents over 12 months, and if it scores near 0% the rules are aimed at the wrong risks: adding more of the same costs review time and buys nothing. That single number is the second line's best lever, and it belongs on the platform's own dashboard. Prefer one rule the second line asked for over ten the platform team found easy to write.

When this is the wrong answer

When the platform genuinely owns the whole decision - it deploys on the team's behalf, chooses the configuration and holds the rollback - then it owns that risk, because it owns the objective. The test is not who runs the tooling. It is who decides, and who is answerable for the outcome.