GV.RM-02: Risk appetite and risk tolerance statements are established, communicated, and maintained

GV.RM-02 requires you to formally define your cybersecurity risk appetite (what you’re willing to accept) and risk tolerances (the measurable thresholds you won’t exceed), then keep those statements current and actively communicated to decision-makers. Operationally, you need board/executive-approved statements tied to metrics, governance, and recurring evidence that teams use them in prioritization and exception decisions. ¹

Key takeaways:

• Put risk appetite in writing, then translate it into measurable tolerances teams can apply day-to-day. ¹
• Make the statements govern real decisions: funding, control selection, exceptions, third-party onboarding, and incident response. ¹
• Maintain audit-ready evidence: approvals, communications, metrics reporting, and periodic refresh based on business and threat changes. ¹

The gv.rm-02: risk appetite and risk tolerance statements are established, communicated, and maintained requirement is a governance control disguised as a risk control. Auditors and regulators rarely fail you for lacking a sophisticated risk model; they fail you when leadership cannot show clear thresholds for acceptable cyber risk, and when operational teams cannot prove they used those thresholds consistently.

Risk appetite is directional. It expresses leadership’s intent: where you accept risk, where you avoid it, and where you invest to reduce it. Risk tolerance is executable. It converts intent into measurable boundaries (for example, maximum acceptable outage for a critical service, maximum time a high-risk vulnerability can remain open, or conditions under which a third party is unacceptable). Your goal is to make these statements “live”: used in intake decisions, exceptions, and prioritization, then reviewed and updated as the business changes.

This page gives you requirement-level implementation guidance: who must own GV.RM-02, what to write, how to get it approved, how to push it into operations, and what evidence to retain so you can defend it under audit. The source requirement is from the NIST Cybersecurity Framework (CSF) 2.0. ²

Regulatory text

Excerpt (GV.RM-02): “Risk appetite and risk tolerance statements are established, communicated, and maintained.” ¹

Operator interpretation (what you must do):

1. Established means you have written, approved statements for cybersecurity risk appetite and risk tolerances that fit your organization’s business context. ¹
2. Communicated means relevant stakeholders can access and understand them, and you can show how they are embedded into decisions (not buried in a slide deck). ¹
3. Maintained means you review, update, and re-approve them on a defined cadence and upon triggering events (M&A, major product launch, material incidents, major third-party changes). ¹

Plain-English interpretation of the requirement

You need a “line in the sand” for cyber risk that leadership agrees to, and that teams can apply without guessing. In practice, a strong implementation has two layers:

• Risk appetite statement (qualitative): Leadership’s stance on categories of cyber risk (availability, confidentiality, regulatory exposure, systemic third-party concentration, ransomware readiness).
• Risk tolerance statements (measurable): Thresholds that drive action, escalation, or refusal. These map to metrics you already track in security and GRC (risk ratings, vulnerability SLAs, BCP/DR targets, third-party criticality, exception volumes).

If you cannot tie tolerances to operational metrics and escalation rules, GV.RM-02 is not functioning, even if it exists on paper.

Who it applies to (entity and operational context)

Applies to: Any organization running a cybersecurity program that uses NIST CSF 2.0 as a framework or reference point. ¹

Operational contexts where GV.RM-02 becomes “exam critical”:

• Regulated industries where board oversight and risk governance are examined (financial services, healthcare, critical infrastructure).
• Organizations with material third-party dependencies (cloud, managed services, payment processors, data processors).
• High-change environments (frequent releases, acquisitions, new geographies) where risk posture shifts quickly.

Typical accountable owners:

• Accountable (A): CISO and/or CCO/Head of GRC, with executive sponsor (CRO/COO/CFO depending on org).
• Responsible (R): GRC lead for drafting, metric mapping, and evidence.
• Consulted (C): Legal, Privacy, IT Ops/SRE, Product, Procurement/TPRM, Internal Audit.
• Informed (I): Control owners, engineering leaders, incident response leadership, third-party relationship owners.

What you actually need to do (step-by-step)

Step 1: Define scope and decision use-cases

Write down where appetite/tolerance must be used so you can test it later:

