GV.RM-03 cyber risk in ERM: requirements and evidence

What GV.RM-03 cybersecurity risk in enterprise risk management asks for

GV.RM-03 asks that cybersecurity risk management activities and results feed into the organization's enterprise risk management (ERM) processes. It sits in the Risk Management Strategy Category of the GOVERN Function in NIST CSF 2.0, and it takes over CSF 1.1 ID.GV-4 under a new identifier. The Subcategory does not ask for a separate cyber program or a new tool. It asks that cyber risk be visible in the same forums, registers and decisions where financial, operational, compliance, reputational and safety risks are already handled. NIST CSF 2.0 is voluntary, and NIST does not offer certification of an organization's alignment, so the question for your assessor or customer is whether your records show this link, not whether a certificate exists.

The risk this addresses is cyber risk that stays siloed. When the security team tracks incidents and vulnerabilities in its own queue, the executive committee may hear about a problem only after it has become a financial or regulatory event. Two things usually make the link hard. First, ERM owners and cyber staff often use different vocabularies, so a risk described as an unpatched internet-facing service may never be translated into the likelihood and impact language the enterprise register uses. Second, many organizations have no agreed escalation thresholds, so the decision about when a cyber issue reaches the board is made case by case, or by whoever happens to be on call.

A practical starting point is to ask three questions and record the answers. Which cyber risks appear in the enterprise risk register, with named owners? Who from cybersecurity attends ERM planning, and what do they contribute? Which written criteria determine that a cyber risk is escalated to ERM or to the board? The NIST Small Business Quick-Start Guide (SP 1300, February 2024) cites this Subcategory when it encourages small businesses to manage cyber risk alongside their other business risks, so the principle applies at any size. Confirm with your own ERM committee and internal audit which thresholds they expect to see, because the Subcategory does not set numeric values and the criteria must fit your risk appetite.

Which risks, teams and processes fall inside GV.RM-03

GV.RM-03 is only as large as the scope you draw around it. The decisions below set which ERM categories cyber risk must sit beside, who takes part, and how far subsidiaries, suppliers and existing registers are pulled in. Settle them in writing before estimating effort, because each one changes how much work the assessment involves.

ERM categories cyber risk must sit beside

NIST's Implementation Examples for GV.RM-03 name compliance, financial, operational, regulatory, reputational and safety risks as the categories cyber risk should be managed alongside. Confirm which of these your enterprise risk framework already tracks as separate categories. Each one you add means a cross-reference between a cyber risk and an existing ERM owner, so a narrow list keeps the first pass manageable while a full list gives a more complete picture.

Business units and risk owners

Decide which business units, process owners and executives own cyber risks that have financial or operational consequences. The Implementation Examples call for cybersecurity risk managers to take part in ERM planning, so name that role explicitly and record who signs off on escalations. Unclear ownership is the most common reason cyber risks stay outside the enterprise register, so write the owner beside every scoped risk.

Subsidiaries in the enterprise view

Decide whether legal entities, business lines and joint ventures that share systems or data are inside the enterprise risk view. A subsidiary that runs its own ERM process may hold cyber risks the parent never sees. Include them and the register grows, reconciliation takes longer and each entity needs an owner. Exclude them and the parent should document why and how their material risks still reach leadership.

Outsourced services and suppliers

Decide whether cyber risks in outsourced services, cloud platforms and managed providers feed the enterprise register directly or only through supplier risk processes. Services you run through a provider still carry your financial, operational and reputational exposure. Including them adds due diligence records and contract data to the review, so confirm which supplier risk outputs the enterprise register will accept.

Existing cyber risk registers

Inventory every register that holds cyber risk, including project risk logs, vulnerability backlogs, audit findings and the register used for a regulator or customer. Decide which one is the source for the enterprise view and how the others map into it. Duplicate entries and conflicting scores are the usual problem, so agree one scoring method and one identifier for each risk before reconciling.

Escalation thresholds for cyber risk

