GV.RM-01 Risk management objectives agreed: requirements and evidence

What GV.RM-01 requires and why NIST CSF 2.0 Govern starts here

GV.RM-01 asks that your organization sets cybersecurity risk management objectives and that the stakeholders who run the business agree on them. It sits in the Risk Management Strategy Category (GV.RM) of the GOVERN Function in NIST CSF 2.0, and it replaces CSF 1.1 identifier ID.RM-1 under a new number. If an assessor or customer asks you to show GV.RM-01, they want evidence that someone with authority wrote down what the cybersecurity program is trying to achieve, that senior leaders signed off on it, and that the objectives are specific enough to check. NIST's Implementation Examples for this Subcategory add three expectations: objectives are revisited during annual strategic planning and after major changes, they are measurable, and senior leaders use them to manage risk and performance. The source text is in the NIST CSWP 29 PDF, and you should read the Appendix A wording yourself before you draft anything.

The risk this Subcategory addresses is effort with no stated destination. Security teams can spend a full year patching, buying tools and running training without anyone having agreed what success looks like. Objectives that are never written down cannot be measured, objectives that the executive team never agreed do not steer budget, and objectives that are not revisited drift away from the business as systems, suppliers and regulations change. What makes this hard in practice is that the objectives have to be both ambitious enough to matter and concrete enough to test. Statements such as "improve security posture" pass a casual read but fail an assessor's question about how progress is measured. Start by listing the near-term and long-term objectives in your current plan, then mark which ones have a named owner, a measure, a target and a date, and which ones have been approved by the leadership group. The gaps in that list are your GV.RM-01 work.

Because GV.RM-01 is an agreement and a review cycle, most of its evidence is documentary: approved objectives, meeting minutes or decision records showing sign-off, and a dated record of the last revision and the trigger for it. Confirm with your own governance team which committee approves objectives and whether it meets on the planning cycle your framework expects. Organizations often outsource the drafting and facilitation of this work to an advisor, but the objectives, their owners and the approval remain the organization's own decisions, and an independent assessor will test whether those decisions happened. Where a platform holds the objectives and their status, such as a self-hosted GRC tool, confirm how it records approvals and revision history before you rely on it as evidence.

Which objectives, teams and programs fall under GV.RM-01

Before objectives can be agreed, leaders must decide what they cover: which business units and risk domains, whether subsidiaries and shared services are included, how third parties enter the picture, and which planning cycles revisit them. Each decision changes how much work the objectives represent and who must sign off on them.

Business units and risk domains in scope

Decide whether objectives cover the whole enterprise or only the units that run critical services and hold regulated data. A narrow scope is easier to measure but leaves gaps that an assessor will ask about, especially where a unit runs its own systems outside central IT. Write down which units and risk domains are excluded and who accepts that exclusion, so the omission is a recorded decision rather than an oversight.

Subsidiaries and shared services

Subsidiaries and shared services often run systems that the parent depends on. Decide whether objectives set at group level bind each subsidiary, or whether each entity sets its own objectives that roll up to the group. Shared service teams, such as a central identity or hosting team, need objectives that reflect the risk they carry for every unit they serve, not only their own budget line.

Third-party dependencies in the objectives

Objectives that ignore suppliers describe only the systems the organization runs directly. Decide which critical providers, such as hosting, managed security and software suppliers, must be reflected in objectives, and who owns each dependency. Confirm with each provider how it reports performance against objectives, because an objective the organization cannot measure in a supplier's environment will not hold up under review.

Planning cycles that must revisit objectives

The Implementation Examples for GV.RM-01 expect objectives to be updated during annual strategic planning and after major changes. Map the annual budget cycle, board strategy sessions, and triggers such as mergers, a new cloud region or a significant incident to a named owner. Without a defined trigger list, objectives drift from the business plan without anyone recording the change.

Leaders who must agree the scope

Objectives only count when senior leaders agree on them, so the scope decision needs named approvers. Identify the executives and board members who sign off on scope, and the operational leaders who must accept measures for their own areas. Record the approvals with dates so the organization can show who agreed to what, and when that agreement was last renewed.

How an assessor tests GV.RM-01

