GV.RM-06 Standard risk calculation method

GV.RM-06 standard risk calculation method: what the requirement asks for

GV.RM-06 asks the organization to set a standard method for calculating, recording, categorizing and prioritizing cybersecurity risk, and to communicate that method so that it is used consistently. It sits in the Risk Management Strategy (GV.RM) Category of the GOVERN Function in NIST CSF 2.0, and it absorbs part or all of CSF 1.1 ID.RM-1. If your IT, security, product and business units each score risk on their own scales, this Subcategory is the one that asks you to replace those private methods with a single, documented approach. The requirement is an outcome, not a prescribed formula, so the organization chooses the method and then has to show that it is applied the same way everywhere. The risk it addresses is incomparability. When one team rates a risk as "high" on a five-point likelihood scale and another rates a similar risk "medium" on a three-point scale, leadership cannot compare them, and the resulting priorities reflect whoever argued most persuasively rather than the exposure itself. Inconsistent scoring also makes risk register entries impossible to aggregate, which weakens reporting to the board and any later decision about where to spend. A useful first check is to take five risks from different departments and score them independently. Wide disagreement on the same risk is the clearest sign that this Subcategory is not yet met. What makes it hard is agreement, not arithmetic. Teams must settle on the scales used for likelihood and impact, decide whether any risks will be quantified in financial or other measurable terms and under what criteria, and define the fields a risk register must hold, including who owns each risk. Each of those choices touches a different department, and the owners of the largest exposures often resist a scale that makes their risks look smaller. Confirm with your own stakeholders who has authority to approve the method, and treat the NIST Implementation Examples for GV.RM-06 as a checklist of design decisions, not as a template to adopt unchanged.

Which risks, teams and tools the standard method must cover

Before a standard calculation method can be written, the organization must decide what it applies to. The cards below cover the risk sources, business units, data classes and inherited risks that the method must reach, with one decision that changes the workload more than the others.

Internal systems and applications

Start with the systems the organization runs itself: on-premises servers, self-hosted applications and internal networks. Each should have an owner who can supply the asset details, exposure and current controls that the method needs as inputs. Check that the scope names systems by inventory identifier rather than by department, because a method applied to a vague scope produces risk entries that nobody can trace back to an asset.

Cloud accounts and platforms

Cloud accounts, managed services and containers often change faster than the inventory. Decide whether each account, subscription or cluster falls under the method and who records its risks when a team creates resources outside central provisioning. Confirm that the register template can record the account or environment as the exposure, so that a single misconfiguration does not get scored twice under two different owners.

Suppliers and outsourced services

Decide whether supplier risks enter the same register and calculation as internal risks, or sit in a separate supplier review. The method should state who scores a supplier's exposure, which data the supplier holds and how the result feeds the risk response options set under GV.RM-04. Ask suppliers which of their controls the organization can rely on, and record that reliance as an assumption the method can test.

AI systems and agents

AI systems add exposures such as training data leakage, prompt injection and unintended tool actions, which may not appear in traditional asset inventories. Decide whether AI models, agents and their connected data sources are in scope, and who owns each one. Confirm that the risk categories list includes AI-specific categories so that these risks are described with the same vocabulary as the rest of the register.

Data classes that drive impact

Impact ratings are only consistent when the organization defines the data classes that set them. Agree on the classes, such as regulated personal data, payment data, health records and internal confidential data, and map each system to the highest class it holds. Check that the method states how a risk touching several classes is rated, so the same incident gets the same impact score in every business unit.

Qualitative and quantitative analysis

This is the scoping decision that changes the work most. If only qualitative ratings such as high, medium and low are allowed, the method is mainly a shared scale and a scoring guide. If quantitative analysis is also allowed, the organization must define formulas, loss estimates, data sources and who validates the inputs, which adds analysis effort and requires finance and risk staff to agree on assumptions.

What a standard risk method has to define before anyone scores a risk

