GV.OV-03 Risk management performance evaluated: requirements and evidence

What GV.OV-03 asks for and why leaders keep missing it

GV.OV-03 is a Subcategory of the Oversight (GV.OV) Category in the Govern Function of NIST CSF 2.0, and it is new in CSF 2.0 with no clear counterpart in CSF 1.1. Its outcome is that the organization's cybersecurity risk management performance is evaluated and reviewed, so leaders can decide whether to adjust direction. If you are the compliance lead or CISO who must show that leadership actually reviews cybersecurity risk performance, this Subcategory is the one an assessor will ask you to prove with dated records of decisions, not with a dashboard alone.

The risk GV.OV-03 addresses is drift. A cybersecurity strategy can slowly stop matching the threats, technology and business priorities it was written for, and nobody notices because the program keeps producing activity. Teams report patch counts, training completion and alert volumes, yet those numbers are never compared with the risk appetite and objectives set under GV.RM, so no one asks whether the program is still reducing the risks that matter. The gap is usually not missing data. Metrics often exist in a ticketing system or a monthly report, but they are not reviewed by anyone with authority to change funding, priorities or tolerances, and they are not tied to a named decision.

Start with a check you can run this month. Pick the key performance indicators and key risk indicators your program already reports, then ask for each one: who reviewed it last, what threshold triggers action, and which decision changed because of it. Where the answer is blank, that is your gap. The three Implementation Examples NIST publishes for GV.OV-03 cover reviewing KPIs and KRIs and communicating risk management metrics to senior leadership, and they are the natural checklist for that exercise. Confirm the exact wording of those examples in the NIST CSF 2.0 Core publication before you map your own evidence to them.

Which metrics, teams and systems GV.OV-03 covers

GV.OV-03 asks whether cybersecurity risk management performance is evaluated and reviewed so leaders can adjust direction. The work depends on a few scoping choices made before any dashboard is built, and each choice changes how much data must be collected, checked and explained.

Which risk activities produce metrics

Start by listing the risk management activities that should yield a KPI or KRI, such as vulnerability remediation, access reviews, risk assessments, incident handling and third-party reviews. Each activity you include needs a named data source, an owner and a definition of what good looks like. A short list tied to decisions leaders actually make is easier to evaluate than a long catalog of counters nobody reads. Ask which indicators will trigger a change in direction and which are only informational.

Which business units feed data

Every business unit that owns systems, data or risk decisions may need to contribute figures. Units that run their own platforms, cloud accounts or applications often hold the raw data, while central security teams hold the scoring logic. Confirm who extracts each figure, how often, and whether the unit can reproduce the number if an assessor asks. Effort grows quickly when each unit reports in its own format.

Which third parties contribute figures

Managed service providers, cloud platforms and software suppliers may hold evidence the organization needs, such as patch status, uptime, or incident notifications. Decide which third-party figures are required for leadership reporting and write those data obligations into contracts or service reports. Without this, a metric may show a gap that only the supplier can close or verify. Check what each supplier can provide and in what format before committing to a KRI that depends on it.

Which senior leaders receive reports

The audience changes the content. A board committee usually needs a short set of trend-level indicators tied to risk appetite, while an executive team may need operational detail to decide on funding or staffing. Each audience you add means another version of the report to produce, review and keep consistent. Agree in advance which decisions each recipient must make from the report, and reduce the set to what supports those decisions.

How often metrics are reviewed

Review frequency sets how much automation is needed. Indicators refreshed continuously from logs or scanners demand pipelines and data quality checks, while figures compiled by hand each quarter demand reliable calendars and sign-off steps. Match the cadence to the speed at which each risk changes, and record the date of each review so you can show that performance was evaluated at the intervals you set.

KPIs versus KRIs: choosing what leadership should see