This table walks through the steps an independent assessor typically takes when testing GV.RM-01, what each step looks for, and the evidence it asks for. Read it as a preparation checklist: each row shows where an organization's records are most often found incomplete. The main takeaway is that an assessor needs written, measurable objectives plus dated proof that senior leaders agreed to them and revisited them.

Test step	What the assessor checks	Evidence usually requested
Review written objectives	Whether cybersecurity risk management objectives exist in writing and are current	Approved objectives document, version history and owner
Confirm time horizons	Whether both near-term and long-term objectives are stated	Objectives tagged by horizon, linked to annual and multi-year plans
Check measurability	Whether each objective has a metric, target or observable outcome	Metric definitions, baseline values, target values and reporting cadence
Look for senior leader agreement	Whether the people accountable for risk approved the objectives, with a record of the decision	Meeting minutes, signed approvals, board or executive committee papers
Trace use in management	Whether leaders use the objectives to manage risk and performance, not only to file them	Dashboards, status reports or decisions that reference the objectives
Test revisiting after planning	Whether objectives were updated during annual strategic planning and after major changes	Planning cycle records, change-triggered reviews, revised objective versions
Compare with the risk program	Whether objectives align with the risk register, risk appetite and organizational context	Traceability from objectives to risks and to the organization's stated mission
Record findings	Whether gaps are reported with clear criteria, such as unmeasurable or unapproved objectives	Assessor's written findings, which only the independent assessor issues

Implementing GV.RM-01 step by step

This sequence turns GV.RM-01 from a statement of intent into agreed, measurable objectives that senior leaders own and revisit. Each step closes with a named artifact so an assessor can trace objectives from draft to review.

Draft near-term and long-term objectives
Start from the organization's mission, strategic plan and dependencies, then write a short set of near-term and long-term cybersecurity risk management objectives. The security lead drafts them with input from business owners so each objective links to a business outcome, such as protecting a revenue service or meeting a customer commitment. Close the step with a draft objectives register that lists each objective, its time horizon and the business context it supports.
Define a measure and owner for each objective
For every draft objective, agree on a measure that can show progress, such as a metric, a threshold or a milestone that can be checked from existing evidence. Name one accountable owner who can act on that measure and report on it. Where a measure cannot yet be produced, record the data source you still need and who will build it. The step is complete when every objective has a measure, a data source and an owner recorded in the register.
Obtain documented agreement from senior leaders
Present the objectives, measures and owners to the executives and board committee who own the risk decisions. Ask them to discuss trade-offs, confirm the objectives and record their approval in the minutes or a signed decision record. Note any objectives they decline or change, and the reason. The output is an approved objectives record with a date, the approving forum and the list of approvers.
Record how objectives feed risk management
Map each approved objective to the risk register, the risk appetite and tolerance statements, and the performance reporting that leaders already receive. Show which risks an objective is meant to reduce and which reports will carry its measure. Confirm that the mapping is visible to the people who manage those risks. The output is a traceability record linking objectives, risks, measures and reports.
Set the review point in strategic planning
Add objective reviews to the annual strategic planning calendar and define the triggers for an unscheduled review after major changes, such as a merger, a new regulated service or a significant incident. Agree who initiates each review and who approves any change to an objective. Confirm the review dates with the planning owner. The output is a documented review schedule and trigger list, approved with the objectives.
Confirm objectives in use and keep the evidence
Check that the objectives appear in the agenda of the leadership or risk committee and in the measure reports produced by owners. Store the approved objectives, decision records, traceability map and review history in a controlled location that assessors can access. An internal reviewer or independent assessor should be able to follow one objective from its approval to its latest review. The step is complete when that trace works for at least one objective, shown on a sample basis.

Evidence that satisfies GV.RM-01 and how to keep it current

An assessor testing GV.RM-01 looks for objectives that exist on paper, were agreed by senior leaders, can be measured and were revisited when planning or circumstances changed. The cards below list the artifacts that show each of those points and the routines that keep them accurate between assessments.

Approved objectives document with version history

This is the core artifact: a written statement of near-term and long-term cybersecurity risk management objectives, with an owner, an approval date and a version history showing what changed and why. Check that each objective names the senior leader who approved it and that superseded versions remain on file rather than being overwritten. Confirm that the document is the one staff actually use, since an assessor may compare it with what the leadership team cites in discussion.

