GV.OV-03 says organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed. You need a small set of measures, reported on a schedule, that leaders use to change course. It is not a dashboard for its own sake.
What good looks like
Five to eight metrics, each with an owner, a definition and a target. Some are key performance indicators that show whether your processes work, such as how quickly critical vulnerabilities are fixed. Others are key risk indicators that show exposure growing, such as the number of unreviewed vendor accounts. Leaders see them regularly and ask questions that lead to action.
How to implement it
- Start from your strategy objectives (GV.RM-01). Pick one measure per objective.
- Write a one line definition for each metric: what is counted, where the data comes from, how often it is refreshed.
- Separate KPIs from KRIs. NIST's examples use both: KPIs to confirm policies and procedures achieve objectives, and KRIs to surface risks with their likelihood and impact.
- Automate collection where you can. Manual numbers pasted into slides drift and get disputed.
- Report to senior leadership at an agreed rhythm and record what they decided.
- Retire metrics nobody acts on.
Evidence to collect
- The metric catalogue with definitions, owners and targets.
- Dated reports sent to leadership.
- Minutes or tickets showing a metric changed a decision or budget.
- Source data or exports behind each reported number.
Common gaps
- Metrics count effort, such as scans run, rather than results.
- Numbers are produced by hand once a quarter and cannot be reproduced.
- No targets, so a trend line cannot be good or bad.
- Reports go out and no one responds.
Collecting evidence without the scramble
Reproducible numbers need evidence that is collected automatically and timestamped. The demo shows how evidence gets gathered from connected systems on a schedule so reports have a source you can point to.
A starter metric set
A small software company could begin with these. Time to fix critical vulnerabilities in production code, as a KPI with a seven day target. Percentage of staff who completed security training within 30 days of hire, as a KPI. Number of production accounts without a review in the last quarter, as a KRI. Number of critical suppliers with no current security review, as a KRI. Open risk register items past their treatment date, as a KRI.
Each fits on one line and each can be pulled from a system of record. Notice that none measures how busy the security team is. They measure whether the controls leadership asked for are working and where exposure is growing.
Reporting to leadership
Keep the leadership report to one page: the metrics, their trend against last period, a plain sentence on what changed, and the decisions needed. NIST's examples call for collecting and communicating risk management metrics with senior leadership, and the communication step is where many programs stall. If a number is red for two periods in a row, the report should say who owns the fix and when.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
How many metrics is too many?
If leaders cannot name what changed last quarter, you have too many. Start with five and add only when a decision needs it.
What is the difference between a KPI and a KRI?
A KPI tells you whether a process is performing. A KRI tells you whether exposure is rising. You need both views.
Sources
- NIST Cybersecurity Framework 2.0 Reference Tool, subcategory GV.OV-03: https://csrc.nist.gov/projects/cybersecurity-framework/filters
- NIST Cybersecurity Framework overview: https://www.nist.gov/cyberframework
The CSF is voluntary guidance. There is no CSF certification, so this post describes how to work toward the outcome, not how to pass an audit.
