What GV.RM-04 asks leaders to decide before risks arrive
When an auditor, a customer questionnaire or a board member asks when your organization accepts, avoids, transfers or shares a cyber risk, GV.RM-04 is the outcome they are testing. It requires documented strategic direction on which risk response options are appropriate, and that this direction is set and communicated. GV.RM-04 is a Subcategory of the Risk Management Strategy (GV.RM) Category in the GOVERN Function of CSF 2.0, so it sits with the leadership decisions that shape everything else in the framework rather than with the technical controls that carry them out. The topic covers three decision areas: when to accept or avoid risk for each data classification, whether to buy cybersecurity insurance, and when shared responsibility arrangements such as outsourcing or public cloud services are acceptable.
The difficulty is specificity. A statement such as "we manage risk prudently" does not tell a team whether it may run a legacy system holding confidential customer records, or whether a vendor can host regulated data outside the organization's own environment. NIST's Implementation Examples for GV.RM-04 point toward criteria tied to data classification, a documented position on insurance, and a written account of which shared responsibility models are acceptable. Confirm your current data classification scheme first, because the acceptance and avoidance criteria can only be written against the categories you already use. Then ask the people who make these calls every week to test the criteria against two or three real past decisions.
Which decisions, data and third parties this requirement covers
GV.RM-04 is only as useful as the decisions it reaches. The choices below determine how many acceptance rules, shared responsibility boundaries and approval paths an organization must document, so they should be settled before anyone estimates effort.
Data classification scheme
Acceptance and avoidance criteria are keyed to data classes, so the scheme in use sets how many rule sets exist. A four-level scheme with clear handling rules produces fewer exceptions than a scheme where each business unit names its own labels. Before scoping, confirm which classes exist, who owns the labels and whether systems already tag data by class. If no scheme exists, creating one is usually the largest single piece of work under this Subcategory.
Risk categories needing separate rules
Not every risk type can be accepted or avoided under the same logic. Regulatory, third-party, operational technology and data loss risks often need their own criteria because their consequences and owners differ. List the categories your risk register already uses and mark which ones need distinct response rules. Each separate category adds a rule set that leadership must approve and maintain.
Cloud and managed services under shared responsibility
Shared responsibility models split security duties between the organization and its provider, and the split varies by service type. Decide which cloud platforms, SaaS applications and managed services fall within the documented position. For each one, record which controls remain with the organization. Contracts, provider security documentation and the organization's own configuration responsibilities all feed this inventory.
Cyber insurance in the decision set
Whether to buy cybersecurity insurance is a named Implementation Example under GV.RM-04. Including it in scope means the strategy must state when insurance transfers a risk and when the organization keeps it. Check whether insurance terms already depend on controls you have not yet evidenced. Insurance can be excluded from scope, but then the strategy should record that decision and why.
Business units that approve exceptions
Exceptions to acceptance and avoidance rules need an owner with authority to approve them. Identify which business units, product owners or regional leads can accept risk within their area, and which exceptions must go to executives. Fewer approvers means faster decisions but more concentrated accountability. Confirm the approval thresholds in writing, because an undocumented exception path is hard to defend in an assessment.
Organization-run versus provider-run scope
The share of systems an organization runs in its own data centers or accounts, compared with those run by providers, determines how much evidence the organization must produce itself. Self-hosted platforms in the organization's infrastructure need full response rules, while provider-run services rely on the provider's documentation and contract terms. Map each system to one of these models before estimating the work, and confirm what each provider will share as evidence.
How an assessor tests the risk response direction
This table compares the four or five tests an assessor typically runs on GV.RM-04, what each one asks the organization to produce, and where the direction tends to fall short. Read each row as a question the assessor will ask, then check whether your documents answer it before the assessment starts.
| Test approach | Evidence requested | Common findings |
|---|---|---|
| Review the written risk response direction and its approval | The current document setting acceptable responses (accept, avoid, mitigate, transfer), its version history, and the record of who approved it and when | Direction exists only as informal guidance, has no owner, or was approved by someone without authority to set risk appetite |
| Compare stated criteria against the data classification scheme | The data classification scheme and the response criteria side by side, showing which response applies to each class | Criteria refer to risk in general terms and never name the data classes, so staff cannot tell which responses apply to customer or regulated data |
| Sample recent risk acceptances, avoidances and transfers | A selection of recent decisions with the risk owner, the stated rationale, the data class affected, and evidence that the criteria were applied | Acceptances signed by no one with authority, decisions that cite no criteria, or avoidances never tracked to closure |
| Sample cybersecurity insurance and shared responsibility decisions | Records showing whether insurance was considered, and for outsourcing or cloud services, the documented rationale and the responsibilities assigned to the provider | Outsourcing or cloud decisions with no documented rationale, or responsibilities assumed by the provider without contract support |
| Review how the direction reached owners and suppliers | Communication records such as briefings, policy acknowledgments, supplier onboarding material, and contract clauses that reference the response criteria | Direction stored in a repository that owners never read, or supplier contracts that do not reflect the organization's response expectations |
Steps to set risk response options that hold up under review
This sequence turns GV.RM-04 into a written position that leaders have approved, that covers each data classification and the insurance and outsourcing questions, and that the people who own risks and buy services can apply. Each step ends with a document a reviewer can inspect.
Confirm the data classification scheme
Start by checking that the organization has a current data classification scheme with defined levels and owners for each level. Risk response criteria only work if every data set can be assigned to a class, so the security lead and data owners review the scheme against the asset inventory maintained under the ID.AM Category. The output is a confirmed classification scheme with a named owner and a review date, plus a list of any data sets that still lack a class. Do not move on until those gaps have an owner.
Draft acceptance and avoidance criteria per class
For each data classification, the security lead drafts the conditions under which the organization would accept a cybersecurity risk, avoid it by not performing the activity, or treat it through other responses. Criteria should reference the risk appetite and tolerance statements from GV.RM-02 so that the thresholds are consistent. The output is an approved criteria table with one row per classification and one column per response option, reviewed by risk owners for clarity. A reviewer should be able to pick any row and see what decision it supports.
Decide and document the cybersecurity insurance position
Finance and legal review whether the organization should buy cybersecurity insurance, and under what conditions. The review covers the losses the organization wants to transfer, the controls insurers ask about at application, and the contract terms that affect coverage. NIST's Small Business Quick-Start Guide cites GV.RM-04 when it suggests that small businesses assess whether insurance is appropriate, so the same question applies at any size. The output is a signed decision memo that states the position, the reasons, the review trigger and the named approver. Confirm the policy terms and exclusions directly with the insurer or broker, since coverage varies by policy.
Set rules for shared responsibility and outsourcing
Legal, procurement and the security lead define when shared responsibility models are acceptable, including outsourced services and public cloud platforms. The rules state which data classes may sit with a third party, what evidence the provider must supply, and when the organization must keep a function in-house. This step connects to the supply chain and vendor work under GV.SC. The output is a written shared responsibility rule set, mapped to the data classes from step one, with a list of services that are currently allowed, restricted or prohibited.
Approve the direction at the right executive level
Present the criteria table, the insurance memo and the shared responsibility rules to the executive or board committee that owns cybersecurity risk decisions. The approving body should be the level that accepts residual risk for the organization, as set out in the roles and authorities in GV.RR. Record the decision, any conditions and any dissent in the minutes. The output is approved minutes or a resolution that references the three documents by version. Without this approval, the direction is advice rather than a position the organization can defend.
Communicate the direction to risk owners and procurement
Once approved, the security lead issues the criteria, insurance position and outsourcing rules to risk owners, department heads and the procurement team, with a short briefing on how to apply them. Procurement adds the rules to intake forms and supplier onboarding so that a service request is checked against the data class before a contract is signed. The output is a distribution record showing who received the direction and when, plus updated procurement templates. Ask each recipient to confirm they understand the escalation path for requests that fall outside the criteria.
Review the direction against outcomes
Schedule a review of the risk response position at intervals the organization sets, and after any material incident, insurance renewal or change in outsourcing. The review checks whether decisions were applied as written, whether exceptions were approved and recorded, and whether the criteria still match the risk appetite. The output is a review note with changes logged against the approved version, which feeds the oversight activity in GV.OV. Keep the record of each exception, since reviewers usually ask for it first.
Evidence that shows the direction is set, communicated and used
An assessor testing GV.RM-04 looks for a written direction, the inputs it relies on, and proof that the people who own risk have received and applied it. The cards below name six artifacts that connect those three steps, with a practical note on keeping each one current between assessments.
Approved risk response direction
The governing document that states which responses are acceptable for each risk level, including when to accept, avoid, mitigate or transfer risk. Record the version, the effective date and the approver, normally a member of executive leadership or the board committee that owns risk appetite. Check that the document cites the risk appetite statements from GV.RM-02 so the two do not drift apart. Keep it current by reviewing it at a set annual date and whenever the cybersecurity strategy or risk appetite changes.
Data classification reference
The classification scheme that the response direction depends on, because acceptance and avoidance criteria differ by data class. The reference should list each class, its owner, the systems that hold it and the handling expectations that apply. Confirm that the scheme in the response direction matches the one used by data owners and asset inventories under ID.AM. Review the reference after any new data type, regulatory scope change or major system migration, and record the review date beside the version number.
Cyber insurance decision record
A dated record showing whether the organization bought cybersecurity insurance, declined to buy it, or deferred the decision, and why. The record should summarize the risks considered, the coverage reviewed, the exclusions that matter for the organization's systems, and the approver. Assessors look for evidence that the decision was made deliberately, not by default. Refresh the record at each policy renewal and whenever the threat profile, critical systems or contractual insurance requirements change.
Outsourcing and shared responsibility reviews
Written criteria for when a service provider or public cloud platform may hold a process or data, plus completed reviews that apply those criteria to real arrangements. Each completed review should name the service, the data class involved, the responsibility split between the organization and the provider, and the approver who accepted the residual risk. Keep reviews current by re-running them at contract renewal, after a material change in the provider's services, and after any incident involving that provider.
Risk owner communication records
Proof that the direction reached the people who own cybersecurity risks, such as system owners, department heads and the legal and procurement teams that sign contracts. Useful records include distribution lists, acknowledgment confirmations, briefing attendance and minutes from the meeting where the direction was presented. Confirm that recipients can state the response options that apply to their systems. Update the distribution list when roles change and send a fresh notice after each approved revision.
Risk acceptance and avoidance log
A running register of each decision to accept or avoid a specific risk, with the data class affected, the rationale, the approver, the expiry date and any compensating controls. The log is where the direction is shown in use. Assessors often sample entries and check that each one falls within the approved direction and within the stated risk tolerance. Review open entries on a fixed schedule so that expired acceptances are either renewed with a fresh approval or closed.
What meeting GV.RM-04 costs in money and effort
This table compares each cost component of setting GV.RM-04 risk response direction, who is paid for it, whether it is one-time or recurring, and what drives it up. No prices or durations are supplied for these items, so use it to structure itemized, scoped quotes and internal budget requests rather than as a estimate of total spend.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Executive and legal time to set direction | One-time to draft, recurring to review | Number of decision-makers, how many data classifications need a response position, and how much legal review the statements need | Attach the response statements to an existing risk appetite or ERM decision cycle so leaders review them in a meeting already scheduled |
| Data classification work, if none exists | One-time, with recurring upkeep | Size and age of the data estate, number of systems holding each class, and whether asset inventories (ID.AM) are already maintained | Start from the classification scheme the organization already uses for privacy or records, and confirm it covers the systems in scope before adding new labels |
| Insurance review and broker input | Recurring at each policy renewal | Whether cybersecurity insurance is already held, the coverage and exclusions being compared, and the broker's time to model scenarios | Ask the broker for a written scope of what the review covers and bring the current policy and incident history to the first meeting |
| Drafting outsourcing and shared responsibility criteria | One-time, updated when suppliers or cloud services change | Number of third parties and cloud services in use, how many contracts already define responsibility splits, and procurement review steps | Reuse existing procurement and third-party risk questionnaires and the GV.SC supplier criteria instead of writing a separate standard |
| Periodic review of response options | Recurring | Frequency set by leadership, changes in threat landscape, new regulatory or contractual demands, and major incidents | Tie the review to the annual ERM or board reporting cycle and record only changes since the last review |
| Evidence upkeep | Recurring | How many decisions must be dated, approved and retained, and whether they live in one register or scattered documents | Keep decisions in the risk register or GRC tool already in use; self-hosted open-source tooling removes license spend but still needs staff time to configure and maintain |
| External review or assessor fees | Recurring if an assessment is commissioned | Scope of the assessment, whether the organization asks for an independent view, and the assessor's own fee terms (NIST does not offer certification for CSF) | Ask for a fixed scope in writing, confirm whether the assessor issues a report or only advises, and prepare evidence before the engagement starts |
| Implementation partner support, if used | One-time or retainer | Whether the partner prepares systems and evidence only, and how much internal interviewing and documentation is needed | Request an itemized quote tied to named deliverables, and confirm which decisions remain with the organization's own leaders |
Who owns the decision, who prepares evidence and who tests it
Your leadership owns every decision GV.RM-04 describes. That means deciding which risk responses are acceptable for each data classification, when risk may be accepted and when it must be avoided, whether to buy cybersecurity insurance, and under what conditions shared responsibility models such as outsourcing or public cloud services are acceptable. These choices follow from your risk appetite and tolerance, which senior leaders set and sign. Nobody else can make them on your behalf, and an assessor will look for evidence that the people with authority made them.
- Acceptance and avoidance decisions: Named executives approve the criteria for each data classification, including who may sign a risk acceptance and for how long.
- Insurance choice: Leadership decides whether to buy cybersecurity insurance, based on its own exposure analysis and the policy terms it negotiates.
- Outsourcing and cloud boundaries: The organization decides which functions may be shared with providers and what residual responsibility stays in house.
- Communication: Decisions reach the teams that must apply them, and the direction is reviewed when risk changes.
- Decision records: Owners keep dated approvals and rationale in a system their own staff can read.
Confirm internally who holds each approval right and whether those names appear in your governance documents before any outside party starts work.
An implementation partner such as DeployOpen prepares the material that makes GV.RM-04 easier to show and maintain. The partner works inside your environment or on your agreed tooling to organize the inputs leadership needs. It does not choose the response options, approve risk acceptances, or state that your direction is adequate. Scope, deliverables and timing are agreed in writing before work begins, so the boundary between preparation and decision is visible from the start.
- Data classification references: The partner can assemble the classification scheme and map each class to systems and data stores for leadership review.
- Draft criteria: Working drafts of acceptance, avoidance and insurance criteria are prepared for the owners to amend and approve.
- Decision record system: The partner can set up a register or GRC workflow that stores decisions, approvers, dates and review cycles.
- Evidence assembly: Approved decisions, policy extracts and review logs are gathered into a folder structure that an assessor can sample.
- Handover: Documentation and runbooks are left with your team so the records remain maintainable after the engagement ends.
Ask any partner to state in writing which artifacts it will draft and which approvals remain with your staff.
An independent auditor or assessor tests GV.RM-04 and is the only party that issues an assessment report or opinion. NIST does not offer certifications or endorsements of CSF-related implementations, so no conformity certificate exists for this outcome. The assessor reviews whether the response direction exists, is approved at the right level, is communicated to affected teams and is applied in practice. Its findings depend on what it can sample and verify, and it will state the limits of its own independence and scope in its report.
- Direction review: The assessor reads the approved criteria and checks that they cover each data classification and the insurance and shared responsibility questions.
- Sampling decisions: It selects a set of accepted or avoided risks and traces each one to an approval, a rationale and a review date.
- Communication checks: It looks for evidence that owners and operators received and understood the direction.
- Independence limits: An assessor cannot design the controls it tests without impairing its objectivity, so advisory work and assurance work are usually separated.
- Scope statement: The report defines what was tested, what was not, and what evidence was unavailable.
Confirm with any auditor which parts of GV.RM-04 it will test, which sample sizes it applies, and whether a readiness review beforehand would conflict with its independence rules.
Open-source tooling that keeps risk response records in one place
GV.RM-04 asks for documented direction on which risk responses are acceptable, and that direction only helps if the evidence and assessment results sit next to it. The cards below describe one open-source GRC option that can hold those records, along with the checks to run before relying on it.
Framework library for response criteria
CISO Assistant ships more than 200 frameworks, including NIST CSF, ISO 27001, SOC 2, PCI DSS, NIS2, DORA and GDPR. For GV.RM-04, this means the acceptance and avoidance criteria can be recorded against the framework that drives them, such as an ISO 27001 clause 6.1.3 risk treatment or a DORA ICT risk requirement. Confirm which framework libraries are loaded in your release and whether you can edit or extend them for your own criteria.
Assessments and audit evidence
The platform runs audits and compliance assessments against the frameworks it holds. Use it to attach evidence to each GV.RM-04 position, such as the data classification criteria, the cybersecurity insurance decision memo or the shared responsibility matrix for a cloud or outsourced service. Ask the vendor how evidence is versioned and whether a past assessment can be reproduced when an assessor requests the state of the program at a given date.
Automatic mapping between frameworks
CISO Assistant performs automatic mapping between frameworks, so a single documented risk response position can satisfy related requirements in several frameworks at once. This reduces duplicate entry when one decision serves NIST CSF, ISO 27001 and DORA. Treat the generated mappings as a starting point, and have your compliance lead review each mapping against the official text before an assessor relies on it.
License obligations under AGPL-3.0-only
CISO Assistant is licensed under AGPL-3.0-only. If you modify the software and make it available to users over a network, the license terms apply to your modified version. Have legal counsel confirm how these terms affect your planned use, internal modifications and any hosted service you offer, before the platform becomes the system of record for risk decisions.
Where risk response direction usually falls short
The most common weakness in GV.RM-04 is direction written as general principles with no data classes behind it. A statement such as "we accept low risks and avoid high risks" gives engineers nothing to apply when a team wants to store customer records in a new service. The fix is to tie each response option to the data classifications your organization already uses, so that for each class someone can state whether accepting, mitigating, transferring or avoiding is allowed, and who signs off. A second gap is acceptance decisions made in meetings with no record. Verbal agreement to accept a known weakness leaves no owner, no review date and no evidence that the decision was made within authority. Close it by requiring a written risk acceptance form with the accepted risk, the approver, the compensating controls and an expiry date, stored where an assessor can find it. Cybersecurity insurance is often treated as a finance matter with no security input. Finance may buy the policy, but the security function knows which controls the insurer will ask about and which exclusions could apply to a real incident. Confirm that security reviews the policy terms and the application answers before purchase, and that the decision to buy or not is recorded with its reasoning.
Outsourcing and cloud services are often approved without checking how the provider's controls and responsibilities are split. Teams sign a contract, assume the provider handles security, and never document which responsibilities remain with the organization. Close this by listing, for each outsourced or shared-responsibility service, which controls the provider performs, which the organization performs, and what evidence the provider supplies, then approving the arrangement against that list. Finally, direction set once and never reviewed is a common failure. New data classes, new platforms, a changed threat picture or a significant incident can each make earlier response decisions wrong. Close it by setting a review trigger in the policy itself, such as a new data class, a new outsourcing arrangement, or a post-incident review, so that the response options are checked against what the organization now runs. Ask your leadership to name the owner of that review and the forum where its results are approved.
Questions buyers ask about GV.RM-04 cost, effort and outside help
How much effort does GV.RM-04 take, and what drives it?
The effort depends mostly on how many data classifications your organization uses, how many response options leadership already has written down, and how many third parties sit in your shared responsibility model. GV.RM-04 asks for strategic direction, not a technical build, so the work is mainly decision-making and documentation. The main drivers are:
- The number of data classifications that need accept and avoid criteria
- Whether a cybersecurity insurance decision has already been made and recorded
- How many outsourced services and public cloud platforms need documented shared responsibility positions
- How many approval rounds the direction needs before leadership signs it
Ask any provider to break its estimate into these items so you can see which ones your team will carry.
Can a small organization write GV.RM-04 direction without a consultant?
Yes, a small organization can usually write this direction in-house, because the subcategory is a short statement of risk response choices rather than a system to build. NIST's Small Business Quick-Start Guide (SP 1300) cites GV.RM-04 when it suggests that small businesses assess whether cybersecurity insurance is appropriate, which shows the expected scale. Outside help is most useful when leaders disagree on acceptable risk, when contracts with suppliers or cloud providers are unclear, or when no one on staff has time to draft the direction and collect sign-off. Your own staff still own the decisions, and an outside partner can only prepare drafts and supporting material.
What does GV.RM-04 need from executives, legal and finance?
Executives own the risk response choices, legal reviews the contract and supplier terms that shape shared responsibility, and finance supplies the figures needed to judge whether insurance or risk transfer is worth buying. Executives must approve the acceptance and avoidance criteria for each data classification and communicate them to staff. Legal should confirm which responsibilities your contracts actually assign to providers, so the documented position matches the agreements. Finance should provide loss exposure estimates and insurance quotes so the cyber insurance decision is based on real numbers. Ask any partner to list these inputs in the written scope before work starts.
How long does GV.RM-04 setup take, and what changes the timeline?
No standard duration is published for GV.RM-04, so the timeline depends on your organization and the scope agreed in writing. Most engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts. The main factors that lengthen the timeline are the number of executive approval cycles, the volume of supplier contracts to review, and whether data classification is already documented. Request a written scope that lists each deliverable and the dependencies on your staff, legal and finance teams, and confirm the dates against that scope rather than a general estimate.
Does GV.RM-04 require us to buy cyber insurance?
No. GV.RM-04 does not require you to buy cybersecurity insurance. Its Implementation Example asks your organization to decide whether to buy it, and to document that decision as part of the response direction. A documented decision to decline coverage is a valid outcome if it reflects your risk appetite and the reasoning is recorded. Insurance is a risk transfer option alongside acceptance, avoidance and mitigation. Confirm with your insurance broker and legal counsel which policy terms, exclusions and notification duties would apply to your environment before you decide.
Will an auditor certify GV.RM-04 for us?
No auditor certifies GV.RM-04 as a standalone item, and NIST does not certify anything. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program. An independent auditor or assessor may examine your documented risk response direction as evidence during an engagement against another framework, and that auditor issues its own report. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports, attestations or certifications. Confirm with your assessor which evidence they expect for this subcategory.
What should we ask a partner to include in a quote?
Ask for a written scope that lists each deliverable, the number of data classifications covered, and the outsourcing and cloud arrangements reviewed. The quote should separate one-time work, such as drafting the direction and running approvals, from any recurring work, such as annual reviews. Ask who is responsible for each input, including executive sign-off, legal review and insurance analysis, and what the partner will not do, such as issuing an assessment report. Also ask how changes to scope are priced and approved in writing. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen works on this
DeployOpen helps organizations turn their GV.RM-04 response decisions into written, testable records inside their own infrastructure. The organization owns the risk acceptance and avoidance decisions, while DeployOpen prepares the systems, documents and evidence that show those decisions are set and communicated.
How we scope
- Each engagement begins with a written scope that names the data classifications and systems covered by GV.RM-04 decisions.
- We list which shared responsibility arrangements, outsourced services and cloud platforms the scope includes and excludes.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.
How we build
- We configure self-hosted open-source GRC tooling in your environment to record response decisions per data classification.
- We draft the risk acceptance and avoidance criteria template for your leadership to review, amend and approve.
- We test that the recorded decisions link to owners, review dates and the supporting risk register entries.
How we hand over
- We document the configured systems, decision records and approval workflow so your staff can operate them independently.
- We deliver a traceable evidence set mapped to the GV.RM-04 Implementation Examples for your internal and external reviewers.
- Only your independent auditor or assessor can issue any report or certificate based on this evidence set.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- We can refresh decision records when insurance terms, outsourcing arrangements or data classifications change.
- Confirm with us in writing which retainer scope, response times and review cadence apply before you commit.
