GV.OV-02 Strategy coverage reviewed: evidence and audit

How NIST CSF 2.0 GV.OV-02 tests whether the strategy still fits

GV.OV-02 asks leaders to check, on a set schedule and after notable events, that the cybersecurity risk management strategy still covers the organization's requirements and risks, and to adjust it where it does not. It is one of three Subcategories in the Oversight (GV.OV) Category of the Govern Function, and it is new in CSF 2.0: the Govern Function itself was added to the five Functions of earlier versions, and the Transition Changes spreadsheet from NIST flags GV.OV-02 as having no clear counterpart in any CSF 1.1 Category or Subcategory. The risk it addresses is drift. A strategy written two years ago can quietly stop matching the contracts, regulations and customer commitments the organization now carries, or it can keep assuming controls that a recent incident showed do not work. If you are the leader who signed that strategy, GV.OV-02 is the outcome that asks whether it still holds.

The difficulty is usually structural rather than intellectual. Most organizations have no defined review trigger, so the strategy is revisited only when someone remembers, and the inputs that would reveal a gap sit in different places: audit findings with the internal audit team, role and performance observations with HR and line managers, and lessons from incidents in the response team's post-incident records. None of these sources is wrong, but no single person is assigned to read them together against the strategy. The result is that a finding that a control is missing from the contract requirements, or that an incident exposed a gap in supplier oversight, may never reach the strategy document at all.

Which strategy inputs, teams and third parties fall in scope for GV.OV-02

GV.OV-02 asks whether the cybersecurity risk management strategy still covers the organization's requirements and risks. The scope you set for that check decides which documents, audit results, roles, incidents and third parties the review must read, and that scope usually changes the work more than the review meeting itself.

Strategy documents under review

Decide which documents count as the strategy: the cybersecurity risk management strategy itself, the policies and risk appetite statements that sit under it, and any standards it adopts. Record the version and approval date of each so the review compares the current text against the requirements it must cover. Confirm who owns each document and whether business unit or regional variants also need to be checked against the central strategy.

Internal audit findings

Internal audit reports are a primary input for GV.OV-02 because the Implementation Examples ask whether findings confirm compliance with internal and external requirements. List every open and closed finding from the period, tag those that point to a gap in the strategy rather than a failed control, and decide how far back the review looks. Ask internal audit to confirm which findings were accepted, deferred or remediated.

External and contractual audit inputs

Include external examinations, regulator findings, customer security questionnaires and contractual audit rights in the same review. These sources often name requirements the strategy never addressed, such as a customer clause on incident notice or a regulator's expectation on third-party oversight. Map each requirement to a strategy section, and mark any with no matching section as a coverage gap for the next revision.

Cybersecurity roles under oversight

The Implementation Example for performance oversight asks whether policy should change based on how people in cybersecurity roles perform. Name the roles in scope, such as the CISO, security operations leads, system owners and the staff who run access reviews, and define what evidence of performance the review receives. Confirm whether staffing gaps, unfilled roles or training shortfalls are reported to the people who can change the strategy.

Incidents that trigger a strategy review

Set written criteria for which incidents require a look at the strategy, such as an incident that bypassed an assumed control, a ransomware event affecting a key service, or a repeat root cause across teams. The Implementation Example for reviewing strategy after incidents expects this link. Confirm with incident response leads which post-incident reports reach the review, and whether near misses and tabletop exercise results count.

Suppliers and cloud services

Decide whether suppliers, managed service providers and cloud platforms create requirements the strategy must cover, such as shared responsibility for logging or data residency obligations written into contracts. Compare each third party's contractual security duties against the strategy's supplier sections. Ask procurement which contracts changed in the period, because those changes often introduce requirements no one added to the strategy.

How an assessor tests strategy coverage review

This table compares the test approach, evidence requested and common findings for each part of GV.OV-02, so readers can see what an independent assessor looks for. It describes how the test is usually approached, not how any specific assessor will work, and the main takeaway is that a review only counts if its output is traceable to a strategy decision.

