GV.RM-02 Risk appetite and tolerance statements

What GV.RM-02 risk appetite and tolerance statements require in plain terms

GV.RM-02 expects three things: written risk appetite statements, measurable risk tolerance statements, and a routine that refines both as the risk picture changes. When a leader or auditor asks whether cyber risk decisions follow written limits, this Subcategory is the test. NIST CSF 2.0 places it under the Risk Management Strategy (GV.RM) Category in the GOVERN Function, and paraphrased, its outcome is that these statements are created, communicated and kept current. The risk it addresses is familiar: accept, fund, delay or reject a cyber risk one case at a time, with no shared limit that tells the people deciding whether the answer is within bounds. The two statements do different jobs. *Risk appetite* is the broad amount of risk leadership is willing to accept in pursuit of its objectives, written in business terms. *Risk tolerance* is the measurable boundary around that appetite, the point at which a specific exposure stops being acceptable and must be escalated or treated. Appetite tells a team what kind of exposure is acceptable, and tolerance tells it whether a given system, supplier or incident is inside that line. Organizations usually struggle in three places: appetite statements so vague that every decision can be justified, tolerances that nobody measures in the security tooling, and statements left unchanged after new threats, acquisitions or audit findings change the picture.

The practical first check is whether each tolerance names a metric the security team already collects, an owner who must act when it is breached, and a review date. Confirm with your risk function which of your existing reports can show those metrics, and confirm with your leadership team who approves changes to the appetite statement. Those answers tell you whether the Subcategory is met on paper or in daily decisions. NIST publishes three Implementation Examples for GV.RM-02 that cover communicating appetite statements, turning them into specific and measurable tolerances, and refining objectives and appetite using known exposure and residual risk. Read them alongside the Core text in the NIST CSWP 29 PDF, since they are the most direct guide to what an assessor will look for. Tie each refinement to a documented trigger, such as a material incident, a new regulatory requirement or a change in the risk register, so the update is traceable rather than an annual formality.

Which parts of the organization and its risk decisions GV.RM-02 covers

Before anyone writes a risk appetite statement, leadership has to decide what it applies to. These six decisions shape the work more than the wording does, and each one changes which owners, data and systems the statements must reach.

Business units, data classes and systems

Decide which business units, data classes and systems the statements govern. A statement that covers customer payment data needs different measures than one covering internal collaboration tools, so list each data class and the systems that store or process it. Check that every in-scope system has a named business owner who can accept or challenge the tolerance that applies to it. Ask whether shadow or self-service platforms fall inside the boundary.

Risk categories with their own tolerance

Operational, third-party, data loss and availability risks often behave differently, so one global tolerance rarely fits all of them. Decide which categories get a separate tolerance statement and which inherit a general one. For example, an availability tolerance is usually expressed as tolerable downtime, while a data loss tolerance is expressed as an acceptable exposure of records. Write down the reason for each choice so auditors can follow it.

Subsidiaries and shared services

Decide whether subsidiaries, joint ventures and shared services such as a central identity team or a managed platform group need their own statements or inherit the parent's. Where a shared service supports several business units, its tolerance must be consistent with the tolerances of every unit it serves. Confirm which entity holds legal and regulatory accountability, because that entity usually sets the appetite.

Link to the cyber risk register

Each tolerance should map to the risk scenarios, ratings and treatment decisions in the cybersecurity risk register, so that a breach of tolerance can be traced to a specific risk entry. Confirm which register fields carry the tolerance threshold and who updates them when residual risk changes. Without this link, the statements remain text that nobody measures against.

Alignment with GV.RM-01 objectives

The appetite and tolerance statements should support the near-term and long-term cybersecurity risk management objectives that senior leaders agreed under GV.RM-01. Check that each objective has a corresponding tolerance it depends on, and that no tolerance contradicts an objective. Record which objective each statement serves so that revisions to objectives trigger a review of the statements.

Approval by executives and board committees

Name the executive who proposes each statement, the executive who approves it and the board committee that reviews it. Many organizations assign the chief information security officer to draft, the chief risk officer or equivalent to challenge, and the board risk or audit committee to approve. Write the approval path into the governance record, and confirm how often the committee revisits the statements and what triggers an earlier review.