Measurement definitions and current values

Each objective needs a defined metric, a data source, a target and a reporting frequency, plus the current value. Without definitions, a reviewer cannot tell whether an objective was met. Record who calculates each measure, how it is calculated and where the raw data lives, such as the ticketing system or vulnerability scanner. Refresh current values on the schedule set in the definition and keep dated snapshots so trends can be shown.

Leadership minutes and sign-off records

Minutes from the meeting where senior leaders reviewed and agreed the objectives, along with signed approvals, show the agreement the outcome requires. Record attendees, the decision taken and any dissent or conditions. Store these records in the same repository as the objectives document and link each approval to the version it covers, so the assessor can trace a specific objective to a specific decision.

Strategic plan excerpts that reference the objectives

Extracts from the enterprise or IT strategic plan that cite the cybersecurity objectives show they drive planning and resourcing, which is what the Implementation Examples describe. Keep the excerpt tied to its plan version and date, and note the budget or initiative lines that deliver each objective. A plan that lists security goals with no linked initiatives is weaker evidence than one where objectives drive named work.

Review records after planning cycles and major changes

Records of each review show that objectives were updated during annual strategic planning and after major changes such as a merger, a new regulated service or a significant incident. Keep the review date, the trigger, the participants and the outcome, including objectives that were kept unchanged. Maintain a review calendar that lists the planned review dates and a change log that records unscheduled reviews, so gaps between audits are visible before an assessor finds them.

What meeting GV.RM-01 costs in money and effort

This table breaks the effort of setting and maintaining GV.RM-01 objectives into components, showing who does the work, whether each cost is one-time or recurring, and what moves it up or down. No figures are given because none were researched, so use the table to structure a written quote rather than to estimate a budget. The main takeaway is that the objectives document itself needs no tool license, and most of the recurring cost is leadership and analyst time at each planning cycle.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Leadership time to set and agree objectives	Senior leaders and the risk owner, often with an internal facilitator	One-time at first adoption, then recurring at each planning cycle	Number of business units and how many leaders must agree; clear existing strategy documents reduce time
Analyst time to define measures and collect data	Security or GRC analysts, sometimes supported by a partner	One-time to define measures, recurring to collect data	Number of measures chosen, availability of data sources, and whether metrics already exist in tooling
Evidence upkeep at each planning cycle	GRC or program staff who record decisions, revisions and approvals	Recurring	Frequency of planning reviews and whether records are kept in one place or scattered across files
Optional external review of objectives	Independent advisor or consultant, paid under a written scope	Usually one-time or periodic, if chosen	Scope of review, number of objectives and whether leaders want an outside challenge before approval
Auditor sampling time	Independent auditor or assessor, paid by the organization	Recurring at each assessment cycle	Depth of sampling, quality of records, and how quickly the organization can produce approved minutes and revisions
Tool licenses for the objectives document	Not required for the objectives document itself	None for the document	A word processor and a versioned repository are usually sufficient; confirm any tooling need in the written scope
Self-hosted storage for register and evidence	Internal IT or a implementation partner that deploys the platform in your infrastructure	One-time setup, recurring hosting and backup	Choice of self-hosted open-source GRC platform, data volume and backup policy; confirm license terms before deployment
Quote contents to request	Partner or advisor preparing the proposal	One-time at engagement start	Ask for a written scope listing deliverables, assumed meeting counts, data sources, evidence formats and who performs each task

Which self-hosted tools can hold GV.RM-01 evidence

CISO Assistant is an open-source governance, risk and compliance platform published under the AGPL-3.0-only license. According to its README, it ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it can run audits and compliance assessments against them with automatic mapping between frameworks. For GV.RM-01, the relevant question is whether the platform can hold the objectives themselves and tie them to the NIST CSF 2.0 Subcategory, not only the framework text.

Framework library: NIST CSF 2.0 is loaded as a framework so that GV.RM-01 can be referenced directly in an assessment.
Automatic mapping: Mappings between frameworks reduce duplicate work when the same objective supports ISO 27001 or DORA obligations.
Assessment workflow: Audits and assessments are organized against framework requirements, which gives a place to record the status of each objective.
Evidence attachments: Documents such as approved strategy minutes or planning records can be attached to the requirement they support.
Self-hosting: The platform is designed to run in the organization's own infrastructure, so governance records stay under its control.