Assessor activity	What the assessor checks	Evidence requested	Common finding
Strategy against requirements and risks	Whether the stated cybersecurity risk management strategy addresses the organization's legal, regulatory and contractual requirements and its identified risks, checked against a requirement inventory the organization maintains	Current strategy document, dated requirement inventory, risk register extract and the review record showing who checked coverage and when	Strategy reviewed on paper but the requirement inventory is older than the strategy or misses newer obligations
Audit findings traced to strategy	Whether findings from internal and external audits were used to confirm the strategy meets internal and external requirements, and whether gaps led to changes	Sample of audit findings, the remediation tickets or decision records they produced, and the strategy revisions that followed	Findings are logged and closed, but no record shows whether any finding changed the strategy
Oversight of cybersecurity roles	Whether leaders reviewed how people in cybersecurity roles perform and used that review to decide if policy or strategy should change	Oversight meeting minutes, performance review summaries for security roles and any recorded decision on policy or strategy	Performance is discussed in meetings, but minutes record no decision and no follow-up
Post-incident strategy review	Whether significant incidents triggered a review of strategy, and whether lessons were carried into strategy or policy updates	Post-incident review reports, action lists, and the strategy or policy versions that changed after each incident	Post-incident reports exist, but no record links an incident to a strategy decision
Review that changed nothing	Whether the review process produces any documented outcome, including a decision to keep the strategy unchanged with stated reasons	Review records with recorded outcomes, rationale for no-change decisions and the date of the next scheduled review	Reviews are held on schedule, but every record reads as no change with no rationale
Ownership and cadence	Whether the review has a named owner, a defined cadence and a path to the people who approve strategy changes	Assigned owner, approval records, review calendar and terms of reference for the oversight body	Owner is named in a policy but the review has no calendar entries or approval trail

What audit findings, role oversight and incidents each prove about strategy coverage

GV.OV-02 asks whether the cybersecurity risk management strategy still covers what the organization must meet and the risks it faces. NIST's Implementation Examples point to three evidence streams that answer that question, and each one exposes a different kind of gap. The first is audit findings. Reviewers should confirm that the findings from internal audits, external assessments and regulator or customer reviews map to requirements the strategy actually addresses. A finding that cites a requirement with no owner, objective or funded activity in the strategy is evidence of a missing requirement, and the review should record which requirements are absent and why.

The second stream is performance oversight of people in cybersecurity roles. The question here is whether the people accountable for the strategy can do what it assumes, and whether the policy still describes who decides what. Gaps in this stream look like unclear accountability: duties that two roles both believe belong to the other, approvals that bypass the named owner, or training and staffing that the strategy never accounted for. Confirm with each role holder which decisions they make in practice and compare that with the documented authorities. The review then has to decide whether the policy should change to match reality or whether the staffing and accountability need to change.

The third stream is incidents. After a significant event, the review should test each assumption the strategy made about that scenario, such as detection coverage, escalation paths, recovery priorities and supplier dependencies. An incident that the strategy did not anticipate shows untested assumptions, and one that the strategy anticipated but mishandled points to a gap between documented intent and operation. Every review must end with a recorded decision, including a decision to keep the strategy unchanged. A dated record showing that audit, role and incident evidence was examined and that the strategy stands is what an assessor can test. An undocumented 'no change' cannot be distinguished from a review that never happened.

Implementing a strategy coverage review cycle, step by step

This sequence turns GV.OV-02 into a repeatable review that checks whether the cybersecurity risk management strategy still covers the organization's requirements and risks, and records every decision to keep or change it.