• Security exceptions (control waivers, compensating controls)
• Vulnerability remediation prioritization
• Third-party onboarding and renewals (especially critical/high inherent risk)
• Incident response severity and escalation thresholds
• Project risk acceptance for launches and architecture changes

Deliverable: a one-page “decision inventory” that lists each use-case, owner, and required tolerance metric.

Step 2: Draft the risk appetite statement (qualitative)

Keep it short and executive-readable. A workable format is a table by risk domain:

Risk domain	Appetite (High/Moderate/Low)	What that means operationally
Availability of critical services	Low	Prioritize resilience work, require tested recovery plans for critical systems
Third-party concentration	Low	Avoid single points of failure; require exit plans for critical third parties
Innovation speed in low-sensitivity products	Moderate	Accept measured control debt with time-bound remediation

Deliverable: “Cybersecurity Risk Appetite Statement” with clear scope and definitions.

Step 3: Translate appetite into tolerances (measurable thresholds)

For each domain, define tolerances that are:

• Measurable (you can report them)
• Assignable (an owner can act)
• Escalatable (breaches trigger decisions)

Examples of tolerance categories to consider (tailor to your business):

• Service resilience: tolerances tied to recovery objectives and testing outcomes.
• Vulnerability exposure: tolerances tied to remediation timelines by severity and asset criticality.
• Identity and access: tolerances tied to privileged access controls and review completion.
• Third-party risk: tolerances tied to minimum security requirements for critical third parties (e.g., incident notification commitments, encryption expectations, audit rights, subprocessor transparency).
• Data protection: tolerances tied to data classification handling and approved transfer mechanisms.

Deliverable: “Cybersecurity Risk Tolerance Register” that maps each tolerance to metric source, reporting cadence, and escalation path.

Step 4: Align tolerances to governance and policies

Update or cross-reference:

• Information Security Policy
• Risk Management Policy / Enterprise Risk Management (ERM) documentation
• Third-party risk management standards
• Exception management procedure
• Incident response escalation criteria

Goal: no tolerance exists without a place in governance where it gets enforced.

Deliverable: a mapping table that links GV.RM-02 statements to policies, procedures, and control owners. This directly supports the recommended control to map GV.RM-02 to policy, procedure, control owner, and recurring evidence collection. ²

Step 5: Get formal approval and record it

Approval should match your governance model (board, risk committee, executive leadership). Record:

• Version
• Approval date
• Approver names/titles
• Effective date
• Next review trigger (cadence and event-driven triggers)

Deliverable: signed minutes, approval memo, or governance portal record.

Step 6: Communicate and operationalize (prove people can use it)

Communication is not an email blast. Build it into workflows:

• Exception workflow: require an “appetite/tolerance alignment” field; force escalation when tolerance is breached.
• Third-party onboarding: require a tolerance check for critical third parties; record outcome.
• Risk register: require mapping of top risks to appetite category and tolerances; show whether within tolerance.
• Quarterly risk reporting: include tolerance breaches, trends, and corrective actions.

Deliverable: screenshots, training materials, process docs, and meeting decks that show tolerances used in decisions.

Step 7: Maintain it with a review-and-change process

Maintenance requires a defined owner and triggers. Common triggers:

• Material incident or near miss
• New regulated product line
• Significant architectural change (cloud migration, identity re-platform)
• Major third-party shift (new MSSP, critical SaaS consolidation)

Deliverable: change log, review notes, and re-approval evidence.

Required evidence and artifacts to retain

Keep evidence in an audit-ready package:

1. Risk Appetite Statement (current and prior versions) ¹
2. Risk Tolerance Register with metrics, owners, and escalation rules ¹
3. Approval records: board/risk committee/executive sign-off artifacts ¹
4. Communication evidence: intranet posting, policy acknowledgments, targeted training for risk approvers ¹
5. Operational proof (most important):
   • Exception tickets showing tolerance check and escalation
   • Third-party assessments showing tolerance gating for critical third parties
   • Quarterly reporting showing tolerance breaches and remediation actions ¹
6. Maintenance evidence: review calendar, triggers, change log, periodic re-approval ¹