A standard risk method has to settle its components before anyone scores a single risk, because a score means nothing unless everyone applies the same scale. The first component is a likelihood scale and an impact scale, each with written criteria that say what a "high" or "severe" rating means in your environment, for example in terms of downtime, records exposed or contractual penalties. The second is the formula or decision rule that combines them, such as a simple likelihood-by-impact matrix or a rule that any critical impact automatically escalates regardless of likelihood. The third is the quantitative analysis criteria used where money or time is estimated: which loss models are acceptable, which data sources they draw on, and who signs off on the assumptions. Implementation Examples for GV.RM-06 point to criteria and formulas of this kind, so write them down rather than leaving them to individual analysts.

The remaining components are the prioritization rules, the risk register template and the shared list of risk categories. Prioritization rules decide which scored risks reach leadership, which go to an owner's backlog and which are accepted, and they should name the threshold and the decision-maker for each band. The register template should record at least a description, the exposure, the chosen treatment and an owner, which is the set of fields NIST's Implementation Examples describe. The category list keeps different teams from labeling the same risk differently, so that a supplier outage is not filed as operational in one business unit and third-party in another. Before relying on mappings in an audit, confirm the Reference Tool links for GV.RM-06 to SP 800-53 Rev. 5.2.0 controls PM-9, PM-18, PM-28, PM-30 and RA-3, and to ISO/IEC 27001:2022 clause 6.1.2 and Annex A control 5.1, in the NIST CSF 2.0 Reference Tool export and in your own control set.

Assign the method an owner and a review date now. The owner, usually the CISO or the head of enterprise risk, approves the scales, the formula and the categories, and records who may change them. Ask each team to score two or three sample risks using only the written criteria, then compare the results, since disagreements at that stage show which criteria are vague. Any changes to the method should be versioned, so that historical scores can be read against the rules that produced them. Internal audit or an independent assessor will test whether the method was followed consistently, not whether the scores are correct, so the documents and version history are the evidence to prepare.

How an assessor tests the standard risk method

This table compares what an assessor does, what they ask you to produce and the findings that most often come up for GV.RM-06 in each test area. Read each row as a question the assessor will ask and the evidence that answers it, then check your own records against the common findings before the assessment starts.

Test area	What the assessor does	Evidence requested	Common findings
Method document and approval	Reads the written method for calculating, recording, categorizing and prioritizing cybersecurity risk, then checks who approved it and when.	Approved method document with version history, the approver's name and role, and the date it was last reviewed.	Method exists only in a spreadsheet or in one analyst's head, or the approval date is missing or predates the current risk process.
Calculation criteria	Checks that the method states how likelihood, impact and any quantitative inputs are scored, and that the formulas or scales are defined rather than implied.	Scoring scales, formulas, worked examples and the quantitative analysis criteria the organization uses.	Scales are named but not defined, so two assessors would score the same risk differently.
Risk register traced through the method	Selects a sample of risk entries and follows each one back through the method to confirm it was described, scored, categorized and prioritized as the document says.	Register extracts for the sample, with the scoring inputs, the category assigned and the priority assigned for each entry.	Entries lack a score, use categories outside the shared list, or cannot be reproduced from the stated criteria.
Register fields	Checks that the risk register records the fields the method requires, such as description, exposure, treatment and ownership.	Register template and a populated sample showing each required field is completed.	Owner or treatment fields are blank, or treatment is recorded without the reason for the chosen response.
Consistency across teams and periods	Compares how different teams and different review cycles scored similar risks, looking for drift in scales or category use.	Risk entries from two or more business units and from at least two review periods, plus any calibration notes.	Each team uses its own scale or category names, and scoring changes between cycles with no recorded reason.
Communication to risk owners	Looks for evidence that the method was shared with the people who own and score risks, and that they received it before using it.	Distribution record, training or briefing material, acknowledgment from risk owners and the date each was issued.	The method was published on an intranet page with no record that owners read it or were trained on it.
Prioritization follows the criteria	Takes a set of prioritized risks and checks that the order matches the stated prioritization criteria and that exceptions were justified.	Prioritized risk list, the criteria applied, and records of any overrides with the approver and reason.	Priorities are set by seniority or by who raised the issue, with no link to the documented criteria.
Risk category list	Confirms that one shared list of risk categories is used across the register and that categories are applied the same way.	Current category list, its approval record and a count of entries by category.	Categories are added informally, or the same type of risk is filed under different names in different teams.
Method review and change control	Checks that the method is reviewed on a set schedule and that changes are recorded, approved and communicated.	Change log, review minutes and the approval record for each revision.	The method has not been reviewed since it was first written, or changes were made without a log entry.