Key performance indicators and key risk indicators answer different questions, and GV.OV-03 needs both. A key performance indicator (KPI) shows whether the cybersecurity risk management program is working as designed, for example whether it is closing the work it planned. A *key risk indicator (KRI)* signals that exposure is rising before an incident makes it visible. Illustrative KPIs include the share of critical patches applied within the window the organization has set, the percentage of incident response exercises that met their stated objectives, and the number of risk treatment items completed on schedule. Illustrative KRIs include the count of internet-facing systems with known exploitable vulnerabilities, the number of open risk treatment items past their due date, and the volume of failed privileged access reviews. The useful test for any candidate metric is whether a leader could act on a change in it.

Review the two sets on different rhythms and with different owners. KPIs are usually reviewed against targets set in the risk management strategy, so a missed target prompts a question about the program: is the resourcing enough, is the process broken, or is the target wrong? KRIs need thresholds agreed in advance, so that a breach triggers a documented decision such as accepting the risk, adding a compensating control or escalating. Write the threshold, the owner and the response for each KRI before it appears in a leadership pack. Confirm with your own risk owners where the data comes from and how often it is refreshed, since those details decide whether the metric can be trusted.

The Implementation Examples for GV.OV-03 pair KPI and KRI review with collecting and communicating risk management metrics to senior leadership, because a metric that stays with the security team does not inform direction. Keep the leadership set short enough to discuss in one sitting and trace each figure back to its source system so an assessor can re-perform the calculation. The NIST CSF 2.0 Reference Tool lists informative references for GV.OV-03, including controls from other frameworks, and the mappings may change as NIST updates them. Check those references directly in the tool before you cite them as evidence, and confirm that each one applies to your environment.

How an assessor tests GV.OV-03 metric review and reporting

This table sets out the question an assessor asks for each part of GV.OV-03, the evidence that answers it and the findings that show up most often. Read it as a checklist for your own metric program before an assessment, since the same questions usually come up in a self-assessment or a customer review.

Test area	Question the assessor asks	Evidence requested and common findings
Metric definitions	Are the KPIs and KRIs defined, with owners, data sources and purpose?	Metric definitions, owners and data sources. Finding: metrics exist as a list but no one owns the data or can say what a threshold means.
Review cadence	Does leadership review the metrics on a set schedule, and is that schedule followed?	Calendar entries, agendas and minutes from review meetings. Finding: metrics defined but never reviewed, or reviews skipped without a record.
Risk indicators	Do the reports include key risk indicators, not only activity counts such as patches applied or tickets closed?	Leadership reports showing KRIs alongside KPIs and trend data. Finding: reports that omit risk indicators or show only compliance activity.
Link to decisions	Do the metrics lead to documented decisions about priorities, resources or risk treatment?	Decision logs, action items and records of changes made after a review. Finding: no link from metrics to decisions, so reviews end without outcomes.
Threshold and escalation	Are there defined thresholds that trigger escalation or a change in strategy?	Threshold settings, escalation records and examples of escalations raised. Finding: thresholds set at levels that never trigger, or none documented.
Source integrity	Can the organization show where the figures came from and that they were checked?	Data source descriptions, calculation notes and samples traced back to systems. Finding: figures compiled by hand with no record of method.
Scope of the framework evidence	Is the metric program tied to the organization's chosen CSF Target Profile or self-assessment?	Mapping of metrics to the GV.OV-03 outcome and the Profile, plus the assessment record. Finding: the mapping is absent, so the assessor cannot confirm coverage.

Implementing GV.OV-03 step by step

This sequence turns GV.OV-03 from a statement of intent into a working cycle: leaders agree what the measurements must answer, owners produce the numbers, and each review ends in a recorded decision about the risk management program.

