When NIST published CSF 2.0 in February 2024 [source: https://csrc.nist.gov/news/2024/the-nist-csf-20-is-here], the headline change was a sixth function: Govern. If you've already mapped your security program to the original five functions — Identify, Protect, Detect, Respond, Recover — your first instinct might be to add a column to your mapping spreadsheet and start filling gaps. Don't. The Govern function describes organizational context, not new controls. Most of what it asks for already lives in your program somewhere.
What the Govern function actually covers
Govern sits above the other five functions. It describes how your organization decides *why* it does security work, not just what it does. The six categories under Govern are:
- GV.OC — Organizational Context: business objectives, legal and regulatory requirements, stakeholder expectations
- GV.RM — Risk Management Strategy: risk appetite, tolerance, and the decisions that flow from them
- GV.RR — Roles, Responsibilities, and Authorities: who owns what, from the board down to the ops team
- GV.PO — Policy: security policies exist, are communicated, and are enforced
- GV.OV — Oversight: senior leadership reviews the cybersecurity risk posture on a documented schedule
- GV.SC — Cybersecurity Supply Chain Risk Management: vendor and supplier risk treated as part of security strategy
Where your CSF 1.1 mapping already satisfies Govern
If you ran a CSF 1.1 program seriously, several Govern categories are already covered without being labeled that way.
GV.PO (Policy) maps almost directly to PR.IP-1 from version 1.1, which required baseline configuration policies and a documented policy update process. If your organization had a security policy set reviewed on a regular cadence with named owners, GV.PO is largely satisfied. Pull those documents and verify current ownership. GV.RR (Roles and Responsibilities) is a close sibling of ID.AM-6, which covered cybersecurity roles for the entire workforce including third parties. Organizations that completed SOC 2 readiness typically have this in their RACI matrix and onboarding training records. Map it directly. GV.RM (Risk Management Strategy) lived inside ID.RM in version 1.1. If you have a risk register and a documented risk appetite statement approved by leadership, you are most of the way there. CSF 2.0 makes explicit what 1.1 only implied: risk tolerance must be formally approved [source: https://www.saltycloud.com/blog/how-to-conduct-a-nist-csf-2-0-risk-assessment-step-by-step-guide-for-2025/], not inferred from the controls you chose not to implement. GV.OC (Organizational Context) is the one category that is genuinely new in scope. Version 1.1 had nothing that explicitly asked you to document the relationship between your security program and business objectives. If your security roadmap doesn't reference the company's risk appetite, regulatory obligations, and key stakeholder expectations in a single artifact, this is a real gap.The actual gaps most programs have
Once you work through the mapping, three Govern gaps show up most consistently.
Leadership oversight is informal. GV.OV requires that senior leadership regularly reviews the cybersecurity risk posture and that these reviews are documented. In many organizations, the security team presents to the board once a year, but there's no output — no decision record, no follow-up action item list, no evidence that review influenced program direction. That's a briefing, not oversight. Fix it by producing a short written summary after each review, even a single page, with the risk items surfaced and any decisions made. Risk appetite isn't written down. Risk appetite statements that are formally documented and board-approved are rarer than they should be [source: https://blog.gradum.io/blog/nist-csf-20-implementation-tiers-roadmap-step-by-step-guide-from-partial-to-adaptive-cybersecurity-maturity]. Many organizations make risk decisions implicitly — the security team remediates based on severity scores without a formal statement of what risk levels leadership has accepted. GV.RM asks for explicit parameters. A concise statement covering acceptable risk tolerance by category (availability, confidentiality, integrity) is usually enough to close this gap. Supply chain risk is operational, not governed. GV.SC goes further than the vendor risk management most programs practice. Version 1.1 covered supplier risk inside ID.SC primarily as an operational activity — do contracts exist, are they reviewed. CSF 2.0 expects cybersecurity supply chain risk to be treated as a component of strategic risk, visible to leadership and connected to your overall risk management decisions. If your third-party risk program runs in isolation from the risk committee, it doesn't satisfy GV.SC.How to approach the mapping without rebuilding what you have
If you're updating an existing program, the practical path is straightforward.
First, extract your existing artifacts: risk appetite statement if it exists, policy set, RACI, vendor risk tier list, board presentation decks from the past year.
Second, map each artifact to the relevant GV category. For each one, note whether the artifact exists, whether it's current (reviewed in the last year), and whether leadership formally approved it. This is the key question GV.RM and GV.OV hinge on.
Third, distinguish documentation gaps from program gaps. Most of the time, the activity exists — you just haven't captured it in a form an assessor could point to. Oversight meetings happen; they don't produce written outputs. Vendor risk reviews happen; they don't feed into a leadership-visible risk summary. These are documentation problems, not program problems.
Fourth, close the explicit gaps. GV.OC will likely require a new artifact: a short statement tying your security program to your business environment, regulatory obligations, and stakeholder expectations. Two to three pages is sufficient. This becomes the anchor document that contextualizes your entire CSF mapping.
Fifth, update your CSF profile. CSF 2.0 introduced profiles more formally [source: https://www.saltycloud.com/blog/nist-csf-2-0-complete-guide-2026/] than version 1.1 did. A current-state profile and a target-state profile for the Govern function gives you a documented gap-closure roadmap — one that satisfies both the letter and the intent of the framework update.
For a mature program, this exercise typically takes a few weeks of part-time effort, not a multi-month rebuild.
What assessors will look for next
If you use CSF alignment as part of a broader compliance story — for a cyber insurance application, a customer security questionnaire, or a regulatory submission — the Govern function will get more attention as assessors update their question sets to reflect CSF 2.0.
Expect questions like: Does leadership review the cybersecurity risk posture on a documented schedule? Is there a written risk appetite statement? How does supply chain risk get reported to senior leadership? These have straightforward answers for organizations that have done the mapping work. They expose thin spots quickly in organizations that haven't.
The distinction matters: an assessor who sees a documented quarterly risk review with a written output will score that differently from an organization that can only point to an annual board presentation with no follow-up artifact. The controls can be identical. The evidence posture is not.
Govern gaps are mostly documentation and formalization work, not new security investment. CloudAnzen continuously maps your control evidence to frameworks including NIST CSF 2.0, making Govern artifacts visible and audit-ready before someone asks for them. Talk to us.