Set the criteria that move a cyber risk from a team register into the enterprise register and to the board. Without written thresholds, escalation depends on individual judgment and gets applied unevenly across business units. Test the criteria against a few past incidents and near misses to see whether they would have escalated them, and record the decision in the policy.

How an assessor tests cybersecurity risk in enterprise risk management

This table compares five things an assessor samples for GV.RM-03, with the test approach, the records requested and the gaps that appear most often. Read it as a checklist of decisions to prove, since an assessor samples recorded decisions rather than accepting a policy statement. The main takeaway is that cyber risk must be visible in the enterprise risk process in practice, not only written into a policy.

Test area	Test approach and evidence requested	Common findings
ERM framework document	Read the enterprise risk management framework and check whether cybersecurity risk is named as a risk category. Request the version history and approval record.	Cyber risk appears only in an IT policy and is absent from the ERM framework, or the framework was last approved before cyber risk was added.
Enterprise risk register	Sample register entries. Confirm cyber entries exist and use the same likelihood, impact and scoring scale as financial, operational and compliance entries.	Cyber risks are tracked in a separate IT register, or they are scored on a different scale so they cannot be ranked against other enterprise risks.
Escalation criteria	Request the written criteria for escalating cyber risks to ERM. Then pick recent security events and check whether the criteria were applied and the escalation decisions were recorded.	Criteria exist but no record shows they were used, or a significant incident was handled inside IT without an ERM decision.
Cyber risk managers in ERM planning	Review agendas, minutes and attendance for ERM planning meetings. Confirm cyber risk managers gave input and that their input changed a recorded decision.	Cyber leaders are invited to annual reviews only, or minutes show attendance without any recorded contribution to planning.
Link to compliance and regulatory risk	Trace a regulatory or contractual obligation to its entry in the risk register and to the cyber risk it depends on. Confirm the owner and treatment decision are recorded.	Compliance obligations are tracked by the legal or audit team with no link to cyber risk entries, so overlapping exposures are scored twice or not at all.

How to bring cyber risk into the enterprise risk process, step by step

This sequence moves cybersecurity risk from a separate IT list into the enterprise risk management process, so that cyber risks are scored, owned, escalated and reviewed on the same terms as other business risks.

Map existing ERM categories and governance
Start by collecting the current enterprise risk management framework: the risk categories in use (financial, operational, compliance, reputational, safety and others), the committees that review them, and the owner of the ERM process. Confirm with the ERM owner where cyber risk would sit today, if anywhere. The output is a mapped category list that shows each existing ERM category, its owner, its review forum and the gap where cybersecurity risk has no home. Done means the ERM owner has reviewed and signed off the mapping.
Agree a common scoring scale with the ERM owner
Cyber risks only compete with other enterprise risks if they are scored on the same likelihood and impact scale. Work with the ERM owner to adopt the existing scale, or to define a joint one where cyber needs extra detail, such as the impact of data loss or service disruption. Document how each level is defined in business terms. The output is a joint scoring scale that the ERM committee has approved. Done means a cyber risk and a financial risk of similar severity receive comparable ratings under the same definitions.
Add cyber risk entries to the enterprise register
Move the cybersecurity risks already identified in your technical registers into the enterprise risk register. Each entry should name a business owner, describe the business consequence rather than only the technical flaw, and reference the scale agreed in the previous step. Avoid duplicating entries across registers. The output is a cyber section of the enterprise register with one owner and one score per risk. Done means every cyber risk in the enterprise register can be traced back to its source assessment.
Bring cyber risk managers into ERM planning
Add the people who manage cybersecurity risk to the ERM planning cycle, including the planning sessions where enterprise risk priorities and budgets are set. Their role is to explain cyber exposure in terms the ERM committee can compare with other risks. The output is a documented list of cyber risk participants in ERM planning, with the meetings they attend and the inputs they provide. Done means the ERM plan for the next cycle records cyber risk priorities and the reasons for them.
Define escalation criteria for cyber risks
Set the conditions under which a cybersecurity risk moves from the security team to the ERM committee or the board. Criteria typically combine a score threshold on the agreed scale with business triggers, such as a risk that could affect a regulated service, customer data at scale, or a supplier that cannot be replaced quickly. Write the criteria so a risk owner can apply them without a debate. The output is an escalation procedure approved by the ERM committee. Done means a sample of past cyber risks can be sorted into escalate or hold decisions with the same answer each time.
Run one or two test escalations
Before relying on the procedure, test it. Choose one or two realistic cyber risks from the register, as an illustrative exercise, and walk them through the escalation criteria, the notification route and the ERM committee discussion. Record where the criteria were unclear, who was missing from the route and how long the decision took in practice. The output is a short test record with the changes made to the criteria or routing. Done means the procedure has been adjusted once based on a real run and the changes are approved.
Set a review cadence for the cyber risk register
Agree how often cyber entries in the enterprise register are re-scored, who triggers an unscheduled review after a significant incident, change or new threat, and how the ERM committee receives updates. Confirm the cadence with the ERM owner against the existing ERM calendar rather than creating a separate one. The output is a documented review schedule and trigger list in the ERM governance calendar. Done means the next scheduled review has an owner, an agenda that includes cyber entries, and a record of the last review.