How to implement a standard risk calculation method in six steps

This sequence turns GV.RM-06 into a working method: one owner, agreed scales and calculation rules, a register and category list that people actually use, and a tested, approved version that the organization communicates.

Confirm scope and method owner
Name the executive sponsor and a single accountable owner for the risk method, usually in the risk, security or GRC function, and agree which business units, systems, suppliers and risk types it covers. Record the scope in a short charter that also states which existing methods, such as enterprise risk management or IT risk registers, the new method must align with. The step is done when the sponsor signs the charter and the owner can name every group that will use the method.
Draft scales and calculation rules
Work with risk owners and the enterprise risk team to define the scales for likelihood, impact and any other factors, such as exposure or control effectiveness, along with the rule that combines them into a rating. Write each level in plain language with observable examples so two assessors would reach the same rating. The output is a draft method document with the scales, the rating matrix and the rules for handling risks that do not fit neatly. It is complete when a small group can rate the same sample risks and agree on most results.
Define quantitative criteria and formulas
Where the organization wants financial or probabilistic estimates, decide which risks need quantitative analysis, which inputs are used, and what formulas convert them into expected loss or similar measures. NIST's Implementation Examples for GV.RM-06 describe criteria and formulas for quantitative risk analysis, so use them as a reference point, then document the data sources, assumptions and owners of each input. Ask the finance and risk teams to confirm the figures they will accept as inputs. The output is a short appendix of criteria and formulas, reviewed by the people who will sign off on the numbers.
Build the risk register template and category list
Create a register template that captures, at minimum, a risk description, the affected assets or processes, the current rating, the treatment chosen, and a named owner. Add a shared list of risk categories so the same kind of risk is labeled the same way across the organization, and align the categories with existing taxonomies where they exist. The output is a populated template with a few example rows marked as illustrative, plus a category list with a definition for each category. Confirm the register can be exported in the format leadership and auditors will request.
Pilot the method on real risks
Run the draft scales, formulas, template and categories against a small set of current risks drawn from several areas, such as an application, a cloud environment and a key supplier. Record where raters disagreed, where a category was missing, and where the calculation produced a result that leadership would not accept. The output is a pilot review record listing each issue, the change made to the method and the person who approved it. The pilot is complete when a second round of ratings shows the changes resolved the issues found in the first.
Approve and communicate the method
Present the revised method to the sponsor and the governance body that oversees cybersecurity risk, and obtain formal approval with a version number and effective date. Publish the method, the register template and the category list where risk owners can find them, and brief each group on how to rate and record risks. Set a review point so the method is revisited as the organization's risk profile changes. The output is an approved method document, a communication record showing who was briefed, and an entry in the register of the method's version history.

Which evidence shows the method is standard and in use

An assessor testing GV.RM-06 looks for two things: a written method that the organization actually owns and maintains, and proof that people apply it to real risks. The artifacts below connect the method document to the register, the criteria and the sampled risk entries, so each one can be traced to the next.

Approved risk method document

This is the written method that defines how cybersecurity risks are calculated, recorded, categorized and prioritized. It should name an owner, show an approval record from the accountable executive or risk committee, and carry a version history with the date and reason for each change. Check that the document states a scheduled review date and that the version in use matches the approved one. The method should also state how quantitative analysis is applied, including the formulas or criteria used, so that an assessor can reproduce a calculation.

Risk register template with required fields