Define the questions the metrics must answer
Start with the risk management objectives already set in your cybersecurity risk management strategy and list the decisions leaders need to make about them, such as whether to fund a control area, accept a risk or change a supplier approach. Senior leaders, the CISO and risk owners agree this list in writing. The output is a short objectives-to-questions sheet. The step is complete when every planned metric can be traced to one objective and one decision.
Select KPIs and KRIs with named owners
Choose key performance indicators that show whether the program is working, such as the share of planned controls operating as designed, and key risk indicators that show exposure is rising, such as the number of open high-severity findings past their due date. For each one, name an accountable owner and the system or report that supplies the data. Keep the set small enough that owners can defend every number. The output is a metric register listing definition, formula, owner, data source and collection method for each metric.
Set review cadence and decision thresholds
Decide how often each metric is reviewed and what value triggers action. A threshold should name the response in advance, for example escalation to the risk committee, funding a remediation project or revisiting the risk appetite. Confirm the cadence against your governance calendar and any regulatory or contractual reporting dates you must meet. The output is a review calendar and a threshold table attached to the metric register. The step is complete when each metric has both a date and a pre-agreed response.
Test the data before the first review
Before leaders see any figure, owners run the collection once and check the results against source records. Look for gaps, double counting, stale data and metrics that move for reasons unrelated to risk. Correct definitions where the data cannot support them and remove metrics that cannot be measured reliably yet. The output is a validation note per metric recording the source checked and any limitation. The step is complete when each metric has been reproduced from its source at least once.
Run the first review with senior leaders
Present the leadership pack to the executives who own the risk decisions. The pack should show each metric's current value, its trend, the threshold status and the open questions the data raises, with no more than a few pages of narrative. Leaders confirm whether the metrics answer the questions set in the first step and whether any threshold needs changing. The output is the leadership pack and a list of proposed actions. The step is complete when the attendees agree the pack is fit for decisions.
Record decisions and adjustments in a decision log
Every decision from the review goes into a decision log: the metric or threshold that prompted it, the decision taken, the accountable owner, the date and the expected follow-up. Adjustments to strategy, resourcing, risk acceptance or metric definitions appear as separate entries so later reviews can see what changed and why. The output is a dated decision log, reviewed by the same leaders at the next cycle. The step is complete when each proposed action is either approved with an owner or formally closed with a reason.
Repeat the cycle and retire weak metrics
At each review, check whether earlier decisions changed the metrics, whether thresholds fired at the right times and whether any metric stopped informing decisions. Update the metric register, calendar and thresholds, then run the next collection and review on the agreed cadence. Retire metrics that no longer support a decision and add ones that cover new objectives. The output is a revised metric register and a review record that shows the cycle is running. An independent assessor will expect to see this record, so keep it current.

Evidence that shows metrics were reviewed and acted on

GV.OV-03 asks whether cybersecurity risk management performance is evaluated and reviewed so leaders can decide on adjustments. An assessor will look for a chain of records: the metrics, the data behind them, the review, the report, and the decision that followed. The cards below cover each link and how to keep it current between formal assessments.

Metric register with owners

The metric register defines each KPI and KRI: its purpose, formula, data source, reporting frequency, target or threshold, and the named owner accountable for it. It is the first thing an assessor asks for because it shows the organization chose its measures deliberately. Keep a version history so changes to thresholds are visible. Check that every metric links to a risk or objective in your risk management strategy, and that owners still hold their roles.

Source data extracts

Each reported value should trace back to a dated extract from the system that produced it, such as a ticketing queue, vulnerability scanner, identity platform or log store. Store extracts with the query or export settings used, so the number can be reproduced. Between audits, schedule the extracts on the same cadence as the reporting cycle and spot-check a sample each quarter. Confirm which of your self-hosted tools can export history with timestamps.

Review meeting minutes

Minutes record who reviewed the metrics, which indicators breached thresholds, what questions were asked, and which risks were discussed. They show that evaluation happened on a set schedule rather than only when an incident prompted it. Record attendance, the metric version reviewed, and open actions with owners and due dates. Keep minutes in the same repository as the register so an assessor can follow a metric from definition to discussion.

Leadership risk report

The leadership report is the document senior management actually reads: current KRI status, trends since the last cycle, risks above appetite, and the decisions required. It shows the evaluation reached the people who set direction. Keep prior versions unchanged once issued, and note the data cut-off date on each. Confirm with your leadership team which report format they use so the evidence matches what they receive.

Decision records and adjustments