How an assessor tests risk appetite and tolerance statements

This table walks through four test steps an assessor can apply to GV.RM-02, showing the evidence each step requests and the findings that appear most often. Read it as a checklist: if your evidence does not answer a step, expect that step to become a finding.

Test step	Evidence requested	Common findings
Confirm the appetite statement exists and is approved	A written risk appetite statement, its approval record from senior leadership or the board, and the date it took effect	Statement is undated, unsigned, or sits in a draft folder; approver is an IT manager rather than someone with authority over risk
Check that tolerances are specific and measurable	Tolerance statements tied to appetite, with thresholds, units, owners and the metrics used to measure them	Tolerances use wording such as 'low' or 'acceptable' with no threshold; no metric exists to show a breach
Check communication to people who take risk decisions	Distribution records, briefing materials, meeting minutes where risk owners discussed the statements, and evidence that they applied them to decisions	Statements are published but risk owners cannot explain them; decisions on exceptions do not reference the appetite
Check the review record against changes in exposure and residual risk	Dated review log, the inputs used (known exposure, residual risk results from assessments or incidents), and any revisions made	No review since first approval; significant incidents or new threats did not trigger an update; residual risk data is missing from the review

How to write, translate and refine risk appetite and tolerance statements

The sequence turns leadership's view of how much cybersecurity risk the organization will accept into measurable tolerances that teams can check, and keeps both current as exposure changes.

Draft the appetite statement with leadership
Senior leaders, with the CISO or the person accountable for cybersecurity risk, write a short statement of how much cybersecurity risk the organization will accept in pursuit of its objectives. Tie each point to a stated mission goal, a regulated service or a critical business process, so the statement explains why the appetite exists rather than listing general aims. The output is a draft statement with a named owner and a list of the objectives it supports. The step is complete when each objective in the draft can be traced back to a leadership decision.
Translate each appetite point into tolerances
For every appetite point, the risk owner drafts one or more tolerance statements with a measurable threshold, a unit of measurement, a named owner and the action required when the threshold is crossed. Thresholds should describe a condition the organization can observe, such as a count, a time window, a coverage percentage or a monetary range, and the source of each measure should be named. Many first-pass thresholds depend on data the organization does not yet collect, such as asset coverage, time to contain or supplier exposure, so the output should also list the data gaps and who will close them. The step is complete when every tolerance has an owner, a threshold and a data source.
Check tolerances against the risk register and method
The risk function tests each tolerance against the cybersecurity risk register and the standard risk calculation method used in GV.RM-06, confirming that the same likelihood, impact and rating scales produce a comparable result. A tolerance that cannot be evaluated from the register, or that uses a scale the method does not define, is revised or assigned a data collection task. The output is a register view or report field for each tolerance and a short note on any tolerance that cannot yet be measured. The step is complete when each tolerance can be checked from recorded risk data.
Communicate and document approval
The approved appetite statement and its tolerances go to the decision makers who must act on them, including executives, the board or its risk committee, and the department leads who own affected processes. The approving body records its decision, the date, the version and any conditions, and the statements are stored in a controlled location with restricted edit rights. The output is a signed or minuted approval and a published version that operational teams can find. The step is complete when each decision maker has received the statement and the approval record is retrievable.
Monitor tolerances against reported exposure
Risk owners report tolerance measures on the cadence set in the risk governance process, and the risk function compares them with the threshold for each statement. When a tolerance is breached, the owner records the breach, the response decided under the risk response options and the leadership notified. The output is a periodic tolerance report that shows status, trend and open breaches. The step is complete when every breach has a recorded owner, response and escalation outcome.
Set review triggers for known exposure and residual risk
The organization defines the events that require the appetite and tolerance statements to be refined, such as a material change in known risk exposure, a significant residual risk left after treatment, a new regulatory obligation, a major incident or a change in strategy. When a trigger fires, the owner proposes a revision, the same approval path runs again, and the change is recorded. The output is a documented trigger list and a change log that links each revision to the evidence that caused it. The step is complete when a revision can be traced to a trigger and an approval.

Which evidence shows the statements exist, are communicated and stay current

GV.RM-02 is only as credible as the records behind it. The artifacts below show that appetite and tolerance statements were approved, passed to the people who act on them, measured against real results and revised over time. Keep them in one controlled location so the history is easy to produce between audits.