The register is the working record of the method. Its template should include fields for risk description, exposure, treatment decision and risk owner, which are the elements NIST describes in its Implementation Examples for GV.RM-06. Confirm that every live entry uses the same template and that no required field is left blank without explanation. Keep the template under version control so that a change to a field can be traced to the date it was introduced and the reviewer who approved it.

Shared risk category list

A single list of risk categories lets different teams describe the same kind of risk in the same words, so that totals and trends can be compared across business units. The list should be short enough to use consistently and should map each category to a named owner who maintains it. Check that the list in the register matches the list in the approved method, and that any category added since the last review has a recorded approval date.

Scoring and prioritization criteria

These criteria define how likelihood, impact and exposure are rated and how the ratings translate into priority. Written thresholds, such as what separates a high from a medium rating, allow two assessors to reach the same result for the same risk. Review the criteria against the organization's risk appetite and tolerance statements, and record any calibration decisions made after an incident or an audit finding. Assessors often test whether a high-priority risk was handled before a lower-priority one.

Records of communication to risk owners

A method nobody has heard of is not in use. Keep records showing that the method was briefed to risk owners, such as training attendance, meeting minutes, email distribution with acknowledgment, or sign-off on the register's ownership fields. Tie each communication to the version of the method it covered. When the method changes, repeat the communication and file the new record alongside the change log.

Sampled risk entries applying the method

Assessors usually select a sample of register entries and trace each one back through the criteria, the category list and the approved method. Each sampled entry should show a consistent rating, a category from the shared list, a treatment decision and a named owner. Prepare a short index of entries with the method version used for each. Any entry rated with an older method version should carry an explanation of when and why it was re-rated.

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

This table lists each cost component of building a standard risk calculation method, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote and to see where a self-hosted open-source GRC platform can remove license spend. No cost figures are given because none were supplied for this subcategory.

Cost component	One-time or recurring	What drives it up or down	How to reduce it
Policy and method design	One-time, with periodic review	Number of risk categories, how many business units must agree, and whether quantitative formulas are required or qualitative scales are enough	Start from a scale your leadership already uses, document the formulas once, and ask the partner to quote design as a fixed deliverable
Tooling or licenses	Recurring if commercial, one-time if self-hosted	Per-user or per-module license terms for commercial GRC suites, and hosting capacity for self-hosted platforms	Self-hosted open-source GRC software, such as CISO Assistant (AGPL-3.0-only), can remove license spend; confirm hosting, backup and upgrade costs in your own environment
Risk register setup	One-time, with migration effort if data moves	Volume of existing risk data, quality of asset inventories, and how many fields the register template must hold (description, exposure, treatment, ownership)	Clean the source data first, limit the register to fields NIST's Implementation Examples call for, and confirm which data import formats the platform accepts
Quantitative analysis effort	Recurring at each assessment cycle	Whether likelihood and impact are modeled with numbers, the availability of loss data, and the number of scenarios analyzed	Limit quantitative work to the highest-priority risks and use qualitative ranking elsewhere, as the prioritization criteria allow
Training or briefings for risk owners	Recurring as owners and roles change	Number of risk owners, turnover, and whether the shared risk categories are new to them	Run one shared briefing on the categories and register, then record attendance and reuse materials for new staff
Evidence upkeep	Recurring	How often risk entries, scores and treatment decisions change, and whether evidence is kept in the register or in separate files	Keep the register as the single record, set review dates per entry, and log changes automatically where the platform supports it
External review or facilitation	Usually one-time per engagement, sometimes recurring	Scope of the independent review, whether a facilitator runs workshops, and the number of sessions needed	Ask for a written scope with named deliverables; an independent assessor issues any formal conclusion, so confirm that role separation before signing

Who owns the risk method, who helps build it and who tests it

Your organization owns the method. The risk owner, usually a senior executive, approves the method and the impact and likelihood scales and accepts residual risk. The CISO function maintains the method document, runs the risk register and sets the review cadence. Business owners define what each impact level means in their own terms, such as financial loss, service disruption, customer harm or regulatory exposure, and confirm the ratings for the systems they run. Because these people make the decisions, they must be able to explain every rating without help from anyone else.