Decision records link a metric outcome to an action, such as changing a control priority, adjusting a threshold, funding remediation or accepting a risk. This is the strongest evidence that metrics led to adjustment, which is what GV.OV-03 asks for. For each record, state the trigger metric, the decision, the approver and the follow-up date, then check at the next review whether the adjustment worked. Records with no follow-up are a common gap.

Review schedule and mappings

The review schedule sets the cadence for each metric and records who runs each review. Alongside it, keep a crosswalk to the informative references NIST lists for GV.OV-03: SP 800-53 Rev. 5.2.0 controls PM-4, PM-6, RA-7 and SR-6, ISO/IEC 27001:2022 clause 9.1 and Annex A controls 5.1, 5.19, 5.20, 8.30, 8.32 and 8.34, and SP 800-171 Rev. 3 requirements 03.11.01 and 03.11.04. Tools such as CISO Assistant (AGPL-3.0-only) can hold framework assessments and mappings, but confirm how it records metric reviews in your own setup before relying on it.

What meeting GV.OV-03 costs in money and effort

This table lists the cost components of evaluating cybersecurity risk management performance under GV.OV-03, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are published for this Subcategory, so use the table to structure a written quote and compare proposals on the same components.

Cost component	One-time or recurring	Who is paid or who carries the effort	What drives it up or down
Tooling or licenses	Recurring if commercial; one-time setup for self-hosted tools	Software vendor for commercial GRC or dashboard products; no license fee for open-source tools, but hosting and admin effort remain	Number of KPIs and KRIs, user seats, and whether dashboards are self-hosted in your own environment or bought as a hosted service
Engineering time to build metric pipelines	One-time build, then recurring maintenance	Internal platform or security engineers, or an implementation partner under a fixed-scope agreement	How many source systems feed metrics (ticketing, asset inventory, vulnerability scanners, SIEM), data quality, and whether metrics are automated or collected by hand
Defining KPIs and KRIs with stakeholders	One-time, revisited when the strategy changes	Risk, security and business leaders, with facilitation by internal GRC staff or a consultant	Number of business units in scope, existing risk appetite statements, and how many rounds of agreement are needed on definitions and thresholds
Leadership review and decision time	Recurring, usually at a fixed cadence	Senior leaders and board committee members, whose time is an internal cost	Meeting frequency, quality of the metric pack, and whether reports show trends and decisions needed rather than raw counts
Evidence upkeep	Recurring	Control owners and GRC staff who store review minutes, metric snapshots and decision records	Retention rules, the number of metrics that need evidence, and whether evidence is captured automatically when reviews happen
External review or testing	Recurring or periodic	Independent assessors, consultants or testers, paid by the organization	Whether the reviewer tests the metrics themselves or only the review process, and how much sampling the assessment plan requires
Auditor sampling	Recurring at each audit cycle	External auditor or certification body, which issues any report or certificate	Number of review cycles in the audit period, the scope of the assessment, and how easily the organization can produce the records for selected periods
Remediation of gaps found in review	Variable, one-time per finding	Internal teams or an implementation partner for technical fixes	Number of findings, age of metric definitions, and whether gaps are caught in internal reviews before the external assessment

Who owns the metrics, what a partner prepares and what the auditor tests

Your organization owns GV.OV-03 in full. The Subcategory asks whether cybersecurity risk management performance is evaluated and reviewed so that leaders can decide on adjustments, and no outside party can make that judgment for you. Your team sets the objectives the metrics should reflect, chooses which key performance indicators (KPIs) and key risk indicators (KRIs) matter for your risk appetite, decides who reviews them and how often, and records what leaders decided and why.

Objectives and metric choices: Define what each KPI and KRI is meant to show, its owner, its data source and its threshold for escalation.
Leadership reviews: Schedule the forums where metrics are discussed, and keep minutes that show who attended and which adjustments were agreed.
Decisions and follow-up: Track each adjustment to closure, including changes to investment, staffing or risk treatment.
Metric register ownership: Approve changes to the register and retire indicators that no longer inform decisions.