Define the review trigger and cadence
The accountable executive, usually the CISO working with the governing body, sets the scheduled review interval and the event triggers that force an earlier review, such as a significant incident, a new contractual or regulatory requirement, or an audit finding that exposes a gap. Confirm the cadence with the leadership group that owns the strategy. The step is complete when a written review charter names the owner, the triggers and the date of the next scheduled review, and that charter is filed with the strategy document.
Assemble the requirements and risk inventory
Gather the current list of obligations the organization must meet, including legal, regulatory and contractual requirements, and the cybersecurity risk register that describes the threats and risk scenarios the strategy is meant to address. Pull the requirements from the Organizational Context and Risk Management Strategy records so the review compares the strategy against the same baseline leaders approved. The output is a dated requirements and risk inventory with an owner and version number, which becomes the reference set for every later comparison.
Collect audit findings and incident reviews
Compile open and closed findings from internal audits, external assessments and regulator or customer reviews, along with the post-incident reviews from the period under examination. Tag each item by the strategy area it touches, such as governance, risk appetite, supplier risk or response planning. Where a finding points to a requirement the strategy never addressed, mark it as a candidate gap. The output is a finding and lessons log that links each item to its source report or incident record, so the reviewer can trace every gap back to evidence.
Review role oversight records
Examine the records showing how people in cybersecurity roles performed against their responsibilities, including performance reviews, training completion, staffing gaps and escalations that were not handled as the policy intended. The question is whether the strategy assigns work to roles that have the capacity and skills to deliver it, and whether recurring performance problems point to a policy that needs to change. The output is a short role oversight summary attached to the review file, with each issue marked as either a strategy gap or an execution problem.
Compare coverage and record gaps
Map each requirement and risk from the inventory to the strategy sections that address it, then note every requirement or risk left uncovered, weakly covered or addressed by a strategy statement that no longer matches current operations. Add the candidate gaps from the audit, incident and role reviews. The reviewer signs off the comparison when every inventory item has a coverage status. The output is a dated coverage review record with one row per requirement or risk, its coverage status and the evidence used.
Decide and document changes or justified no-change decisions
For each gap, the decision owner chooses to amend the strategy, adjust a policy or process, accept the residual risk with a stated rationale, or defer the decision with an owner. Every no-change decision needs a written reason, because an unexplained decision to keep the strategy is the main thing an assessor will question. Approvals come from the people who hold authority over the strategy. The output is a change log entry for each decision, linked to the coverage review record and the approval of record.
Communicate outcomes to leadership
Send a summary of the coverage review, the gaps found, the decisions taken and the open items to the executives and governing body responsible for the strategy, and record their acknowledgment. Confirm with your leadership and governance teams which format and level of detail they expect. The step closes when the summary, the change log and the minutes or acknowledgment are stored together, so the next review can start from the agreed baseline.

Evidence that shows a strategy coverage review happened and changed what it should

An assessor testing GV.OV-02 wants to see that the review took place, what it compared the strategy against, and what changed as a result. The six artifacts below link those three points, and each needs a named owner and a standing calendar so the record stays current between audits.

Dated review minutes and sign-off

Minutes from each strategy review, showing the date, attendees, the decisions taken and a named approver who signed off the outcome. Set a standing review calendar with a fixed owner who schedules the meeting and circulates the pre-read at least one cycle ahead. Undated or unsigned minutes are weak evidence, because an assessor cannot tell whether the review happened before or after an audit or incident. Check that the approver has the authority to set cybersecurity strategy.

Requirements and risk inventory

The register of legal, regulatory, contractual and business requirements, together with the risks the strategy is meant to address, is the baseline the review compares against. Record the version and date of each input the review used, and assign one owner per source, such as legal for regulations and the risk function for the risk register. Without this baseline, a review can confirm that the strategy is internally consistent but not that it covers what the organization must meet.

Strategy version history with change rationale

A version log of the cybersecurity risk management strategy, where each change records what was altered, why, who approved it and which input triggered it. A gap between a review date and the next version date is useful evidence only if the log shows that the review concluded with no change. Keep the log in the same controlled repository as the policy documents, so that prior versions cannot be overwritten silently.

Audit findings and their disposition

Internal and external audit findings that touch the strategy, each with its disposition: accepted, mitigated, transferred, or closed with a stated reason. NIST's first Implementation Example for GV.OV-02 is reviewing audit findings to confirm compliance with internal and external requirements. Confirm that each finding that points to a strategy gap has a linked strategy change or a documented risk acceptance, and that the review minutes refer to it by identifier.

Role oversight and performance review records

