4.2.2. Information Security Program Metrics
💡 First Principle: A metric only tells leadership something useful if it can go up while risk actually goes down — activity counts can be inflated by busywork, but an outcome-based metric can't be gamed without actually changing the underlying risk.
Counting the number of vulnerability scans run per month measures effort, not effect — a team can run ten scans a month and never remediate a single finding. A better metric, such as mean time to remediate critical vulnerabilities, ties directly to actual risk exposure and can't be improved by activity alone; it requires genuinely closing gaps faster. Program metrics reported to the board (Phase 2's governance loop) should overwhelmingly favor this outcome-based category over volume-based activity counts, precisely because activity counts create an illusion of progress that outcome metrics don't allow.
⚠️ Exam Trap: Program metrics are sometimes designed around volume of activity (number of scans, number of training sessions delivered). The correct answer favors outcome-based metrics tied to actual risk reduction, since activity-based metrics can be inflated without changing real risk.
Reflection Question: Your team reports "500 vulnerabilities scanned this quarter" to the board as a security metric. What does this number fail to tell the board, and what metric would tell them more?