Risk owner: signs off the method, the scales and the category list, and accepts residual risk on the organization's behalf.
CISO function: keeps the method current, maintains the register and schedules reviews.
Business owners: translate impact levels into their operations and confirm ratings for their systems.
Enterprise risk or finance: checks that cyber scales can be compared with other enterprise risks, as described under GV.RM-03.
Records owner: keeps approvals, version history and meeting notes that an assessor will request.

Check that each named role has approved the method in writing and that an internal staff member can explain any rating in the register.

Where organizations usually fall short on a standard risk method

GV.RM-06 asks for one method that calculates, records, categorizes and prioritizes cybersecurity risk, and that the organization communicates. Most shortfalls are not missing documents. They are gaps between the written method and how risks are actually scored, recorded and passed to the people who own them.

Scales without written criteria

A likelihood scale labeled High, Medium and Low is only useful if each level has a written definition that two assessors would apply the same way. Without it, one team reads High as more than a quarter chance in a year and another reads it as a feeling. Closing action: write a definition, an example and an evidence expectation for every level of likelihood and impact, then test the scale by having two people score the same three risks and compare results.

Different teams, different formulas

Security, IT operations and business units often score the same risk with different formulas, so a supplier outage can rank as critical in one register and moderate in another. The result is contested priorities at steering meetings. Closing action: publish one calculation formula, name the owner who maintains it, and require every register entry to show the inputs used so the score can be reproduced.

Quantitative analysis claimed, not applied

Many method documents say risks will be quantified in financial terms, yet the register holds only ordinal ratings. Quantitative analysis needs defined criteria, such as which loss types are modeled, which data supports the input estimates and how uncertainty is shown. NIST's Implementation Examples for GV.RM-06 describe criteria and formulas for this analysis. Closing action: pick the risks where quantification changes a decision, document the formula and inputs for each, and remove the claim for everything else.

Register missing treatment and ownership

A risk register that records a description and a score but not the chosen treatment, the accountable owner or the review date cannot show that anyone decided what to do. Assessors testing GV.RM-06 look for these fields because they link the method to action. Closing action: add mandatory fields for exposure, treatment (accept, mitigate, transfer or avoid), named owner and next review date, and block entries that leave any of them blank.

Risk categories that drift

Teams add categories such as Cloud, Third party or Cloud vendor to a register over time, and older entries keep the original labels. After two years, trend reporting counts the same exposure under several names. Closing action: keep one controlled list of risk categories with an owner and a change log, map any legacy labels to the current list once, and review the list on a fixed schedule.

Method never communicated to risk owners

A method stored in a policy library does not help a system owner who is asked to score a risk without guidance. Owners then guess, skip fields or send scores back for rework. Closing action: brief each risk owner on the scales, formula and categories, provide a one-page scoring guide and worked example, and confirm acknowledgment in the same way you track policy reviews.

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

How long does it take to produce a standard risk calculation method?

No duration is published for this work, so the honest answer is that the timeline depends on the inputs you already have. The method itself is a set of decisions: how you calculate likelihood and impact, whether you use quantitative criteria or a qualitative scale, how you record each risk, how you rank risks, and which risk categories you share across departments. Teams with an existing enterprise risk process and a current asset inventory usually have most of the raw material, so the work is mostly agreeing definitions. Teams starting from scratch need more time for stakeholder workshops, sign-off from leadership and a pilot against real risks. Ask any partner to break the work into written phases with named deliverables before agreeing a timeline.

Can our team write a standard risk method without outside help?

Yes, most organizations can, provided the right people are in the room. NIST describes GV.RM-06 as a method that is set and communicated, so it does not require a specialist to exist, only a consistent approach that the organization owns. Internal teams usually handle the risk register template, category list and prioritization criteria well. Outside help tends to add value when the method must be tested against quantitative analysis, when several business units need one scale, or when the team lacks time to pilot the method on live risks. Whichever route you choose, the approval and ownership of the method stays with your leadership.