Records from oversight of people in cybersecurity roles, such as performance reviews, staffing gap assessments and training completion, showing whether the strategy's assumptions about people still hold. NIST's second Implementation Example asks whether performance oversight suggests the policy should change. Keep these records in the HR or GRC system with the review date, the finding and the decision, and ensure the cybersecurity lead receives them before each strategy review.

Post-incident strategy reviews

Short reviews held after significant incidents that ask whether the strategy's coverage, priorities or risk responses failed in practice. NIST's third Implementation Example covers reviewing strategy after incidents. Each review should record the incident reference, the strategy clauses examined and any change made or deliberately not made. Assign the incident commander or post-incident lead as the owner of the trigger, so that the review starts within a set period after closure rather than being forgotten.

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

This table lists each cost component of running a GV.OV-02 strategy coverage review, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since no fixed figures are published for this Subcategory. The main takeaway is that open-source tooling removes license spend but not the internal time needed to review, decide and document.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Inventory of requirement sources and review cadence	Internal GRC lead, with outside help if a readiness partner is engaged	One-time setup, then periodic updates	Number of requirement sources and audit programs in scope; ask the quote to list each one
Leadership and analyst time for each strategy review	Executives, risk owners and security analysts	Recurring, once per review cycle	Number of audit findings, incidents and open exceptions to consider; ask how many review cycles are included
Review of cybersecurity role performance	Security managers and HR or workforce owners	Recurring, each review cycle	Number of cybersecurity roles and staffing changes; ask whether role reviews are scoped separately
Post-incident strategy reviews	Incident responders, leadership and the GRC owner	Recurring, driven by incidents	Incident volume and severity; a quiet year costs less than one with major events
Tooling and licenses for the GRC record	Software vendor for commercial GRC; none for self-hosted open source	Commercial licenses recur; open-source license cost is typically zero but hosting is not	Commercial seat counts and modules versus self-hosted platform; confirm the license terms of any platform before adopting it
Engineering time to produce and export evidence	Platform or security engineers, or an implementation partner under a fixed-scope agreement	Setup one-time, exports recurring	Degree of automation in the GRC record and the number of systems feeding it; ask what is delivered as working automation
Staffing and upkeep for self-hosted tooling	Internal platform team or a retained support partner	Recurring	Upgrades, backups, access control and hosting; self-hosted open source removes license spend, but these upkeep costs remain
External readiness review or independent assessment	Outside consultant for readiness; independent auditor or assessor for any formal assessment	Usually one-time per assessment cycle	Scope of the assessment and whether the framework is used for certification or only alignment; NIST does not offer certification
Auditor sampling effort	Internal staff who produce samples, plus the independent auditor	Recurring, each audit cycle	Number of review records the auditor samples; well-kept dated minutes and findings logs reduce sampling effort

How CISO Assistant can hold the strategy review evidence

CISO Assistant can act as the single place where GV.OV-02 evidence is kept, provided the organization configures it that way. The project is licensed under AGPL-3.0-only and, according to its README, ships more than 200 frameworks, including NIST CSF, ISO 27001, SOC 2, PCI DSS, NIS2, DORA and GDPR, and runs audits and compliance assessments against them with automatic mapping between frameworks. For this Subcategory, that means the CSF 2.0 requirement inventory, the ISO/IEC 27001:2022 clause and Annex A references, and the SP 800-53 Rev. 5.2.0 and SP 800-171 Rev. 3 mappings can sit in one tool, so a reviewer sees the same strategy-coverage question from each framework's angle. Before relying on this, confirm in the README which frameworks, mapping sets and assessment features your version includes, because the mapping content may differ from the NIST Reference Tool export.

For the review itself, the practical job is to hold three record types: the list of requirements and risks the strategy must cover, the dated records of each strategy review, and the audit findings, people-in-role oversight notes and post-incident lessons that prompt a change. Store each review as an assessment or audit object linked to the requirements it tested, and record the decision taken, such as no change, a policy revision or a new risk owner. Ask your implementation partner to confirm how attachments, comments, owners and review dates are modeled in your installed version, and whether an export is available for the auditor. Keep the record of what leaders decided separate from the tool's own findings, since the tool shows coverage but does not judge whether the strategy is sound.