Approved risk appetite statement

The current appetite statement, with the version number, the body that approved it and the date of approval. Assessors generally look for a clear link between the statement and the leadership decision that adopted it, such as meeting minutes or a signed approval record. Check that the statement names the categories of cyber risk it covers and that the approver had the authority to set it. Store the signed record next to the statement, not in an email thread.

Tolerance register with thresholds

A register that turns each appetite statement into measurable tolerance statements, listing the metric, the threshold, the named owner and the review frequency. A useful test is whether someone outside the team can tell from the register alone when a threshold has been crossed. Confirm that every tolerance traces back to an appetite statement and that each metric has a documented data source.

Communication record and recipients

A dated record of who received the appetite and tolerance statements, in what form, and whether they acknowledged them. This shows the statements were communicated, which is a separate outcome from being written down. Include executives, risk owners and the teams that operate the controls the tolerances depend on. Update the distribution list when roles change so the record matches the organization chart.

Tolerance breach log and decisions

A log of each time a tolerance was exceeded, with the date, the metric value, the response chosen and the person who decided it. Accepting, mitigating, transferring or avoiding the risk should each leave a traceable decision. Assessors tend to test whether breaches lead to action and whether the statements were revisited afterward. An empty log can raise questions too, so explain how monitoring would have caught a breach.

Dated review history and revisions

The record of each review of the appetite and tolerance statements, including what changed, why, and who approved the change. Reviews should be triggered by known exposure, residual risk changes and incidents, not only by the calendar. A versioned wiki such as XWiki keeps every edit with its author and timestamp and allows comparison and rollback. A GRC tool such as CISO Assistant can hold the same history alongside audits and assessments, and it is worth confirming how each tool exports that history for an assessor.

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

This table lists the cost components of setting and maintaining risk appetite and tolerance statements, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a request for quote, since every row should map to a line in the written scope.

Cost component	One-time or recurring	Who carries the cost	What drives it up or down
Executive and board time to set appetite	One-time to set, recurring to revisit	Executives, board members, risk committee	Number of risk categories leaders must decide on, and how many decision rounds are needed before statements are approved
Analyst time to translate appetite into tolerances	One-time build, recurring refinement	Internal risk or security analysts, or a partner under a fixed-scope engagement	Number of business units and systems in scope, and whether metrics already exist for each tolerance
Tooling and licenses	Recurring where commercial, often none for self-hosted open source	Organization or its hosting provider	Choice of a GRC or wiki platform already in use; self-hosted open-source tools can remove license spend but still need hosting and administration
Evidence upkeep through review cycles	Recurring	Risk owners and the security or compliance team	Frequency of review, the rate at which known exposure and residual risk change, and how many tolerance statements must be tracked
External facilitation or review by a partner	Usually one-time, optionally recurring	Organization, under a written scope with agreed deliverables	Internal facilitation skill, the scale of workshops, and whether an independent review of draft statements is requested
Independent auditor testing	Recurring with each audit cycle	Organization, paid to an external auditor or assessor	Audit scope, sampling depends on evidence quality, and whether the framework is used for a contract or regulator

Which open-source tools can hold the statements and their evidence

CISO Assistant is an open-source governance, risk and compliance platform licensed under AGPL-3.0-only. For GV.RM-02, its value is in linking risk appetite and tolerance statements to the framework outcomes they support. The project's README describes support for more than 200 frameworks, including NIST CSF, ISO 27001, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it runs audits and compliance assessments against them with automatic mapping between frameworks. Teams can therefore record a tolerance threshold once and show where it bears on several frameworks at the same time.

Framework linkage: Tolerance statements can be tied to the GV.RM-02 Subcategory so the assessment record shows the statement, its owner and its review history together.
Assessment records: Assessment runs against the loaded framework content keep a structured record that an assessor can follow without a spreadsheet.
Automatic mapping: Mappings supplied by the platform can help reuse one statement across frameworks, but each mapping should be reviewed by the compliance lead.
License obligations: AGPL-3.0-only applies to modifications and, in some network deployments, to the software served to users. Legal review should happen before customizing the code.
Operating burden: The platform is a database-backed application that needs its own backup, patching and access control.

