Security Engineering · Chapter 10 of 12
Risk and controls, and the three lines
The governance model every regulated organisation runs on — the vocabulary from scratch, one control walked end to end, and where it turns into theatre.
If you work in a bank, an insurer, a listed company or anyone selling to them, this is the machinery around your work — and the vocabulary is the barrier, not the ideas. An engineer who can say ‘that is a design deficiency, not an operating one’ in the right meeting changes the outcome of that meeting.
The model, and the rename you should know about
For twenty years this was the Three Lines of Defence. In July 2020 the Institute of Internal Auditors renamed it the Three Lines Model and restructured it around six principles.
What actually changed, and why practitioners still say “defence”
“Defence” was dropped because it framed risk purely as something to avoid. A new principle, Creating and Protecting Value, has no analogue in the old version — the point being that an organisation exists to take risk intelligently, not to minimise it.
The numbering was explicitly stripped of sequence. A footnote in the document says it directly, because the old name invited people to read it as a relay.
First and second line roles may be blended in one team or one person. They are roles, not departments.
But the banking world kept saying ‘defence’, and there is a good reason. The phrase entered banking through the Basel Committee's operational-risk principles, not through the IIA — and that text, revised as recently as 2021, still says three-lines-of-defence model. Your prudential regulator did not adopt the rename.
So both names are current, in different rooms. Use whichever your audience uses, and know why they differ.
The vocabulary, from zero
| Term | What it means | Technology example |
|---|---|---|
| Risk capacity | The hard ceiling — how much you could absorb before the organisation is threatened. A fact, not a choice. | The largest data breach the company could survive, given insurance and cash. |
| Risk appetite | How much you are willing to take, chosen inside that ceiling. | “We accept moderate risk from adopting new cloud services quickly.” |
| Risk tolerance | The operating band around a specific objective. Narrower and concrete. | “No more than 4 hours of unplanned downtime a quarter on payments.” |
| Inherent risk | Exposure before any control. | Holding customer data at all, with nothing protecting it. |
| Residual risk | What is left after controls. | The same, after encryption and access control — not zero. |
| Control owner | Accountable for the control running. | The platform lead who runs the access review. |
| Risk owner | Accountable for the outcome. Usually more senior, and usually a different person. | The CTO, who owns ‘unauthorised production access’. |
| RCSA | Risk and control self-assessment. The business rates itself; the second line challenges it. | A team declares its access control ‘Effective’. Compliance samples that claim. |
| Compensating control | A substitute, used only when the real control genuinely cannot be implemented. Must offset the same risk to the same rigour. | Cannot disable a legacy admin account? Isolate it, record every session, alert on every use. |
Appetite must sit well inside capacity, and the gap is the point.
Capacity is the ceiling. Appetite is where you choose to operate under it. Tolerance is the band you run in day to day.
If appetite and capacity converge, one bad quarter is existential. An organisation whose stated appetite is at its capacity has not made a decision — it has written down what it was going to do anyway.
Design versus operating effectiveness — the distinction that matters most
Design effectiveness asks: if this control ran exactly as written, would it work at all? Operating effectiveness asks: did it actually run, consistently, over the period?
The example that makes it stick: a change-approval policy requiring sign-off from any engineer — including the one who wrote the change — is designed wrong. It cannot prevent self-approval no matter how perfectly it is followed. Testing whether people followed it is a waste of time. And note the ordering: if the design is deficient, operating testing is moot — a well-run bad control is still a bad control.
One control, end to end
When it fails, the language is specific and worth getting right:
- An observation — worth improving, not a failure. ‘Your runbook is two versions out of date.’
- A finding — a real gap needing remediation and usually a root cause. ‘12 of 45 terminated employees kept access beyond the 24-hour target.’
- An issue — the tracked ticket with an owner and a due date, whatever its origin.
- A risk acceptance — a formal, time-bound decision to leave a residual risk untreated. Who signs scales with severity, and there is a point worth carrying: the CISO should not be the sole approver. The security function flags the risk and calibrates the rating; the business that owns the risk signs for it — and anything above stated appetite goes to the board.
Metrics: KPI, KRI, KCI
Three initialisms, one causal chain, and understanding the chain is more useful than the definitions.
- KCI — key control indicator. Is the control operating? ‘% of production deployments that passed the automated policy check.’
- KRI — key risk indicator. Is exposure rising? ‘% of cloud accounts created outside the approved pipeline.’
- KPI — key performance indicator. Business output. Nothing to do with risk. ‘Deployments shipped this sprint.’
- The chain runs KCI → KRI → KPI. A control quietly degrades, so the KCI drops. Exposure rises later, so the KRI moves. The business takes a hit later still. By the time it shows up in a KPI it is an incident, not a metric — which is the entire argument for watching the leftmost one.
Where it goes wrong
- The first line abdicates. ‘Security will tell us if there is a problem’ — but the IIA is explicit that the risk stays with the business regardless of what the other lines do. A second line that ends up operating controls has become a first line with no one challenging it.
- Duplicated testing. Three lines testing the same 25 accounts three times is the model implemented backwards. Each line should be doing a different job.
- A residual-risk number that looks computed. The formula residual = inherent × (1 − control effectiveness) circulates widely and is a teaching aid, not arithmetic — control effectiveness is not a clean percentage and risk is not linearly scalar. Treat a tool that reports it to one decimal place with suspicion.
- Risk acceptances with no expiry. An acceptance without a date is a decision to never fix it, made by someone who has since left.
- Evidence that is a screenshot. See control frameworks — the same failure, and the same fix.
The tools, briefly
Two markets get called ‘GRC’ and they do not compete. Enterprise integrated risk management — ServiceNow IRM, Archer, MetricStream, IBM OpenPages, Diligent, Workiva, and AuditBoard, which renamed itself Optro in March 2026 — sells to large regulated organisations on negotiated contracts. Compliance automation — Vanta, Drata, Secureframe — sells a fast path to a SOC 2 report, with published per-seat pricing. A startup buying Vanta and an insurer buying Archer are not in the same market.
And a caution on market sizing: published figures for this space range from about $15 billion to over $70 billion depending entirely on what the analyst chose to include. Any single ‘the GRC market is worth X’ claim is meaningless without the definition attached.
Check yourself