CISO Assistant does not decide strategy, set risk appetite or determine whether a requirement is met. Those decisions stay with the accountable executives, and an independent auditor or certification body, not the software or its vendor, forms any conclusion on conformity. Treat the tool as the record of the review rather than the review. Because the license is AGPL-3.0-only, an organization that modifies the software and makes it available to users over a network should take advice from counsel on its source disclosure duties, and should also confirm the obligations that apply to self-hosting and internal use before deployment. Your counsel and the project's license text, not this page, should settle those questions.

Who owns the strategy review, who prepares the evidence and who audits it

Your leadership owns the strategy and the decision to change it. GV.OV-02 asks whether the cybersecurity risk management strategy still covers your requirements and risks, so the people accountable for that strategy must be the ones who review it, weigh audit findings, examine how cybersecurity roles are performing and decide what changes. Those decisions, and the reasons behind them, are the record an assessor will read first.

Strategy decisions: Leadership decides whether the strategy covers current legal, regulatory and contractual requirements and risks, and records the adjustments it approves.
Audit finding responses: Accountable owners decide how each finding affects the strategy and set dates for remediation.
Role performance judgments: Managers review whether cybersecurity roles are working and whether policy should change.
Incident lessons: The incident review group decides which lessons change the strategy, not only the runbooks.
Retained minutes and approvals: Your own governance records, signed or approved by named individuals, show that the review actually happened.

Before engaging anyone, confirm with your board or executive committee who holds the approval authority for the strategy and whether that authority is written into a charter or policy.

Where organizations fall short on strategy coverage and how to close each gap

GV.OV-02 asks whether the cybersecurity risk management strategy still covers the organization's requirements and risks. The gaps below share one root cause: the strategy is reviewed informally, if at all, and the inputs that should drive a change never reach the people who own the strategy.

No defined review trigger

Many strategies are reviewed on the calendar or when someone remembers, so changes in regulation, contracts, systems or threats are absorbed late or not at all. Write down the events that force a review, such as a new contractual security requirement, a material system change, a new regulatory obligation or a significant incident. Check whether each trigger has a named owner and a due date for the review it starts.

Requirements nobody has inventoried

A strategy that cites laws, customer contracts and frameworks without a maintained list of them cannot show coverage. Ask the strategy owner for the register of applicable requirements, with each entry linked to the strategy section that addresses it. Where a requirement has no owner or no section, treat that as a coverage gap to be closed before the next review.

Audit findings that stop short

Internal audit, external assessment and regulator findings often land with the control owner but never reach the person who approves the strategy. Route every finding that concerns policy, scope or risk appetite to the strategy owner, and record how each one changed or did not change the strategy. This is the step NIST's Implementation Examples for GV.OV-02 describe as confirming compliance with internal and external requirements.

Role oversight kept in HR files

Performance reviews for security staff can show that roles are underperforming, understaffed or unclear, yet those findings usually stay in personnel records. Bring aggregate observations, such as recurring unfilled duties or repeated escalations missed, into the strategy review and ask whether policy or role design should change. Keep individual performance data out of the strategy paper and report only the patterns.

Incident lessons not acted on

Post-incident reports often list lessons but do not change the strategy, so the same gap reappears in the next event. After each significant incident, ask whether the strategy's assumptions, risk tolerances or priorities were wrong, and record the answer. Track each lesson to a decision and a revised strategy section, so reviewers can see that incidents shaped direction.

Reviews without recorded decisions

A review meeting that ends with no written outcome gives assessors nothing to test and leaves the next review starting from zero. Record each review's inputs, the coverage gaps found, the decision taken for each gap (change, accept or defer), the approver and the date. An auditor reviewing GV.OV-02 will look for this decision trail, so keep it in the same place as the strategy document.

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

How much effort does a first GV.OV-02 strategy coverage review take?

The effort depends on how many requirements and risks the strategy must cover, how many audit reports and incident reviews feed the review, and how much of the evidence already exists in one place. A first review is usually heavier than later ones because the team must build the baseline: a list of internal and external requirements, a register of open audit findings, and a record of what changed after recent incidents. No duration figure has been published for this work, so ask any partner to show the expected effort by activity in the written scope. Ask the partner to estimate the hours for collecting inputs, mapping them to the strategy, and drafting the decisions for leadership.