Setting criteria for escalating cyber risk within ERM

GV.RM-03 names escalation criteria because cyber risk without thresholds either floods the board with routine findings or never reaches it at all. Escalation criteria are the rules that decide which cybersecurity risks leave the security function and enter enterprise risk management (ERM) forums, at what speed, and in front of whom. Common triggers include a threat to a critical service beyond an agreed impact level, a risk that breaches a stated risk tolerance, a condition that starts a regulator or customer notification duty, exposure across a system or business unit above an agreed level, and a high-rated finding that remains open past its remediation deadline. The thresholds should follow from the risk appetite and tolerance set under GV.RM-02 and from the scoring method set under GV.RM-06, so that a risk rated high under one method is not handled as low under another. Confirm the exact wording of the Implementation Examples in the NIST CSF 2.0 Reference Tool before drafting, because NIST publishes them online and can revise them separately from the framework document.

Each trigger needs a named owner who is accountable for noticing that it has fired and for deciding whether to escalate. Usually that is the cybersecurity risk manager for detection and a specific executive, such as the chief risk officer or the business owner of the affected service, for the decision. Write down who holds each role, who covers when they are absent, and how many hours or days the owner has to act after a trigger fires. An illustrative example: a trigger for an unpatched internet-facing system that supports a payment service could name the head of platform engineering as the detector and the chief risk officer as the decision maker, with the decision logged in the risk register within one business day. Without this allocation, the criteria exist on paper but nobody acts on them.

Keep a record of every escalation decision, including decisions not to escalate. The record should state the trigger, the facts used, the owner's decision, the rationale, the risk treatment chosen and the review date. Assessors and board members will ask for this trail, and it shows whether the thresholds are being applied consistently. Review the criteria at least when risk appetite changes, after a material incident, or when a regulator or major customer changes what it requires, and check that no trigger has gone silent for a long period, since that can signal a threshold set too high. Ask the people responsible for ERM to confirm how escalations reach the board so the criteria connect to the reporting line in GV.RM-05.

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

This table lists the cost components of bringing cybersecurity risk into enterprise risk management, who is paid for each, whether it is one-time or recurring, and what drives it up or down. NIST does not certify or price the framework, so every cost below comes from your own staff time, tooling and any outside review you choose to buy. Use it to build a written scope and quote request.