Daydream practical note: teams often store these in scattered systems (GRC tool, ticketing, SharePoint). Daydream works best when you map GV.RM-02 to a named control owner and schedule recurring evidence pulls from those systems, so audits become retrieval rather than archaeology.

Common exam/audit questions and hangups

Expect these questions:

• “Show me the approved risk appetite and tolerances for cybersecurity.”
• “Who approved them and when were they last reviewed?”
• “How do tolerances affect vulnerability remediation, exceptions, and third-party onboarding?”
• “Show examples where a tolerance was breached and what decision was made.”
• “How do you ensure teams know these thresholds exist?”

Hangup patterns:

• Appetite exists; tolerances do not.
• Tolerances exist; no evidence they drive decisions.
• Metrics exist; no link to governance, escalation, or approvals.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Writing a generic appetite statement with no tie to the business	No operational meaning, no decisions change	Anchor it to services, data classes, regulated obligations, and third-party dependencies
Tolerances expressed as slogans (“we have zero tolerance for breaches”)	Not measurable; not credible	Replace with thresholds that trigger escalation and resourcing
No exception governance mapped to tolerances	Teams accept risk informally	Require tolerance checks in exception tickets and approvals
Third-party risk treated separately	Appetite doesn’t cover supply chain	Add third-party concentration and critical third-party minimums to tolerances
No maintenance triggers	Statements go stale	Define event-driven review triggers and track them in a change log

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for GV.RM-02, so this page does not cite specific actions. Practically, weak GV.RM-02 implementation increases the chance that executives cannot demonstrate reasonable oversight of cyber risk, and it leads to inconsistent acceptance of risk across business units. That inconsistency is what examiners and auditors tend to probe: “Who decided this was acceptable, based on what threshold, and where is the record?”

Practical 30/60/90-day execution plan

First 30 days: Establish and approve a usable baseline

• Identify the governance body and approvers for cyber risk appetite/tolerance.
• Draft appetite domains and a first-pass tolerance register using metrics you already report.
• Define the top workflows that must consume tolerances (exceptions, third-party onboarding, vulnerability SLAs).
• Secure formal approval; publish a controlled version with an owner and review triggers.

By 60 days: Embed into core workflows and reporting

• Update exception management to require appetite/tolerance alignment and escalation on breaches.
• Add tolerance checks to third-party intake for critical third parties; record decisions.
• Produce a recurring risk report showing tolerance breaches, root causes, and remediation owners.

By 90 days: Prove operations and maintenance

• Collect multiple real examples of tolerance-driven decisions (approved exceptions, rejected third parties, prioritized remediation).
• Run a tabletop review with leadership: test whether tolerances trigger the right escalations.
• Finalize the maintenance calendar and change log process; schedule the next review and evidence collection cycle.

Frequently Asked Questions

What’s the difference between risk appetite and risk tolerance for GV.RM-02?

Risk appetite is the leadership-level posture on what categories of cyber risk you’re willing to accept. Risk tolerance converts that posture into measurable thresholds that teams apply in workflows and escalations. ¹

Do we need board approval, or is executive approval enough?

GV.RM-02 requires the statements be established, communicated, and maintained, but it doesn’t prescribe an approver in the excerpt provided. Match approval to your governance model, then retain evidence that the right risk authority approved and reviews it. ¹

How do I prove “communicated” without spamming the company?

Tie the statements to systems people already use: exception tickets, third-party onboarding checklists, and quarterly risk reporting. Auditors value evidence of use over broad announcements. ¹

We have ERM appetite statements already. Do we need cyber-specific ones?

If the ERM statements cover cybersecurity in actionable detail and include tolerances your security program can report and enforce, you can extend them. Most teams still need a cyber-specific tolerance register to make thresholds operational. ¹

How often should we review and update appetite and tolerances?

Set a defined review cadence and event-driven triggers tied to material business, threat, or technology changes. The key test is whether you can show a maintained version history and re-approval when conditions change. ¹

What’s the minimum artifact set to get through an audit?

Keep the approved appetite statement, the tolerance register with metric owners, evidence of communication into key workflows, and examples of tolerance-driven decisions plus a maintenance/change log. If any one of these is missing, GV.RM-02 is hard to defend. ¹

Footnotes

1. NIST CSWP 29

2. NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes