ID.RA-04 says the potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded. The simplest way to meet it is a risk register where each entry names a scenario, estimates how likely it is, estimates how bad it would be for the business, and has a named owner. If the estimates live in an email thread, they are not recorded.
What good looks like
A risk register that business leaders have actually looked at. NIST's own example says business leaders and cybersecurity practitioners work together to estimate likelihood and impact and record them in risk registers. The security team alone guessing at business impact is a common failure.
Good entries are scenarios, not scanner output. "Attacker uses a stolen contractor credential to read customer files" is a scenario. "CVE found in library X" is a finding that might feed one.
NIST also lists two more examples worth taking seriously. Enumerate the potential business impacts of unauthorized access to your communications, systems, and the data they process. And account for cascading failures across systems that depend on each other, such as an identity provider outage that also locks you out of your ticketing and paging tools.
How to implement it
- Pick a simple scale. Three levels for likelihood and three for impact is plenty. Define each level in a sentence so two people score the same way. For example, impact High might mean more than a day of outage for a key customer service or exposure of regulated customer data.
- Draft scenarios from your threat list (ID.RA-03) and your known weaknesses (ID.RA-01). Aim for 10 to 20 scenarios, not 200.
- Hold a 60 minute session with someone from finance or operations, someone from engineering, and whoever owns customer relationships. Ask what a bad day would cost in money, time, trust, and legal exposure.
- Record the likelihood, the impact, and the reasoning in one line. The reasoning matters more than the number because it lets the next reviewer challenge it.
- Look for dependencies. For each critical system, note what else breaks if it fails. That is how you capture cascading failure.
- Set a review date. Quarterly is a fair rhythm for a small company, plus a review after any major incident or architecture change.
Try it yourself
This walkthrough shows a register being built from scenarios, with likelihood, impact, owners, and treatment.
Click through it at your own pace, or open it full screen.
A worked example
Take a company of 60 people with one customer facing web app and a cloud hosted database. A scenario in the register might read: "A contractor's stolen credentials are used to download the customer table."
Likelihood: Medium. Contractors use personal laptops and MFA is on, but one legacy account still uses a password only.
Impact: High. The table holds customer contact details and contract terms. Notification duties would apply in several states, the two largest customers have breach clauses in their contracts, and the engineering team would spend roughly two weeks on response instead of the roadmap.
Owner: the head of engineering. Next review: end of next quarter.
Notice what makes this useful. The reasoning is short, specific, and checkable. Someone from finance can read it and say the contract clause detail is wrong, or that the cost estimate is low. That conversation is the real value of the outcome.
Also write the "not yet known" items. If you cannot say how many customer records the table holds, record that as an open question with an owner. Gaps in knowledge are a risk input too.
Evidence to collect
- The risk register with likelihood, impact, owner, and last reviewed date
- Meeting notes or an invite showing business stakeholders took part
- Your scoring scale definitions
- A dependency map or list for critical systems
- Version history showing the register changes over time
Common gaps
- Scores with no reasoning, so nobody can tell why a risk is rated High
- Only technical impact is recorded, such as "server down", with no business consequence
- Likelihood is guessed once and never revisited after threats change
- Cascading failures are ignored because each system is assessed alone
- The register belongs to one person who is the only one who ever opens it
Quick check
Do we need numbers, or are High, Medium, Low enough?
The outcome does not require a numeric model. Consistent, defined levels that leaders understand are enough. Move to dollar estimates only if you have the data and a decision that depends on them.
Who should own a risk entry?
The person who can decide how to respond, usually a business or engineering lead. The security team can coordinate the register, but ownership by someone with authority is what makes the response in ID.RA-06 actually happen.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (February 2024), Appendix A, CSF Core: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 landing page: https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
The CSF is voluntary guidance. There is no CSF certification, so nothing here makes a company "CSF certified". You describe your own practices against the outcomes.