Confirm with your own governance documents that these responsibilities are assigned to named roles, because an assessor will ask who signs off on the metrics as well as who collects them.

Where GV.OV-03 programs usually fall short and how to close each gap

GV.OV-03 asks whether cybersecurity risk management performance is evaluated and reviewed so leaders can decide on adjustments. Most programs fail that test in a handful of predictable ways, and the gaps below tend to reinforce each other. Each card names the gap, the fix and what to check in your own environment.

Metrics without owners

A KPI on a dashboard with no named owner is rarely reviewed, and nobody is accountable for moving it. Assign each metric to one role that can explain its data, set its target and act when it drifts. Check that every metric in the review pack names an owner, and that the owner has accepted the metric in writing. Metrics that no one will defend in a leadership meeting should be removed rather than kept for appearance.

KRIs that duplicate KPIs

Many programs report the same measurement twice, once as a performance indicator and once as a risk indicator. A KRI should signal rising exposure before a loss event, such as a growing count of unpatched critical assets past due, while a KPI tracks how well a control process is running. Review each KRI and ask which risk it warns about and what leaders would do if it moved. If the answer is the same as for the paired KPI, merge or rewrite one of them.

Reports that never reach senior leadership

Metrics often stay inside the security team's tooling, so the executives who own risk appetite never see them. Agree a fixed reporting cadence, a short set of metrics and a named recipient group with the executive sponsor. Confirm that the minutes or board pack show the metrics were presented and discussed, since that record is the main evidence an assessor will look for.

No record of decisions taken

Reviewing performance only counts under GV.OV-03 if the review leads to a recorded decision, such as funding a remediation, accepting a residual risk or changing a target. Keep a decision log that links each reviewed metric to the decision, the decision owner, the date and any follow-up task. When a metric is reviewed and nothing changes, record why. Ticketing or GRC workflows can hold this log, but the content matters more than the tool.

Thresholds never defined

A metric without a threshold cannot show when leadership should act, so every review ends with a discussion instead of a decision. Define the value that counts as acceptable, the value that triggers escalation and the action that follows, and tie these to the risk appetite and tolerance set under GV.RM. Revisit thresholds after incidents or significant changes in the environment, and record each change and its approver.

Metrics that cannot be traced to a data source

If a figure in a board pack cannot be traced to a system export, scan result or ticket query, its accuracy cannot be tested. For each metric, document the source system, the query or calculation, the collection frequency and the person who produces it. Keep the query and the raw output with the report so a reviewer can reproduce the number. Self-hosted GRC tools such as CISO Assistant (AGPL-3.0-only) can hold metric definitions and audit records alongside framework mappings, but confirm its metric and reporting features against your requirements before adopting it.

Questions buyers ask about GV.OV-03 cost, effort and outside help

How much effort does GV.OV-03 take to implement?

The effort depends on how many performance measures leadership already tracks and how well those measures connect to the cybersecurity risk management strategy. GV.OV-03 asks the organization to evaluate its cybersecurity risk management performance and decide on adjustments, so the work is mostly defining indicators, collecting data from existing security tools and running a review cycle. NIST publishes three Implementation Examples for this Subcategory, covering key performance indicators (KPIs), key risk indicators (KRIs) and communicating metrics to senior leadership. Ask any partner or internal team to estimate effort by listing each indicator, its data source, its owner and how often leaders will review it. No effort figure is supplied for this topic, so treat any number you hear as unverified until it is tied to that list.

Can we implement GV.OV-03 in-house without outside help?

Yes, many organizations do this internally, since GV.OV-03 is an outcome that the organization owns and NIST does not require any particular tool or provider. The main questions are whether your security team can define KPIs and KRIs that leaders will actually use, and whether your monitoring tools can produce the data without manual work. Outside help is most useful when the metrics need to be built from several systems, when no one in-house has run a metrics program before, or when you need an independent view of whether the indicators are meaningful. Be clear with yourself about which part you are buying: a partner prepares systems, dashboards and evidence, while the organization still decides which risks matter.

