GV.RM-01 says risk management objectives are established and agreed to by organizational stakeholders. This is where the strategy gets teeth: written, measurable goals that leaders have signed on to, so security work can be judged against something.
What good looks like
A short list of objectives, near term and long term, set during annual planning and updated when something major changes. Each is measurable. Senior leaders agree on them and use them to steer budget and priorities.
How to implement it
- Draw on the mission and obligations you already documented under GV.OC.
- Write objectives that can be measured. Compare "improve vulnerability management" with "fix critical findings in internet facing systems within seven days, at least 90 percent of the time".
- Mix near term and long term goals, such as closing a known gap this quarter and building a recovery capability over the year.
- Review with leaders together, not one by one, so trade offs are visible. Record agreement.
- Link each objective to a metric (see GV.OV-03) and an owner.
- Revisit at annual planning and after major changes.
Evidence to collect
- The objectives document with dates, owners and metrics.
- Meeting notes or sign off showing leaders agreed.
- Planning records showing objectives were updated.
Common gaps
- Objectives are vague and cannot be measured.
- Security sets them alone and finance or product has never seen them.
- Objectives are set once and never updated after a major change.
- No link to budget, so nothing changes.
Example objectives
A fifteen person software company could set four: reduce time to fix critical dependency vulnerabilities to seven days; complete access reviews for all production systems each quarter; restore the customer database from backup within four hours in a test; and complete security training for all staff within 30 days of hire. Each one is checkable, each has an owner, and each maps to a risk the leadership team already worries about.
Tying objectives to the rest of governance
Objectives become useful when other governance outcomes point back at them. The metrics under GV.OV-03 measure them. The resource decisions under GV.RR-03 fund them. The policy under GV.PO-01 states how to meet them. If you cannot draw a line from a budget request or a policy rule back to an objective, one of the two probably needs rethinking.
Annual rhythm
Set objectives during annual strategic planning, check progress each quarter, and reopen them when something large changes, such as a funding round, a major customer in a regulated sector, or a serious incident. Small companies can do this in a single ninety minute session with leadership, as long as someone writes down what was agreed.
Checking an objective
A quick test for each objective: can someone tell next quarter, with data, whether it was met? Does one person own it? Would a leader notice if it were dropped? If any answer is no, rewrite it.
Quick check
Who must agree to the objectives?
Senior leaders whose budgets and teams are affected, usually the CEO, engineering, product, finance and legal or operations heads.
Sources
- NIST Cybersecurity Framework 2.0 Reference Tool, subcategory GV.RM-01: https://csrc.nist.gov/projects/cybersecurity-framework/filters
- NIST Cybersecurity Framework overview: https://www.nist.gov/cyberframework
The CSF is voluntary guidance. There is no CSF certification, so this post describes how to work toward the outcome, not how to pass an audit.