Before committing, confirm in the README and the current release notes whether objectives tracking, measurement fields and review dates are native features or need custom configuration.

Where organizations usually fall short on GV.RM-01

GV.RM-01 asks for objectives that leaders agree on, can measure and revisit during planning. The gaps below tend to appear together, because an objective that is vague is hard to agree on, hard to measure and easy to forget after the planning meeting. Each card names the check that closes the gap.

Objectives that cannot be measured

Statements such as "improve security posture" or "reduce cyber risk" sound right but give an assessor nothing to test. GV.RM-01 expects objectives that can be measured, so each one needs a metric, a baseline and a target date. Check whether a reviewer could say, from the record alone, whether the objective was met. If not, rewrite it with a measurable indicator and a named data source.

Objectives set by security alone

When the security team drafts objectives and sends them up for sign-off, the result is often a list that executives have never discussed. The Subcategory outcome depends on organizational stakeholders agreeing to the objectives, so the record should show who reviewed them, who approved them and what they said. Check the minutes or decision log for named senior leaders, not only a security sign-off.

No record of annual revisiting

NIST's Implementation Examples describe updating objectives during annual strategic planning and after major changes. Many organizations agree objectives once and never reopen them, so the objectives drift away from the business. Check whether the planning calendar includes a dated review of each objective, and whether the outcome of that review is recorded, including objectives that were dropped or changed.

Objectives disconnected from strategy

Cybersecurity objectives that do not reference the enterprise strategy, the mission or the major initiatives planned for the year are hard to defend at board level. Each objective should trace to a business outcome, such as protecting a launch, a regulated service or a customer commitment. Check that every objective names the strategic goal it supports, and that a leader outside security can explain why it matters.

Evidence scattered across email

Objectives agreed in email threads, chat messages and slide decks are difficult to produce during an assessment and easy to lose when staff change roles. Auditors will ask for one current version, its approval history and the review trail. Keep a single controlled document or ticket for each objective, with an owner, version number and links to the approval record. Confirm that a new team member could find the current set in minutes.

Questions buyers ask about GV.RM-01

How much effort does GV.RM-01 take to put in place?

The effort depends on how many objectives you already have, how clearly they are written and how many teams must agree on them. GV.RM-01 asks for cybersecurity risk management objectives that are set, agreed by stakeholders and kept measurable. NIST publishes three Implementation Examples for it: updating objectives during annual strategic planning and after major changes, making objectives measurable, and having senior leaders agree on them and use them to manage risk and performance. Most of the work is drafting and debating objectives, defining a measure for each one and agreeing a review rhythm. Organizations with an existing strategy and metrics usually need less time than those starting from nothing. Ask any provider to break its estimate into workshops, drafting, measurement design and review cycles.

How long does it take to set up GV.RM-01 objectives?

The duration is driven by four factors: the size of the organization, the number of business units whose risk must be reflected, the maturity of existing planning cycles and the time senior leaders can give to review. Organizations that already run an annual strategic planning cycle can attach objectives to that calendar, which shortens the path. Organizations without one must first agree on who owns the planning process. Your provider should give a duration only in a written scope, with the review meetings and approval steps named. No fixed timeline applies to every organization, so ask for a schedule tied to your planning dates rather than a generic figure.

What does GV.RM-01 need from senior leadership?

GV.RM-01 needs senior leaders to agree on the objectives and to use them to manage risk and performance, which is an explicit NIST Implementation Example. In practice, leaders must do three things:

Review and approve near-term and long-term objectives in a planning forum.
Accept the measures used to judge progress, including what counts as success.
Revisit the objectives after major changes such as a merger, a new regulation or a significant incident.

Leadership does not write the objectives alone, but a set nobody with budget authority has agreed to will not hold. Ask your provider how sign-off will be recorded so an assessor can later see who approved what and when.

Can our in-house team implement GV.RM-01 without outside help?