Cost component	One-time or recurring	What drives it	How to keep it down
ERM process design and mapping	One-time	Number of ERM categories, how many existing risk registers must be reconciled, and how many business units feed the process	Start from the enterprise risk taxonomy already in use and map cyber risks to it instead of building a separate scheme
Enterprise risk tooling or licenses	One-time setup, then recurring	Whether a commercial GRC product is licensed or a self-hosted open-source tool is deployed, plus integration with the existing ERM system	Reuse current ERM software where it fits; self-hosted open-source GRC removes license spend but not configuration or hosting work
Risk owner and cyber risk manager time for ERM meetings	Recurring	Meeting frequency, number of attendees, and how many cyber risks are presented each cycle	Set a fixed review cadence, send pre-read summaries, and limit presentations to risks that changed or crossed a threshold
Escalation drill effort	Recurring	How many escalation criteria exist, how many roles are involved, and how often drills are run and their findings tracked	Test the escalation criteria in a tabletop with the existing incident team rather than running separate exercises
Evidence upkeep	Recurring	Volume of meeting minutes, risk register entries, escalation records and decisions that must be kept current and retrievable	Store evidence in the ERM system of record with consistent naming, and assign an owner for each record type
Assessor or independent review fees (if purchased)	Recurring per assessment	Scope of the review, number of sites and systems sampled, and whether the reviewer must be independent of the implementation partner	Ask for a written scope with defined sampling and deliverables, and compare quotes on the same scope

Who owns, who prepares and who assesses GV.RM-03

Your leadership owns GV.RM-03 in substance. The CISO, cyber risk managers and the enterprise risk management (ERM) owner decide how cybersecurity risk is weighed against financial, operational, compliance, reputational and safety risks, which thresholds trigger escalation, and who signs off on what reaches the board. These decisions are the outcome the Subcategory describes, so they cannot be delegated to a consultant or a tool.

Decision rights: Name the individuals who approve escalation criteria and record their approval in the ERM policy or committee minutes.
Thresholds: Set the criteria for escalating cybersecurity risks within ERM, including the impact levels and conditions that move a risk to the enterprise register.
Risk records: Keep the cybersecurity entries in the enterprise register current, with owners, dates and the decisions taken.
Cyber risk manager input: Involve cyber risk managers in ERM planning cycles so their view is in the agenda, not added afterward.
Escalation practice: Run real escalations through the process at least periodically so the records show the criteria in use.

Check that every threshold and approval in this tab appears in a document your leadership has actually adopted, with a named owner and a review date.

Which evidence shows cyber risk is inside enterprise risk management

The evidence for GV.RM-03 is a set of records showing that cybersecurity risk actually moves through the enterprise risk management (ERM) process, not a single policy statement. An assessor will usually start with the ERM framework or charter, checking that it names cybersecurity risk alongside financial, operational, compliance, reputational and safety risks. Next, expect requests for an extract from the enterprise risk register with the cyber entries, their owners, and the scores used to rank them, dated within the current cycle. Keep the extract as a dated export, because a live register view cannot be tested later.

Governance records come next. Pull agendas and minutes from the ERM committee for the last few cycles and mark the cyber items, so the assessor can see discussion and decisions rather than a standing line. Store the written escalation criteria with their approval record, showing who signed them and when. Pair them with an escalation log that lists each cyber risk escalated, the decision taken, the decision-maker and the date. Also keep attendance or meeting records proving that cybersecurity risk managers took part in ERM planning, since the Implementation Examples for this Subcategory name that involvement directly.

To keep these current between audits, assign one owner to collect each artifact on a fixed calendar and confirm the owner can produce it on request. A GRC platform such as CISO Assistant (AGPL-3.0-only), which ships many frameworks and runs assessments with automatic mapping between them, may hold these records, but confirm with the vendor and in your own environment that it stores ERM registers, committee minutes and escalation decisions in the form your process needs. For control mappings, NIST's CSF 2.0 Reference Tool links GV.RM-03 to ISO/IEC 27001:2022 clause 6.1.3, Annex A control 5.1 and several SP 800-53 Rev. 5.2.0 controls. Check each mapping against the source documents before an assessor sees it, rather than reusing a copied table.