Confirm which framework content version is loaded, how it handles the NIST CSF 2.0 Subcategory identifiers, and whether the mapping output satisfies your assessor before relying on it.

Where organizations fall short on risk appetite and tolerance

Most weak GV.RM-02 implementations fail in predictable ways: the statements exist but do not bound any decision, or they exist but drift out of use. The cards below pair each gap with a remediation step that leadership and the risk function can complete and evidence.

Appetite written as slogans

Statements such as "we take a measured approach to cyber risk" do not tell a manager which risks to accept, avoid or escalate. Replace the slogan with a boundary the executive team can apply to a real decision, such as the categories of system or data where a loss event is unacceptable and the conditions under which the board would accept an exception. Ask each executive to name one decision the statement would change. If none comes to mind, the statement needs rewriting.

Tolerances without a measurement source

A tolerance such as "critical systems recover quickly" cannot be tested because nobody has named the data that shows whether it holds. For each tolerance, record the metric, the system or population it covers, the tool or log that produces the figure, and the owner who reports it. Where a tolerance depends on a value that is not yet measured, mark it as pending and set a date for the first reading rather than leaving the field blank.

Statements approved once and never revisited

A statement approved during the first framework cycle often outlives the business conditions it described, such as new products, new jurisdictions or a changed supplier base. GV.RM-02 expects appetite and tolerance to be refined as known exposure and residual risk change. Set a review trigger list, including major incidents, material audit findings and significant changes to the risk register, and schedule a standing review at the strategic planning cycle so refinement happens on a known cadence.

Tolerances not linked to the risk register

When tolerances live in a policy document and the risk register uses its own scoring, the two cannot be compared, and a risk above tolerance can sit unflagged for months. Add a field to each register entry that names the tolerance it is measured against and shows whether current residual risk is inside or outside it. Review the breaches each reporting period and record the response decision, whether that is treatment, acceptance with an expiry date or escalation.

Communication stopping at the executive team

Appetite that only the executive team has read cannot guide the engineers, product owners and procurement staff who make most daily risk decisions. Identify the functions that take actions bounded by tolerance, such as change approval, vendor onboarding and access requests, and give each a short extract of the statements that applies to its decisions. Confirm with each function lead that they can state the boundary in their own words.

No record of who approved which version

Without a versioned record, an assessor cannot confirm which appetite statement was in force when a risk was accepted, and the organization cannot show its own decisions were authorized. Keep each version with its approver, approval date, effective date and a summary of what changed. Store the history in a system that retains prior versions and attribution, so an earlier statement can be retrieved without relying on email threads.

Who owns the statements, who prepares evidence and who tests them

Your leadership and risk team owns the decision. The risk appetite statement says how much cybersecurity risk the organization is willing to pursue to meet its objectives, and only accountable executives and the board or its delegate can set it and accept the consequences. Tolerance statements, which turn appetite into measurable limits for specific risk areas, should be approved by the same people who own the risk register and the enterprise risk committee. Outside help can inform the decision, but it cannot make it.

Appetite decision: Executives agree the statement, record the reasoning and name the person who signs it.
Tolerance approval: Owners approve each measurable limit, including the threshold, the measure and the response when a limit is breached.
Communication: The team decides who receives the statements and how they reach business units, suppliers and the board.
Periodic review: The team sets the trigger for refining appetite when known exposure or residual risk changes.
Accountability record: The organization keeps the approval history so an assessor can see who decided what and when.

Check that every tolerance statement has a named owner who can accept a breach, and that the approval record exists before any external assessor is engaged.

Questions buyers ask about risk appetite and tolerance statements

How much of this work can we do in-house versus with a partner?

Most organizations draft the statements in-house and bring in a partner for structure, facilitation and evidence design. The organization owns the decisions: which risks it will accept, how much disruption it will tolerate and which thresholds leadership signs. A partner can prepare the working drafts, map each appetite statement to measurable tolerance thresholds, and set up where the statements live and how they are versioned. The split depends on how many business units, regulators and existing risk registers must be reconciled. Ask any partner for a written scope that names the deliverables, the workshops included and the review cycles before work starts, so the quote reflects the actual effort.

What does risk appetite work need from executives?

