NIST CSF 2.0 GV.RM-06: Use One Method to Score Risk

GV.RM-06 says a standardized method for calculating, documenting, categorizing and prioritizing cybersecurity risks is established and communicated. Everyone scores and records risk the same way, so risks can be compared, summed and ranked. Without that, a risk register is just a list of worries.

What good looks like

A written method that fits on a page. A single register template with fixed fields. A shared list of risk categories. Clear rules for turning likelihood and impact into a priority. Everyone who adds a risk uses the same form and the same scale, and the top of the list matches what leaders consider most dangerous.

NIST's examples cover four elements: criteria for quantitative approaches with probability and exposure formulas, templates such as a risk register that capture description, exposure, treatment and ownership, criteria for prioritization at appropriate levels, and a consistent list of categories for aggregation and comparison.

How to implement it

1. Choose the scale. A simple five by five matrix is fine to start. Define each level in words and, where possible, in money or customer impact, so two people scoring the same risk land near each other.
2. Decide when to be quantitative. For a few big risks, estimating annual probability and loss in money gives leaders something they can compare to insurance or a budget line. For the long tail, qualitative scores are enough. State the rule.
3. Build the register template. Minimum fields: ID, description, category, affected asset or service, likelihood, impact, score, owner, treatment decision, due date, status and last review.
4. Fix the category list. Technical, third party, legal, people, process and physical is a workable start. Keep it short so people can choose without debate.
5. Set prioritization rules. Which score triggers a treatment plan, which goes to leadership (see GV.RM-03) and which can be accepted within tolerance (see GV.RM-02).
6. Publish the method and train the people who will use it. Do a calibration session where several people score the same three risks and compare.
7. Review the register on a schedule and close or re-score stale entries.

Evidence to collect

• The written risk method with scales and criteria.
• The register itself with filled fields, owners and dates.
• Calibration session notes or another record of consistent use.
• Evidence of prioritization in action, such as a treatment plan opened for a top risk.

Common gaps

• Scoring is subjective and varies by author.
• The register has a description and nothing else: no owner, no date, no decision.
• Categories multiply until aggregation is meaningless.
• Risks are logged and never revisited.
• Vulnerability scanner output is dumped into the register, burying real business risks under thousands of rows.

Keeping scanner noise out

Findings from tools belong in a vulnerability workflow, not the strategic register. Roll them up into a handful of risk statements, such as "unpatched dependencies in the customer API" with a score and an owner. Reachability analysis helps here, since it shows which vulnerable dependencies your code actually calls, so the risk statement describes real exposure and not a raw count.

Working through a register

The demo walks through adding risks to a register, scoring them and assigning owners and treatments, the way the template above is meant to be used.

Calibrating the scale

Define impact levels with concrete anchors for your company. For a fifty person software firm, a score of three might mean a day of downtime for one customer or exposure of non sensitive internal data. A score of five might mean a multi day outage for all customers or loss of regulated personal data. Likelihood anchors work the same way: five could mean it is expected to happen this year, one could mean less than once in a decade. Anchors turn arguments about adjectives into discussions about facts.

Documenting treatment

Each register entry should end in a decision: reduce, accept, transfer or avoid, following the direction set under GV.RM-04. For reduce, link the work item and due date. For accept, record the approver and an expiry. The register becomes an audit trail of choices, which is what customers and auditors want to see.

A one page method

If you have nothing today, start with this. Score likelihood from one to five and impact from one to five using the anchors above. Multiply for a score out of 25. Scores of 15 and above need a treatment plan within 30 days and leadership visibility. Scores of 8 to 14 need an owner and a review each quarter. Scores below 8 can be accepted by the owner with a note. It is crude, and that is fine, because the value comes from everyone using the same crude method and refining it together.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST Cybersecurity Framework 2.0 Reference Tool, subcategory GV.RM-06: https://csrc.nist.gov/projects/cybersecurity-framework/filters
• NIST Cybersecurity Framework overview: https://www.nist.gov/cyberframework

The CSF is voluntary guidance. There is no CSF certification, so this post describes how to work toward the outcome, not how to pass an audit.