What does the work require from our organization?

The main requirement is decision-making time from people who own risk. Expect to need a sponsor who can approve the method, risk owners who will agree how their risks are scored, and staff who maintain the asset and threat information the method depends on. NIST's Implementation Examples point to four areas: quantitative analysis criteria and formulas, a register template that records description, exposure, treatment and ownership, prioritization criteria, and a consistent list of risk categories. Each one needs a named owner and a review date. Confirm with your own risk and audit functions which existing policies, registers and reporting lines the method must align with before the work starts.

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

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. The CSF is a voluntary framework, so there is no NIST certificate for GV.RM-06 or any other Subcategory. If a customer or contract asks for evidence, the organization shows its own method, records and reviews, and an independent assessor may test them if the requirement calls for that. An implementation partner can prepare the documents and systems, but only an independent auditor or assessor issues a report, and that report is outside the partner's role.

Can a self-hosted open-source GRC tool hold our risk register?

Often yes, but confirm the fit before you commit. A self-hosted GRC tool can store the register template, record ownership and treatment for each risk, keep a history of changes and produce reports for leadership. The CISO Assistant project, licensed under AGPL-3.0-only, includes risk and assessment features and ships many frameworks, including NIST CSF, but you should verify which risk fields, scoring formulas and category lists it supports in your version. Check how it handles custom scales, role-based access, audit logs, backups and upgrades inside your own infrastructure. Keep the method document separate from the tool, so a tool change does not change how risks are scored.

What should a written scope include before we hire a partner?

A written scope should name the deliverables, the systems in scope, the people who approve each deliverable and the acceptance criteria. For GV.RM-06, list the quantitative analysis criteria, the risk register template, the prioritization criteria and the risk category list as separate deliverables, along with the tool or workspace that will hold the register. State who owns each decision, which business units are included, how many review rounds are covered and what happens to work that is out of scope. Confirm whether the partner will also support evidence collection for an assessor, and make clear that an independent auditor, not the partner, issues any report. DeployOpen works on fixed scopes agreed in writing before work starts, and a quote follows from that scope.

What drives the cost of building a standard risk method?

Cost follows the amount of decision work and the number of people paid to do it. There is one-time effort to design the method, build the register template, set scoring criteria and run a pilot. There is recurring effort to review risks, update categories and keep the register current, which is usually handled by your own risk function. Costs rise with the number of business units, the depth of quantitative analysis, the number of systems feeding the register and the amount of tool configuration. Ask any provider to price the one-time design separately from recurring support, and to state which deliverables are fixed and which depend on your review cycles.

How DeployOpen works on this

DeployOpen helps organizations set up the systems, templates and records that show a standard cybersecurity risk method is in use for GV.RM-06. The organization owns its risk method and decides its criteria, while DeployOpen prepares the self-hosted tooling and evidence inside the client's own infrastructure.

How we scope

Engagements are fixed-scope, with the GV.RM-06 deliverables and timelines agreed in writing before work starts.
The written scope names which risk calculation criteria, formulas and prioritization rules the organization has chosen to adopt.
Scope also lists which risk categories, register fields and business units the shared method will cover.

How we build

Configure a self-hosted risk register with fields for description, exposure, treatment and ownership, matching the agreed method.
Build the shared list of risk categories and map each category to owners, scoring criteria and review cycles.
Test the register workflow with sample risk entries so calculation, categorization and prioritization can be checked end to end.

How we hand over

Deliver written documentation of the risk method, its formulas, categories and prioritization steps for the organization to approve.
Provide exported register records and change history that an independent assessor can sample during testing.
Confirm with the organization and its assessor which evidence formats they accept before handover is closed.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainer support can cover register updates when the organization revises its risk criteria or categories.
An independent auditor or assessor, not DeployOpen, decides whether the evidence meets the organization's goals for GV.RM-06.