It needs named executives who can make trade-off decisions, not only review drafts. The board or a designated committee should approve the appetite statements, and senior leaders from finance, operations, legal and the business lines should agree the tolerance thresholds that apply to their areas. Executives must commit time for at least a few facilitated sessions and must be willing to state, in plain terms, how much loss or downtime the organization accepts. When leaders delegate the decisions to the security team alone, the statements tend to be technically precise but never adopted. Confirm the approval path and the decision owner in writing before the work begins.

How long does a first pass at risk appetite statements take?

The duration depends mainly on the number of business units, the maturity of the existing risk register, the availability of executives and the number of regulatory obligations that must be reflected. An organization with a documented enterprise risk management process and clear financial loss data usually moves faster than one that has never quantified cyber risk. Approval cycles often take longer than drafting, because each committee must review and agree the wording. No duration is set here, because none has been researched for this topic. Ask any provider to break the timeline into workshops, drafts, review rounds and approval steps, and to state which of those depend on your executives.

Can our organization write risk appetite statements without outside help?

Yes, an organization can write them alone if it has leaders who can make risk decisions, a working enterprise risk management method and someone accountable for keeping the statements current. NIST CSF 2.0 does not prescribe the wording or the thresholds, so the organization sets them. Teams that go alone often struggle with two parts: turning broad appetite language into measurable tolerance statements, and documenting how those statements will be refreshed as exposure and residual risk change. An outside partner can help with those parts, but the decisions remain yours. Check your current risk governance maturity against the GV.RM-02 Implementation Examples before deciding.

Does NIST certify our risk appetite and tolerance statements?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Statements are internal governance documents that an organization writes and approves itself. If a customer, regulator or auditor asks for evidence, they will examine whether the statements exist, were approved, are communicated and are kept current. Only an independent auditor or assessor can issue a report on those controls, and an implementation partner can only prepare the statements and evidence for that review.

How often should we revisit risk appetite and tolerance statements?

Revisit them on a fixed schedule set by leadership and also whenever a material change occurs. The NIST Implementation Example for GV.RM-02 describes periodic refinement based on known risk exposure and residual risk, so the trigger is changing exposure, not only the calendar. Common triggers include a major incident, a new regulatory obligation, a significant change in the technology estate, a merger or a shift in strategy. The review cycle your board chooses should be documented, along with who approves each change and where the version history is kept. Ask for the revision process to be part of the written scope so the cost of recurring reviews is visible.

What should a written scope cover before we request a quote?

A written scope should list the business units and risk categories in scope, the number of facilitated workshops, the deliverables such as appetite statements, tolerance thresholds and a communication plan, and the review rounds included. It should also name the approval steps and the executives expected to attend, and state which evidence the organization will receive. Deployopen agrees scope, deliverables and timelines in writing before work starts, and provides a quote from that scope. Ask any provider for the same level of detail, and compare quotes against identical deliverables rather than headline effort.

How DeployOpen prepares risk appetite and tolerance evidence

DeployOpen helps organizations prepare the systems, documents and evidence behind GV.RM-02 risk appetite and tolerance statements, inside the client's own infrastructure. The organization's leadership sets its appetite and tolerances, and an independent auditor or assessor, not DeployOpen, judges whether the outcome is met.

How we scope

Agree in writing which risk appetite and tolerance records, owners and review cycles fall inside the engagement before work starts.
Confirm which GV.RM-02 Implementation Examples the organization already meets and which it needs to address.
Identify the risk register, governance forums and self-hosted tools that will hold appetite and tolerance statements.

How we build

Configure a self-hosted wiki or GRC platform to hold appetite statements, measurable tolerance statements and their approval history.
Map each tolerance statement to the risk categories and measures leadership has agreed, so exposure can be compared against it.
Set up version control and role-based permissions so changes to appetite and tolerance are recorded with who approved them.

How we hand over

Deliver the written appetite and tolerance statements, the review procedure and the change log in the organization's own repositories.
Provide a documented process for refining appetite and tolerance when known risk exposure and residual risk change.
Brief the named owners on how to maintain the records, and list the evidence an assessor will ask to see.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and periodic review of appetite and tolerance records are available as a retainer.
Ask any implementation partner to confirm in writing which evidence is prepared by them and which decisions remain with your leadership.