Chapter 62 — Risk, metrics, and communicating with leadership

How it works

Qualitative vs quantitative risk:

   QUALITATIVE (High/Medium/Low heat maps)   fast, intuitive, low
     analytical overhead -- and the DEFAULT most organisations use.
     Weakness: "High" means different things to different people, and
     it's impossible to meaningfully compare "High cyber risk" against
     "High supply-chain risk" or "High market risk" on the SAME
     scale -- which is exactly what a board weighing competing
     investments needs to do.

   QUANTITATIVE (FAIR -- Factor Analysis of Information Risk, an Open
     Group standard)   expresses risk in DOLLAR terms:
       risk = Loss Event Frequency x Loss Magnitude
     both expressed as PROBABILISTIC RANGES (not single point guesses --
     FAIR analyses typically use Monte Carlo simulation to produce a
     distribution, e.g. "a 10-90% confidence range of $200K-$4M in
     annualised expected loss from this risk category") rather than false
     precision.
     STRENGTH: lands directly in the language executives and boards
     already use for every OTHER business risk they weigh (market risk,
     credit risk, operational risk) -- "this risk could cost us $X-$Y
     per year" is directly comparable to "expanding into this market
     could cost us $X-$Y", which a "High" severity rating simply cannot
     be.
     COST: genuinely harder to do well -- requires real data (or
     defensible estimates) for frequency and magnitude, and unskilled
     application produces false precision that's WORSE than an honest
     qualitative rating. Use it selectively, for your highest-stakes risk
     decisions and board-level asks, not for every finding in Ch 59's
     backlog.

The risk register — a living document, not an annual exercise:

   For each significant risk: description, likelihood, impact, OWNER,
   TREATMENT (the same four options as Part 1 Ch 4's threat-modeling
   decision: mitigate / accept / transfer / avoid), residual risk after
   treatment, and a REVIEW DATE. This is Part 1 Ch 4's threat-modeling
   output and Ch 59's risk-acceptance records, ROLLED UP to the
   organisational level -- the same discipline, applied at a coarser
   grain for leadership visibility.

Metrics that matter vs vanity metrics:

   METRICS THAT MATTER (each should be trended over time, not reported
   as a single snapshot):
     - MTTD / MTTR (mean time to detect / respond) -- Part 8's detection
       program directly produces this.
     - % of KEV/high-EPSS findings remediated within SLA (Ch 59) -- a
       far more informative number than raw finding count.
     - ATT&CK technique coverage % (Part 8 Ch 51/57's heat map) -- a
       genuine measure of detection breadth, with live-validation dates
       attached so it can't be gamed by writing untested rules.
     - % of access reviews completed on schedule, and the RATE of stale
       grants found and revoked per cycle (Part 7 Ch 49) -- both the
       process health AND the underlying risk trend.
     - % of assets with current classification/inventory (Part 7 Ch 41) --
       the foundational "do we even know what we're protecting" metric.
     - phishing-simulation click-through-rate TREND (if you run these) --
       trend matters far more than any single result.
   VANITY METRICS (avoid leading with these):
     - raw vulnerability/finding COUNT -- rises simply as scanning
       coverage improves; not informative about actual risk trend on its
       own (Ch 59).
     - number of SECURITY TOOLS deployed -- says nothing about whether
       they're tuned, integrated, or producing acted-upon findings.
     - training COMPLETION percentage alone, with no accompanying
       behaviour-change evidence (e.g. phishing-simulation click-rate
       actually improving) -- completion doesn't prove comprehension or
       changed behaviour.

Board and leadership reporting — the practical discipline:

   [ ] a SMALL number of KPIs (5-8, not 30) TRACKED OVER TIME, not a
       comprehensive data dump -- the board's job is oversight and
       resource-allocation decisions, not operating the security program;
       give them what they need to do THAT job.
   [ ] BENCHMARK against peers/industry where possible (breach-cost
       reports, industry maturity surveys) -- "our MTTD is X, industry
       median is Y" is more actionable than X in isolation.
   [ ] TIE metrics to BUSINESS OBJECTIVES explicitly -- "this system's
       uptime and integrity protect $X in annual revenue" or "this
       control reduces our exposure in the risk category the board
       flagged last quarter as a priority" -- connect the technical work
       to what the board already cares about, don't assume the connection
       is obvious to a non-technical audience.
   [ ] FRAME ASKS as resource-allocation decisions with an explicit
       risk-reduction rationale: "we need budget/headcount for X because
       it reduces risk category Y from [current state] to [target
       state]" -- not "we need more security tools" as an unquantified
       request.
   [ ] DIFFERENT AUDIENCES need different framing: an incident update to
       the immediate leadership team (technical detail, tactical
       decisions needed NOW) looks very different from a board-level
       quarterly update (strategic trend, business impact, resourcing
       asks) or a customer-facing communication (G1 Ch 51's incident-
       communication guidance, revisited here for the ongoing,
       non-incident reporting case too).

Building the business case for security investment:

   Proving a NEGATIVE (the breach that didn't happen because of this
   investment) is inherently hard -- there's no clean, attributable
   metric for "incidents prevented." Use what's available instead:
     - INDUSTRY BREACH-COST BENCHMARKS (e.g. the annually-published "Cost
       of a Data Breach" report from major vendors/researchers) to
       establish a credible order-of-magnitude cost-avoidance range for a
       given risk category.
     - FAIR quantification (above) for your highest-stakes specific
       decisions, where the analytical investment is justified by the
       size of the ask.
     - CONCRETE FINDINGS FROM YOUR OWN LABS AND AUDITS as the most
       persuasive evidence available: "here is the actual attack path we
       found and walked in our own environment (Part 1/2/4's hands-on
       labs), here is what it would have cost had it been a real
       attacker, and here is the specific, budgeted investment that
       closes it" is far more compelling to a leadership audience than an
       abstract risk statement, precisely because it's demonstrated, not
       hypothetical.