Where organizations fall short on cyber risk in ERM and how to close each gap

Most weaknesses under GV.RM-03 are not missing policies. They are breaks in the path between cyber risk records and the enterprise risk process, so decisions about cyber risk never reach the people who own enterprise risk. Each card names one break, the symptom an assessor is likely to notice and the closing action that repairs it.

Cyber risks stay in the IT register

Cyber risks are logged in a security or IT tool and never appear in the enterprise risk register that the executive committee reviews. An assessor will compare the two registers and find cyber items missing, or find that they are listed only as technology issues. Close the gap by agreeing which cyber risks meet the enterprise threshold and mirroring those entries into the enterprise register with a named business owner, reviewed on the same cycle as other enterprise risks.

Scoring scales that do not compare

Cyber teams score likelihood and impact on a 1 to 4 scale while finance and operations use monetary bands or a 1 to 5 scale, so no one can rank a cyber risk against a supplier, credit or operational risk. Assessors look for one shared scale in the enterprise method. Close the gap by mapping cyber impact to the same financial, customer and safety bands used across ERM, then recalibrating a sample of past cyber risks to confirm the scores line up.

Escalation criteria written but unused

The risk policy defines when a cyber risk must go to the executive or board, but the escalation log shows no entries against those criteria over the review period. Assessors compare the written thresholds with actual incidents and near misses and ask why nothing was escalated. Close the gap by running a tabletop against the criteria, recording the decision on each test case, and tracking every cyber risk that crosses a threshold through to a documented ERM decision.

No record of ERM decisions on cyber items

Committee minutes mention cyber topics, but there is no record of what was decided, who accepted the residual risk or when it will be revisited. An assessor will sample cyber risks and ask for the decision trail. Close the gap by adding a decision field to the enterprise register with the approver, the risk response chosen, the accepted residual level and a review date, and by filing each decision in the minutes with a reference to the register entry.

ERM owners absent from cyber reviews

Enterprise risk owners such as the chief financial officer, operations lead or general counsel receive cyber reports but attend no cyber risk review, so business context does not shape scoring or responses. Assessors check attendance and ask who signs off cyber risk acceptance outside the security team. Close the gap by naming enterprise risk owners for each cyber risk category, scheduling them into a quarterly joint review, and recording attendance and sign-off in the review minutes.

Third-party risk outside ERM

Supplier and cloud provider risks are assessed by procurement or security during onboarding, then dropped from the enterprise register, so a critical vendor outage or breach never reaches the leadership risk view. Assessors ask whether the enterprise register includes concentration and dependency risks from key suppliers. Close the gap by adding a register entry for each critical supplier, linking it to the business service it supports, and reviewing it alongside other enterprise risks when the supplier assessment is refreshed.

How DeployOpen works on this

DeployOpen works on GV.RM-03 by preparing the systems, records and evidence that show cybersecurity risk flowing into your enterprise risk management process. The organization keeps ownership of its risk decisions, escalation criteria and sign-off, and DeployOpen implements the supporting platforms inside your own infrastructure.

How we scope

Agree in writing which ERM forums, risk registers and escalation paths the engagement covers before work starts.
Map the GV.RM-03 Implementation Examples to your existing ERM categories and name the owner of each record.
Confirm which informative references your assessor expects, such as the SP 800-53 or ISO/IEC 27001 mappings in scope.

How we build

Configure a self-hosted risk register that records cybersecurity risks alongside financial, operational and compliance risks.
Set up documented escalation criteria and test that a sample risk reaches the ERM committee through the defined route.
Test the workflow with your risk owners so evidence of review, decisions and dates is captured as the process runs.

How we hand over

Deliver the written scope, configuration records, runbooks and a model escalation criteria document for your review.
Provide an evidence index that maps each artifact to the GV.RM-03 outcome and the assessor's testing questions.
Walk through the handover with your CISO, risk function and internal audit so ownership is clear after delivery.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Review escalation records and register changes periodically so the evidence stays current for the next assessment.
Confirm with your independent assessor which evidence they accept, since DeployOpen prepares evidence but does not issue reports.

