Security metrics, SLOs and risk quantification
Metrics that change decisions: time to remediate by tier, MFA coverage, detection precision, and how to put a number on risk without pretending to be precise.
01Metrics that change decisions
- Pick leading and lagging indicators that leadership will act on
- Set security SLOs with error budgets
- Explain FAIR-style risk ranges without false precision
| Metric | Type | Why it moves decisions |
|---|---|---|
| % workloads on workload identity (no static keys) | Leading | Directly shrinks credential theft impact |
| Phishing-resistant MFA coverage | Leading | Removes the top initial access vector |
| Critical vuln MTTR, internet-facing | Lagging | SLA burn makes prioritisation explicit |
| Detection precision per rule | Quality | Low precision is analyst burnout |
| Mean time to contain | Lagging | Measures response engineering, not luck |
For risk, resist a single number. Give a range with assumptions: "a leaked customer-data export is plausible once every 2 to 5 years given current controls; impact 2 to 10 M in notification, churn and fines. Control X moves likelihood to once per 10 to 20 years for Y cost." Leaders can compare that to other spend. A heat map cannot be compared to anything.
"I pick a handful of metrics that are both measurable and causal: identity coverage, time to fix exposed criticals, detection precision, time to contain. Then I set SLOs and report the budget burn, so security competes for priority with the same vocabulary as reliability."
This is an advanced module
Advanced: Security Architecture at Scale is part of the Pro pass. 0 more sections — the deep dives, the final design, follow-ups and the test — unlock with it.
Already a cyart.io or studio.cyart.io member? Your pass code is in your Studio account.