Yes, many organizations can do it internally, provided someone owns the planning process, has access to executives and can keep measures current. The harder parts are usually neutral facilitation between competing business priorities and drafting measures that are both meaningful and collectable. An outside implementation partner can prepare the workshop material, draft candidate objectives, design the measures and set up the records an assessor will review. The organization still owns its objectives and their approval. A partner does not decide your risk appetite or issue any assessment report. Ask for a written scope that separates the work your team will do from the work a partner performs.

Does NIST certify organizations as compliant with CSF 2.0?

No. NIST does not certify organizations, and it states that it does not offer certifications or endorsements of CSF-related products, implementations or services. It also has no plans to develop a conformity assessment program. The CSF is voluntary for most organizations, although some customers or suppliers require it. If a contract asks for proof of GV.RM-01, you can show documented objectives, approval records and measurement reports. Any formal attestation must come from an independent assessor or certification body chosen by you, and any firm offering a NIST certificate should be questioned closely.

How do GV.RM-01 objectives relate to GV.RM-02 and GV.RM-03?

GV.RM-01 sets what cybersecurity risk management should achieve, GV.RM-02 defines how much risk the organization will accept and how that is measured as tolerance, and GV.RM-03 brings cybersecurity risk into enterprise risk management alongside other risk types. In practice, objectives come first, then risk appetite and tolerance statements express the limits that objectives operate within, and enterprise risk management determines how escalations reach leaders. Objectives that conflict with stated appetite, or that never reach the enterprise risk process, are hard to defend in an assessment. Review the three together during the same planning cycle.

What evidence shows that GV.RM-01 is working?

Assessors typically look for a dated record of the objectives, the approval trail, the measures attached to each objective and evidence that objectives were reviewed during planning or after major change. Useful artifacts include planning minutes, approved objective documents, measurement dashboards or reports and a change log showing revisions. Keep the records in a system your team controls, such as a self-hosted GRC tool, so the history is retained. Confirm with your assessor or auditor which evidence formats they accept before the work starts.

Which CSF 2.0 Subcategory mappings should we check for GV.RM-01?

NIST's Reference Tool lists informative references for GV.RM-01, including SP 800-53 Rev. 5.2.0 controls PM-9, RA-7 and SR-2, ISO/IEC 27001:2022 clauses 6.1.1 and 6.1.2 with Annex A control 5.1, and SP 800-171 Rev. 3 requirements 03.11.04 and 03.17.01. These are useful starting points if you must show alignment with several frameworks. Confirm each mapping against the current NIST export before relying on it in a contract, because NIST updates informative references separately from the framework document.

How DeployOpen prepares GV.RM-01 evidence

DeployOpen starts with a written scope that names the business units, systems and decision forums whose objectives will be covered, the planning cycle the objectives will follow and the people who must agree to them. Scope, deliverables and timelines are agreed in writing before work starts, and most engagements are fixed-scope. A quote follows from that written scope, so the reader should expect the scope document to list the leaders involved, the existing strategy and risk documents to be reviewed, and the systems that will hold the objective records. DeployOpen prepares systems and evidence for the client, but the client owns its objectives and the decisions to approve them. DeployOpen does not issue audit reports, attestations or certifications; an independent auditor or certification body does that.

Inside the client's own environment, DeployOpen helps build the objectives structure: a short register of near-term and long-term cybersecurity risk management objectives, each with an owner, a measure, a baseline, a target, a review date and a link to the strategic plan. The measures are where most of the work sits. Each objective needs an indicator that a steering group can read in a meeting, such as the share of in-scope assets covered by a named risk owner or the number of overdue risk decisions. Where the organization already runs a GRC platform, such as the self-hosted CISO Assistant (AGPL-3.0-only), the register can be configured there so that objectives, measures and review records sit alongside the controls they support. The client should confirm which features its chosen platform supports before relying on them.

Readiness review comes last. DeployOpen can walk through the evidence an assessor would ask for under GV.RM-01: approved objectives with dates, minutes showing senior leaders agreed them, records of updates after the annual planning cycle or a major change, and reports showing that objectives are used to manage risk and performance. Each item should be traceable to the NIST CSF 2.0 Core and to the informative references the client maps to, which NIST publishes in the NIST CSF 2.0 Reference Tool export. The client should ask the independent assessor which evidence formats and sampling approach it expects before the review begins, because those choices shape what is recorded and retained.

GV.RM-01 Risk management objectives agreed