Last updated:
Guide · Security governance
NIST CSF 2.0's Govern Function: What Changed and How Security Managers Should Apply It
NIST CSF 2.0 makes Govern an explicit sixth Function. Govern is not a first step that an organization completes before the others; it establishes the organizational context, risk strategy, roles, policy, oversight, and supply-chain expectations that inform Identify, Protect, Detect, Respond, and Recover.
For a security manager, the new top-level placement matters because governance decisions must be visible enough to guide priorities, assign authority, justify exceptions, challenge performance, and resolve third-party risk throughout the security programme.
Primary source: NIST Cybersecurity Framework (CSF) 2.0
CertArc interpretation
Relationship, not sequence
Govern
Organizational context, risk strategy, authority, policy, oversight, and supply-chain expectations inform the other Functions.
- Identify
- Protect
- Detect
- Respond
- Recover
What changed from CSF 1.1?
CSF 2.0 gives governance its own top-level Function. In CSF 1.1, governance-related categories sat inside Identify: Business Environment (ID.BE), Governance (ID.GV), Risk Management Strategy (ID.RM), and Supply Chain Risk Management (ID.SC). CSF 2.0 reorganizes and expands that material so governance is visible across the whole Core.
This does not mean that every Govern outcome is wholly new. The accurate change is elevation, reorganization, and additional emphasis: Organizational Context draws on the former Business Environment material; risk strategy, roles, policy, and oversight make governance decisions explicit; and supply-chain risk management now sits within Govern.
Why are the six Functions not six sequential steps?
NIST says the Functions should be addressed concurrently. Their order and visual size do not establish a sequence or level of importance. An organization may discover a new dependency in Identify, change a policy through Govern, strengthen a safeguard in Protect, and adjust response authority after an incident at the same time.
Govern informs the other five Functions because context and decision rights shape what the organization considers important, proportionate, reportable, and recoverable. The flow also works back into governance: operational evidence can reveal that strategy, policy, authority, or oversight needs to change.
What does each Govern category require managers to decide?
The category summaries come from NIST CSF 2.0. The management questions, typical owners, evidence, triggers, and failure modes are CertArc interpretation, not prescribed NIST roles or documents.
GV.OC · Organizational Context
Cybersecurity decisions reflect the mission, stakeholders, dependencies, and legal, regulatory, and contractual requirements.
GV.RM · Risk Management Strategy
Cybersecurity priorities, constraints, appetite, tolerance, and assumptions guide consistent risk decisions.
GV.RR · Roles, Responsibilities, and Authorities
Cybersecurity responsibilities and decision authority are established, communicated, understood, and enforced.
GV.PO · Policy
Cybersecurity policy is established, communicated, enforced, and adjusted to organizational context and risk strategy.
GV.OV · Oversight
Cybersecurity performance and risk-management results inform timely adjustments to strategy and direction.
GV.SC · Cybersecurity Supply Chain Risk Management
Cybersecurity supply-chain risk is governed across supplier selection, agreements, monitoring, change, and exit.
Actual accountability depends on the organization's governance model, delegated authority, legal obligations, and risk structure.
| Govern outcome | Management question | Typical accountable owner | Evidence to retain | Review trigger | Common failure mode |
|---|---|---|---|---|---|
| GV.OC · Organizational ContextCybersecurity decisions reflect the mission, stakeholders, dependencies, and legal, regulatory, and contractual requirements. | Which services and stakeholder expectations make cybersecurity risk material to this organization? | Executive leadership with enterprise risk, legal, compliance, and business-service owners. | Critical-service maps, stakeholder and obligation registers, dependency records, and approved context assumptions. | A new market, acquisition, major service, regulation, contract, or dependency changes the business context. | The security programme inherits a generic control list without a shared view of mission-critical outcomes. |
| GV.RM · Risk Management StrategyCybersecurity priorities, constraints, appetite, tolerance, and assumptions guide consistent risk decisions. | What risk can the organization accept, who can accept it, and what must be escalated? | Enterprise risk leadership and executives, with the security leader advising on cybersecurity exposure. | Approved risk appetite and tolerance statements, assessment criteria, treatment rules, escalation thresholds, and material risk decisions. | Loss events, threat change, strategy change, repeated exceptions, or risk decisions that conflict across business units. | Teams score risks but lack a decision rule connecting scores to authority, treatment, or escalation. |
| GV.RR · Roles, Responsibilities, and AuthoritiesCybersecurity responsibilities and decision authority are established, communicated, understood, and enforced. | Who owns the business risk, who advises, who executes, and who can approve an exception? | Executive leadership and business owners, supported by security, risk, HR, legal, and governance bodies. | Charters, delegations, role descriptions, committee terms, RACI records, escalation paths, and exception approvals. | Reorganization, leadership change, outsourcing, recurring decision delay, or an incident exposes ambiguous authority. | Security is made accountable for business risks it can advise on but cannot accept or fund. |
| GV.PO · PolicyCybersecurity policy is established, communicated, enforced, and adjusted to organizational context and risk strategy. | Which expectations must be mandatory, where can exceptions exist, and how are they approved? | The authority designated by the governance model, with security drafting and affected functions implementing. | Approved policies, ownership and version history, communication records, exception decisions, and enforcement evidence. | Technology, threat, obligation, business-process, or exception-pattern change makes policy inaccurate or impractical. | Policy becomes a static document library disconnected from risk decisions, operations, and enforceable authority. |
| GV.OV · OversightCybersecurity performance and risk-management results inform timely adjustments to strategy and direction. | What must leaders know to judge whether cybersecurity risk is within direction and whether decisions are working? | Board or executive oversight bodies, with management and risk functions preparing decision-useful evidence. | Oversight agendas and minutes, risk and performance reports, challenge records, decisions, actions, owners, and due dates. | Material incidents, missed objectives, unexplained trends, repeated overdue actions, or a change in risk exposure. | Reporting counts activity but does not show exposure, decision quality, unresolved ownership, or required action. |
| GV.SC · Cybersecurity Supply Chain Risk ManagementCybersecurity supply-chain risk is governed across supplier selection, agreements, monitoring, change, and exit. | Which suppliers can materially affect critical outcomes, and who owns risk decisions throughout their lifecycle? | Business service owner and procurement, supported by security, legal, privacy, resilience, and enterprise risk. | Supplier criticality criteria, due-diligence decisions, security requirements, contractual obligations, monitoring results, exceptions, and exit plans. | New critical supplier, material service change, concentration risk, contract renewal, adverse event, or termination. | A point-in-time questionnaire substitutes for lifecycle ownership, contractual clarity, and ongoing risk decisions. |
GV.OC · Organizational Context
Cybersecurity decisions reflect the mission, stakeholders, dependencies, and legal, regulatory, and contractual requirements.
Management question
Which services and stakeholder expectations make cybersecurity risk material to this organization?
Typical accountable owner
Executive leadership with enterprise risk, legal, compliance, and business-service owners.
Evidence to retain
Critical-service maps, stakeholder and obligation registers, dependency records, and approved context assumptions.
Review trigger
A new market, acquisition, major service, regulation, contract, or dependency changes the business context.
Common failure mode
The security programme inherits a generic control list without a shared view of mission-critical outcomes.
GV.RM · Risk Management Strategy
Cybersecurity priorities, constraints, appetite, tolerance, and assumptions guide consistent risk decisions.
Management question
What risk can the organization accept, who can accept it, and what must be escalated?
Typical accountable owner
Enterprise risk leadership and executives, with the security leader advising on cybersecurity exposure.
Evidence to retain
Approved risk appetite and tolerance statements, assessment criteria, treatment rules, escalation thresholds, and material risk decisions.
Review trigger
Loss events, threat change, strategy change, repeated exceptions, or risk decisions that conflict across business units.
Common failure mode
Teams score risks but lack a decision rule connecting scores to authority, treatment, or escalation.
GV.RR · Roles, Responsibilities, and Authorities
Cybersecurity responsibilities and decision authority are established, communicated, understood, and enforced.
Management question
Who owns the business risk, who advises, who executes, and who can approve an exception?
Typical accountable owner
Executive leadership and business owners, supported by security, risk, HR, legal, and governance bodies.
Evidence to retain
Charters, delegations, role descriptions, committee terms, RACI records, escalation paths, and exception approvals.
Review trigger
Reorganization, leadership change, outsourcing, recurring decision delay, or an incident exposes ambiguous authority.
Common failure mode
Security is made accountable for business risks it can advise on but cannot accept or fund.
GV.PO · Policy
Cybersecurity policy is established, communicated, enforced, and adjusted to organizational context and risk strategy.
Management question
Which expectations must be mandatory, where can exceptions exist, and how are they approved?
Typical accountable owner
The authority designated by the governance model, with security drafting and affected functions implementing.
Evidence to retain
Approved policies, ownership and version history, communication records, exception decisions, and enforcement evidence.
Review trigger
Technology, threat, obligation, business-process, or exception-pattern change makes policy inaccurate or impractical.
Common failure mode
Policy becomes a static document library disconnected from risk decisions, operations, and enforceable authority.
GV.OV · Oversight
Cybersecurity performance and risk-management results inform timely adjustments to strategy and direction.
Management question
What must leaders know to judge whether cybersecurity risk is within direction and whether decisions are working?
Typical accountable owner
Board or executive oversight bodies, with management and risk functions preparing decision-useful evidence.
Evidence to retain
Oversight agendas and minutes, risk and performance reports, challenge records, decisions, actions, owners, and due dates.
Review trigger
Material incidents, missed objectives, unexplained trends, repeated overdue actions, or a change in risk exposure.
Common failure mode
Reporting counts activity but does not show exposure, decision quality, unresolved ownership, or required action.
GV.SC · Cybersecurity Supply Chain Risk Management
Cybersecurity supply-chain risk is governed across supplier selection, agreements, monitoring, change, and exit.
Management question
Which suppliers can materially affect critical outcomes, and who owns risk decisions throughout their lifecycle?
Typical accountable owner
Business service owner and procurement, supported by security, legal, privacy, resilience, and enterprise risk.
Evidence to retain
Supplier criticality criteria, due-diligence decisions, security requirements, contractual obligations, monitoring results, exceptions, and exit plans.
Review trigger
New critical supplier, material service change, concentration risk, contract renewal, adverse event, or termination.
Common failure mode
A point-in-time questionnaire substitutes for lifecycle ownership, contractual clarity, and ongoing risk decisions.
How is governance evidence different from control-operation evidence?
Governance evidence shows what the organization decided, why it decided it, who had authority, what expectations apply, and how performance is reviewed.
Control-operation evidence shows whether a safeguard or operational process ran and what result it produced.
Governance evidence examples
- approved risk appetite and tolerance
- governance charters and delegations
- policy approvals and exception decisions
- oversight minutes and recorded actions
- supplier requirements and lifecycle decisions
Control-operation evidence examples
- control logs and scan outputs
- tickets and access-review results
- backup and recovery test results
- alert, investigation, and incident records
An artifact can support both purposes. An access-review record, for example, may prove that a control operated and also provide oversight evidence when leaders use its exceptions and trends to change policy or risk treatment. The test is the claim the evidence is meant to support.
How does a missing risk owner weaken every other Function?
Consider a business-critical customer identity service with no clearly accountable risk owner. Security can identify exposure and propose controls, but it cannot unilaterally decide the business impact, accept material risk, fund every treatment, or settle restoration priorities.
- Identify
- cannot settle the service, asset, and risk priority.
- Protect
- cannot resolve proportional control investment or risk acceptance.
- Detect
- lacks agreed thresholds for alert escalation.
- Respond
- lacks authority for business-impacting containment decisions.
- Recover
- faces conflicting restoration priorities.
These are not five unrelated operational defects. The missing owner is a Govern failure that propagates into how the other Functions are prioritized and authorized.
What should a security manager do this quarter?
This checklist is CertArc practical guidance, not a NIST-prescribed implementation order. Use it to make a small set of governance decisions observable and reviewable.
- Confirm the mission, critical services, stakeholders, dependencies, and external obligations used to frame cybersecurity decisions.
- Compare cybersecurity risk appetite and tolerance with current enterprise risk decisions and unresolved exceptions.
- Document material decision rights, escalation paths, and ownership gaps rather than relying on assumed responsibility.
- Check policy against current mission, technology, threat, legal, regulatory, and contractual change.
- Define the oversight questions and evidence leaders need, rather than reporting activity counts alone.
- Identify and prioritize critical suppliers and confirm responsibility across selection, monitoring, change, and exit.
- Choose one current and target Organizational Profile use case to expose outcome gaps and priorities.
- Set review triggers, owners, and dates for unresolved governance decisions.
How is this relevant to security-management judgment?
Govern is conceptually relevant to management responsibilities involving governance, risk ownership, policy, oversight, and third parties. This is not an official NIST-to-CISM mapping. Readers preparing for CISM can compare the workplace decisions here with CertArc's managerial-mindset guide.