Every security metric worth collecting, with its exact formula, its data source, its cadence, its audience — and the specific way each one gets gamed or misread.
Who needs this: CISOs, SOC managers, GRC leads, anyone who has to build a board slide or defend a budget | Read time: 14 min | Maps to: CSF 2.0 GOVERN (GV.OV), IDENTIFY (ID.IM), DETECT (DE.CM) | CIS Controls 8, 17 | ISO 27001 A.5.35, A.5.36
Welcome to the appendix nobody reads until the week before the board meeting, cyber-survivors. Let us fix that now, calmly, with nothing on fire.
Here is the problem this catalog exists to solve. Almost every security metric in common use can move in the direction you want while the organization gets less safe. Mean time to respond drops when analysts close tickets faster. Vulnerability counts fall when a scanner quietly loses credentials to four hundred hosts. Alert volume drops when a log source stops reporting — and, delightfully, GuardDuty documents that its own machine-learning model will stop generating a finding if it decides continued activity from a remote host has become expected behavior (AWS). Persistent exfiltration goes quiet in the console. The graph goes down. You are being robbed.
So the discipline in this appendix is not "collect more numbers." It is: for every metric, know its formula, know where the data comes from, know who it is for, and know the exact lie it tells when it improves for the wrong reason. A metric you cannot describe the failure mode of is not a metric. It is decoration.
Each domain below gives you a table of six columns — metric, formula, source, cadence, target direction, audience — followed by the short list of ways that domain's numbers get gamed. Chapter 16 owns the governance model these feed; Chapter 9 owns detection instrumentation; Chapter 10 owns vulnerability prioritization. This appendix owns the definitions.
| Metric | Formula | Source | Cadence | Target | Audience |
|---|---|---|---|---|---|
| MTTD | mean(detection_ts − first_adversary_activity_ts) | Case management; onset timestamp set at post-incident review | Quarterly | Down | SOC, leadership |
| MTTC | mean(containment_ts − detection_ts), where containment = adversary can no longer act | Case management; containment action logs | Monthly | Down | SOC, leadership, board (SEV-1 only) |
| MTTR | mean(recovery_complete_ts − detection_ts) | Case management, rolling 30-day window | Monthly | Down | SOC only |
| Dwell time | eradication_ts − first_adversary_activity_ts, per intrusion, median | Post-incident review, per confirmed intrusion | Per incident, trended quarterly | Down | Board |
| Internal detection rate | internally-detected incidents ÷ all confirmed incidents | Mandatory detection_source field on every case | Quarterly | Up | Board |
| Time to first touch | mean(analyst_ack_ts − alert_created_ts) by severity | SIEM/SOAR queue | Weekly | Down | SOC |
| Detection coverage triple | per prioritized technique: telemetry / logic / last validated | DeTT&CT scoring plus detection repo metadata | Quarterly | Up | SOC, leadership |
Definitions follow Prophet Security and Crogl. Report dwell as a median, not a mean — one 400-day edge-device intrusion will otherwise erase a good year.
How this domain gets gamed or misread:
Takeaway: Report MTTC and internal detection rate. Keep MTTR on the SOC dashboard where its context lives.
| Metric | Formula | Source | Cadence | Target | Audience |
|---|---|---|---|---|---|
| KEV SLA attainment | KEV-applicable assets remediated or mitigated within tier deadline ÷ KEV-applicable assets | Scanner + asset inventory + KEV feed | Monthly | Up | Leadership, board |
| Median time to remediate, by severity tier | median(verified_fix_ts − advisory_publication_ts) per tier | Ticketing joined to scan results | Monthly | Down | Leadership |
| Exposure window | verified_fix_ts − first_exploitation_evidence_ts for KEV items | KEV catalog date vs. remediation record | Per KEV item | Down | Leadership |
| Asset inventory coverage | assets with an owner and a scan result ÷ assets known to any source | CMDB reconciled against cloud APIs, EDR, DHCP | Monthly | Up | Leadership, board |
| Open exceptions and renewals | count of live exceptions; mean renewals per exception | Exception register | Quarterly | Down | Board |
| Verification rate | closed remediations carrying a verification artefact ÷ closed remediations | Ticketing | Monthly | Up | SOC, leadership |
The benchmarks that make these numbers speak: 23.43% of KEV entries showed exploitation evidence on or before the day the CVE was published, and median time from CVE publication to KEV listing fell to 80 days (VulnCheck); across 13,000 polled organizations only 26% of KEV vulnerabilities were fully remediated, with median patching time rising to 43 days (DBIR 2026 coverage).
How this domain gets gamed or misread:
Actionable takeaway: Never print KEV SLA attainment without asset inventory coverage on the same line. They are one metric with two halves.
| Metric | Formula | Source | Cadence | Target | Audience |
|---|---|---|---|---|---|
| Phishing-resistant MFA coverage | privileged accounts with FIDO2/certificate-based auth enforced ÷ all privileged accounts | IdP authentication-methods report | Monthly | Up to 100% | Leadership, board |
| Standing privilege count | accounts with permanent membership of a highest-privilege role, excluding break-glass | IdP role assignments; cloud IAM | Monthly | Down to break-glass only | Leadership, board |
| Orphaned account age | median and max days since owner departure for still-enabled accounts | HR feed joined to directory | Monthly | Down | Leadership |
| Non-human identity count and ownership | NHIs with a named human owner ÷ total NHIs discovered | Cloud IAM, app registrations, CI token inventory, K8s service accounts | Quarterly | Up to 100% | Leadership |
| Unused-access decay | principals with permissions unused in 90 days ÷ active principals | IAM Access Analyzer unused-access analyzer; equivalent IdP reports | Quarterly | Down | SOC, leadership |
| OAuth grants with tenant-wide consent | grants where ConsentType = AllPrincipals for non-first-party apps | Get-AzureADPSPermissions.ps1 export; Workspace OAuth token log | Quarterly | Down | Leadership |
Sources for the collection mechanics: IAM Access Analyzer, Microsoft's illicit consent grant guidance.
How this domain gets gamed or misread:
| Metric | Formula | Source | Cadence | Target | Audience |
|---|---|---|---|---|---|
| Restore test success rate | successful restore tests ÷ attempted restore tests, by tier | Restore test log | Quarterly | Up | Leadership |
| Measured time to restore | wall-clock service_verified_ts − restore_approved_ts | Stopwatch during the test, including approvals | Per test | Down, vs. stated RTO | Board |
| RTO gap | measured TTR − stated RTO, per tier-1 service | As above | Quarterly | ≤ 0 | Board |
| Backup isolation coverage | protected assets with ≥1 copy in a non-overridable repository ÷ protected assets | Backup platform config audit | Quarterly | Up | Board |
| Age of oldest untested tier | days since last successful test at each tier | Restore test log | Monthly | Under ceiling | Leadership |
Chapter 12 owns the five-tier restore testing rubric these numbers come from.
How this domain gets gamed or misread:
| Metric | Formula | Source | Cadence | Target | Audience |
|---|---|---|---|---|---|
| Vendor tier coverage | tiered vendors with current diligence on file ÷ tiered vendors | Vendor register | Quarterly | Up | Leadership, board |
| Evidence currency | median age of the current SOC 2 / ISO certificate / pen test per tier-1 vendor | Vendor register | Quarterly | Down | Leadership |
| Standing integration count | active OAuth/API integrations with write or .All scopes into production data | IdP enterprise app inventory; SaaS admin consoles | Quarterly | Down | Leadership |
| Concentration exposure | tier-1 services dependent on a single provider, named | Dependency mapping | Annual | Named, not scored | Board |
| Vendor incident response time | vendor_notification_ts − vendor_incident_start_ts per notified event | Vendor notifications, contract terms | Per event | Down | Leadership |
Context worth putting beside these: third-party involvement appeared in roughly 48% of breaches in the 2026 DBIR, a ~60% year-over-year increase, and only 23% of third-party organizations had fully remediated their MFA issues (SecurityWeek).
How this domain gets gamed or misread: questionnaire completion rate is not assurance — it measures whether a vendor typed. Count reviewed evidence, not received evidence. And a vendor register that only contains vendors who went through procurement is missing the SaaS-to-SaaS integrations that caused most of 2025's cross-tenant damage.
| Metric | Formula | Source | Cadence | Target | Audience |
|---|---|---|---|---|---|
| Control coverage by IG tier | implemented safeguards ÷ safeguards in the tier (IG1 = 56 of 153) | Control assessment record | Semi-annual | Up | Board |
| Exercise cadence attainment | exercises completed ÷ exercises scheduled, by type | Exercise register | Annual | 100% | Board |
| AAR/IP closure rate | improvement-plan items closed by due date ÷ items raised | Improvement plan | Quarterly | Up | Leadership, board |
| Playbook freshness | playbooks with last_tested inside the stated ceiling ÷ active playbooks | Playbook repo CI check | Monthly | 100% | Leadership |
| Time-to-milestone in exercises | measured time to declare, assemble command, first holding statement, containment decision | Exercise evaluator record | Per exercise | Down | Leadership |
| Stalled-authority count | decisions in an exercise that waited on an absent approver | Exercise evaluator record | Per exercise | Zero | Board |
CIS Implementation Group counts are from CIS. The federal baseline expectation is that contingency and IR capabilities are exercised at least annually (NIST SP 800-84); CISA asks for a plan review quarterly (CISA IRP Basics). NIST SP 800-61r3 makes improvement a tracked category in its own right — from evaluations (ID.IM-01), from exercises (ID.IM-02) and from real incident execution (ID.IM-03) (SP 800-61r3).
How this domain gets gamed or misread: an exercise that is scheduled, run and never produces a closed improvement item is theatre with a catering budget. AAR/IP closure rate is the metric that separates the two (CISA CTEP). And stalled-authority count is the highest-value number in this whole table, because it is the only one that predicts what will actually go wrong at 03:00.
| Metric | Formula | Source | Cadence | Target | Audience |
|---|---|---|---|---|---|
| On-call load | pages per responder per week, and out-of-hours pages per responder per week | Paging platform | Weekly | Down | SOC, leadership |
| Alert volume per analyst | alerts requiring human decision ÷ analysts on shift | SIEM/SOAR | Weekly | Down | SOC |
| True-positive ratio | confirmed true positives ÷ alerts triaged, per detection | Case management joined to detection ID | Monthly | Up | SOC |
| Analyst attrition | voluntary departures ÷ average headcount, rolling 12 months | HR | Quarterly | Down | Board |
| Key-person concentration | procedures with exactly one person able to execute them | Runbook ownership audit | Semi-annual | Zero | Board |
| Consecutive-hours exceedances | responder-shifts exceeding the stated maximum during an incident | IC log | Per incident | Zero | Leadership |
The evidence base is real, not soft. Sleep deprivation leaves rule-following relatively intact but measurably degrades exactly what a novel incident demands — handling the unexpected, revising plans, filtering distraction and communicating effectively (Harrison & Horne, 2000). The peer-reviewed alert-fatigue survey cites industry false-positive rates as high as 99% (ACM Computing Surveys 57(9)). NCSC has the only government guidance dedicated to responder welfare and puts "include all staff in the IR plan" first (NCSC). And the British Library's published review recorded that its technology department "was overstretched before the incident and had some staff shortages" — the pre-incident staffing deficit became the recovery constraint (British Library review).
Six numbers. Trended over quarters, tied to money and days, each falsifiable.
Everything else stays off the board slide for one of three reasons. It is unactionable at that altitude (time to first touch, per-detection true-positive ratio). It is gameable without context (MTTR, alert volume, patch counts). Or it is an input rather than an outcome (backup job success, training completion, tickets closed). A director cannot act on a number whose movement they cannot interpret, and handing them one is not transparency — it is noise wearing a suit.
These numbers actively mislead. Replace them.
| Anti-metric | Why it misleads | Use instead |
|---|---|---|
| Patches applied / vulnerabilities closed | Rises with scanner noise and vendor advisory volume, both of which grew faster than exploitation risk | KEV SLA attainment; median time to remediate by tier |
| Blocked attacks / events per second | Counts unsuccessful noise; scales with internet background radiation | Confirmed intrusions and their dwell time |
| Security awareness training completion % | Measures attendance, not behavior | Reporting rate on simulations, and median time-to-report of a real phish |
| Backup job success rate | Measures whether a scheduler ran | Measured time to restore, and RTO gap |
| Alert volume (down = good) | Falls when a log source dies | Alerts per analyst plus log-source health |
| Total identities with MFA | Counts phishable factors as coverage | Phishing-resistant MFA coverage on privileged roles |
| Maturity score out of 5 | Self-assessed, non-comparable, moves when the assessor changes | Control coverage by IG tier, with the assessment evidence |
| Vendor questionnaires returned | Measures whether the vendor typed | Tier-1 vendors with reviewed, current evidence |
Actionable takeaway: Take your current executive deck and delete every row that appears in the left column. If the deck is now empty, that is the finding.
MTTD has a structural problem: you can only compute it for intrusions you eventually detected. Undetected intrusions contribute nothing to the average, which means the metric improves when your detection gets worse in the specific way that matters most — silently.
Here is how to instrument it anyway, without lying.
Set the onset timestamp during the post-incident review, never during the incident. first_adversary_activity_ts is an investigative finding, not a field someone fills in at 04:00. MTTD is a retrospective metric by construction and cannot be computed live.
Record the evidence horizon alongside it. If your identity logs retain 30 days on a P1 license (Microsoft) and CloudTrail Event history holds 90 days of management events (AWS), then any dwell time you report is bounded by your retention, not by the adversary. A 30-day MTTD in a 30-day-retention estate means "at least 30 days." Put that phrasing in the footnote. Note also that some sources lag — Google Workspace OAuth token log events arrive a couple of hours late (Google) — so an onset timestamp derived from them is a floor, not a fact.
Make detection_source a mandatory field on every case, with values internal, external party, or adversary announcement. This is the companion measure that makes MTTD honest, because it is the one detection metric that cannot be improved by closing tickets faster.
Report the three together, always: MTTD, internal detection rate, and coverage triple. MTTD alone is a claim about speed. The three together are a claim about speed, honesty and scope.
Now the part leaders get wrong. When you present this limitation, do not undercut your own number by apologizing for it. Say it as a property, in one sentence: "MTTD measures the intrusions we found; the internal detection rate measures how often we are the ones who find them, and that is the number I want you watching." That framing is stronger than a clean-looking MTTD, because a board that understands the limit understands why the ingest budget matters. Undermining your metric is admitting it is bad. Bounding your metric is demonstrating you know what it measures. Same fact. Completely different meeting.
Actionable takeaway: Add two mandatory fields to your incident record this month — detection_source and evidence_horizon_days — and footnote every MTTD you publish with the second one. It costs a dropdown and a number, and it is the difference between a metric and a claim.
Metrics are the only part of a security program that outlives the person who built it. Choose them badly and you leave your successor a decade of charts that go the right way while the estate rots underneath. Choose them well and you leave behind something rarer: a set of numbers that get worse when things get worse.
Count what an attacker would care about, publish the denominator, and never trust a graph that only goes down.