What does GV.OV-03 require from senior leadership?

GV.OV-03 requires leadership to review cybersecurity risk management performance and act on what the review shows. In practice, senior leaders must agree which indicators matter, set the thresholds that trigger a decision, and commit time to a recurring review. Without that participation, metrics become reporting that nobody uses, and the Subcategory's outcome is not met. Leadership also decides what happens when an indicator moves outside tolerance, which links GV.OV-03 to the risk appetite and response choices set elsewhere in the GOVERN Function. Before any engagement starts, confirm who will chair the review, who approves the metric set and how adjustments are recorded.

How long does it take to put GV.OV-03 in place?

No supplied duration exists for this Subcategory, so no timeline can be stated here. The time depends on how many indicators you define, how many data sources must be connected, and how quickly leadership agrees on thresholds. Ask any provider for a written schedule with milestones, including when indicator definitions will be approved, when dashboards will be tested with real data and when the first leadership review will take place. A fixed-scope agreement should tie each milestone to a deliverable so you can see progress without relying on estimates. Also ask how many review cycles are included before the engagement closes.

Will an auditor certify GV.OV-03 for us?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. No body can issue a NIST CSF 2.0 certificate for GV.OV-03 or any other Subcategory. An independent assessor can still review your evidence and report on how your measurement practice works, but that report is an assessment, not a certification. If a customer or regulator asks for proof of GV.OV-03, ask them which document they will accept, such as a self-assessment, an independent review report or evidence from a framework that they do certify.

What does an implementation partner do compared with an auditor?

A partner prepares the systems and evidence, while an independent auditor or assessor reviews them and issues any report. For GV.OV-03, a partner might help define KPIs and KRIs, connect data from security tools, build the reporting views and document how the review meets the outcome. The auditor tests whether those controls operate as described and whether the evidence is reliable. The organization remains responsible for its controls and for the decisions taken at each review. Keep these roles separate in your contract so the party that builds the metrics is not the only party that checks them.

What should a fixed-scope quote for GV.OV-03 include?

A useful quote lists the scope in writing before work starts, along with deliverables, timelines and who is responsible for each item. Ask for the indicator list with definitions and owners, the data sources and integrations included, the dashboard or report format, the number of leadership review sessions supported and the evidence package delivered at the end. Confirm which items are one-time, such as setup and documentation, and which recur, such as updates after tool changes or ongoing support under a retainer. Also ask what is excluded, including any work on other NIST CSF Subcategories. Most engagements are fixed-scope, so the written scope is the basis for the quote rather than a rough estimate.

How DeployOpen scopes and prepares GV.OV-03 evidence

DeployOpen works on GV.OV-03 as a fixed-scope implementation project inside your own infrastructure, agreed in writing before work starts. We prepare the metric definitions, dashboards and review records that show your leadership reviews risk management performance, while your organization owns the controls and an independent auditor or assessor issues any report.

How we scope

Agree in writing which GV.OV-03 KPIs and KRIs the engagement will define, build and document.
Confirm which senior leadership forums receive risk metrics and how often they meet.
Record which systems, data sources and frameworks, such as SP 800-53 PM-4 or ISO 27001 clause 9.1, are in scope.

How we build

Configure a self-hosted platform inside your cloud account, data center or air-gapped network to collect metric inputs.
Define KPI and KRI thresholds, owners and calculation methods so each metric can be reproduced by an assessor.
Build leadership reporting views and test them against sample data before any live reporting cycle begins.

How we hand over

Deliver metric definitions, data lineage notes and dashboard configuration as documented, versioned artifacts.
Provide review meeting records templates and a log of metric decisions that shows adjustments to direction.
Document what your staff must run, confirm and retain, so the evidence remains usable after handover.

How we support

Offer ongoing support, upgrades and continuous testing of the reporting platform as a retainer, if you choose.
Review metric performance with your team at the cadence agreed in the written scope.
Help your team prepare evidence packs for an independent assessor, without issuing any attestation ourselves.