Questions buyers ask about GV.RM-03 cost, effort and outside help

Can we meet GV.RM-03 in-house without outside help?

Yes, in most organizations the core work can be done in-house, because GV.RM-03 is an outcome about how cybersecurity risk management feeds into enterprise risk management (ERM), not a technical configuration. The organization owns the decision. The work is to show that cybersecurity risks are reported into the ERM process, that cybersecurity risk managers take part in ERM planning, and that escalation criteria exist. Teams that already run an ERM function and a risk register often need less help. Outside help is most useful when the ERM process is immature, when the risk register is inconsistent, or when the team lacks someone who can translate technical findings into business risk language. Confirm your own starting point before deciding.

What drives the effort needed to meet GV.RM-03?

The effort depends mainly on how mature your ERM process already is and how many risk categories it covers. The three Implementation Examples for GV.RM-03 point to managing cybersecurity risk alongside compliance, financial, operational, regulatory, reputational and safety risks, so organizations with many business lines or regulators tend to need more mapping work. Other drivers include:

Whether a shared risk taxonomy and scoring method already exist
How many risk registers and owners must be reconciled
Whether escalation thresholds are written down or left to judgment
How often the board or executive committee already reviews risk

Each driver adds work to the initial design and to the recurring reviews that keep the process current.

How long does it take to bring cybersecurity risk into ERM?

The timeline depends on the drivers above, not on a fixed period that applies to every organization. NIST does not publish a duration for GV.RM-03, and this page does not supply one. A useful way to plan is to split the work into phases: agreeing the ERM integration design, mapping cybersecurity risks to existing ERM categories, setting escalation criteria, and then running the first full reporting cycle. The first cycle usually takes longest because it tests whether the criteria work in practice. Ask any implementation partner to explain how each phase is scheduled and what finishes each one before you accept a timeline.

What does GV.RM-03 need from the compliance lead and risk owners?

The compliance lead and risk owners must make decisions that engineers cannot make alone. The compliance lead usually coordinates how cybersecurity risks are classified alongside other ERM categories and confirms that the records meet internal and external requirements. Risk owners must accept responsibility for individual risks, agree on likelihood and impact ratings, and confirm the escalation thresholds. Expect these people to review draft criteria, attend planning sessions and sign off the final design. Their time is the constraint that most often delays the work, so confirm named owners and review dates before the engagement starts.

Does NIST certify that we comply with GV.RM-03?

No, NIST does not certify compliance with the CSF or with any subcategory such as GV.RM-03. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The CSF is voluntary for most organizations, although some customers or suppliers may require it. Any statement that your organization is certified against GV.RM-03 should be treated with suspicion. What you can show is evidence of your own alignment, which your organization decides how to present.

Must an independent assessor check our GV.RM-03 work?

No assessor is required by NIST, and the organization decides whether to commission one. If you need an outside view, for example because a customer or regulator asks for it, an independent assessor, auditor or certification body issues any report. DeployOpen prepares systems, controls and evidence for assessment but does not issue audit reports, attestations or certifications. Before you commission an assessment, confirm what the requesting party will accept, the scope of the review and whether the assessor will use the CSF 2.0 Reference Tool or its own method.

What should we ask for in a written quote for GV.RM-03 work?

Ask for a quote that follows a written scope, because DeployOpen does not publish a price list and most engagements are fixed-scope. A useful quote states the deliverables, the ERM documents and risk registers in scope, the number of workshops, the roles each party performs, and what the client must provide. It should also separate one-time design work from recurring activities such as quarterly reporting or retainer support, and it should say what happens if scope changes. Ask the provider to confirm exactly which outputs are evidence that you can give an assessor and which are internal working papers. Scope conversations are the right place to discuss figures for your environment.

GV.RM-03 Cybersecurity risk in enterprise risk management