Can our own team run the GV.OV-02 coverage review without outside help?

Yes, many organizations run this review in-house, because the work is mainly document review and decision-making rather than technical testing. The team needs someone who owns the cybersecurity strategy, someone who holds the audit findings, and someone who tracks incidents and the performance of people in cybersecurity roles. Outside help is most useful when the requirement set is large, when several frameworks apply at once, or when no one has run a structured review before. An implementation partner can prepare the inputs and evidence, but the organization must still own the strategy and the decisions it records.

What does leadership have to provide for a coverage review?

Leadership has to accept accountability for the strategy and make the decisions the review produces. In practice this means:

Naming an executive owner who can approve changes to the strategy.
Making time for the people who run audits, incident response and cybersecurity roles to feed their findings into the review.
Agreeing in advance what counts as a coverage gap and how the organization will respond to it, such as accepting the risk, funding a fix or changing the target.
Confirming that the review output goes to the people who approve budgets and priorities.

Without these decisions, the review produces a list of gaps with no path to closing them.

Does NIST certify GV.OV-02 or any other CSF 2.0 Subcategory?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. The CSF is voluntary for most organizations, so there is no NIST certificate to buy for GV.OV-02. Some customers or regulators may ask for evidence that you follow the CSF, and in that case the evidence is your own documented review, its outputs and its follow-up. If a third party is asked to assess your alignment, that assessment is an independent report from the assessor, not a NIST certification. Confirm with the requesting customer or regulator what form of evidence they accept.

How long does setting up the GV.OV-02 review process take?

Setup time depends on how mature the existing governance is, how many internal and external requirements apply, and how many systems hold the evidence. Organizations that already keep an audit findings register and an incident review process usually need less setup than those that build both from scratch. No timeline has been supplied for this work, so ask for a timeline with the quote, showing when inputs are collected, when the first review meets leadership, and what is handed over at the end. Fixed-scope engagements begin only after the scope, deliverables and timeline are agreed in writing.

What should we ask a partner to include in a written GV.OV-02 scope?

A written scope should state what the partner will prepare and what the organization must own. Ask for:

The list of inputs the review covers, including audit findings, reviews of performance oversight for cybersecurity roles, and post-incident reviews.
The requirements and risks the strategy must be checked against, and who confirms the list.
The evidence the partner will prepare, in what format, and where it will be stored.
The meetings with leadership, the decisions expected from them, and who records those decisions.
The deliverables, the timeline and the acceptance criteria.
What the partner will not do, such as issuing an assessment report or certification.

DeployOpen plans and implements systems and prepares evidence for compliance assessments. Independent auditors and certification bodies issue reports and certificates, so the scope should keep those roles separate.

How DeployOpen scopes and prepares GV.OV-02 evidence

DeployOpen works on GV.OV-02 by preparing the systems and records that show your cybersecurity strategy is checked against your requirements, risks, audit findings, role oversight and incident lessons. Your organization owns the strategy and the review decisions, and an independent assessor is the party who judges the evidence.

How we scope

Agree in writing which review inputs are in scope: audit findings, role oversight records and incident lessons.
Confirm which internal and external requirements the strategy must be checked against for this engagement.
Define the platforms, data sources and owners involved, with deliverables and timelines fixed before work starts.

How we build

Configure self-hosted open-source GRC tooling inside your own infrastructure to record strategy review cycles.
Map each review input to the GV.OV-02 outcome and its Implementation Examples in a traceable register.
Test that review records, decisions and follow-up actions are captured consistently before handover.

How we hand over

Deliver documented procedures, review templates and an evidence index showing where each record is kept.
Provide a walkthrough so your owners can run a strategy coverage review and produce the records themselves.
Hand over administration access and runbooks so your team keeps the tooling and evidence under its own control.

How we support

Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
Retainers can cover updates to the review register when audit findings, incidents or requirements change.
Ask an independent auditor or certification body to confirm which evidence they will accept before the review cycle begins.