ID.RA-05 says threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization. The answer in practice: take the inputs you recorded in ID.RA-01, 03, and 04, combine them into a ranked list, and let that ranking decide where time and budget go first.
Inherent risk means the risk before your controls are counted. Looking at it first stops you from rating something Low only because a control exists that nobody has tested.
What good looks like
Someone can explain why this quarter's security work is what it is. The top items on the roadmap trace back to ranked risks, not to whatever vendor pitch arrived last or whichever scanner finding is loudest.
NIST's examples are two: develop threat models to understand risks to data and pick suitable responses, and prioritize cybersecurity resource allocation and investment based on estimated likelihood and impact.
How to implement it
- For each scenario in your risk register, score inherent risk by assuming controls fail. Then score residual risk with the controls you can show are working.
- Build a simple threat model for your most valuable data. Draw where it enters, where it is stored, who and what can touch it, and where it leaves. List what could go wrong at each step.
- Rank scenarios by inherent risk, then by how cheaply you can reduce them. A cheap fix for a High risk goes first.
- Tie the budget request or the engineering plan to the ranking. A line such as "Item 3 on the register, estimated High, addressed by MFA on contractor accounts" is the traceability an assessor looks for.
- Re-rank when inputs change, for example after an incident, a new product launch, or a new exploited vulnerability in a package you ship. Reachability analysis helps here because it shows whether a vulnerable function in a dependency is actually called by your code, which changes likelihood.
A short example
Two risks both score Medium after controls. One relies on a firewall rule that nobody has tested in two years. The other relies on MFA that is audited monthly. Their inherent risk is the same, but the first depends on a weak control. Scoring inherent risk exposes that, and the first one moves up the list for retesting.
Evidence to collect
- A ranked risk list showing inherent and residual scores
- At least one threat model for a critical data flow
- A roadmap or budget document that references the ranked items
- Notes showing the ranking changed after new information
Common gaps
- Only residual risk is scored, which hides weak or untested controls
- Priorities are set by severity labels from tools, with no business context
- Threat models are drawn once during design and never reused
- Ranking exists but spending decisions ignore it
Quick check
What is the difference between inherent and residual risk?
Inherent risk is the level before any controls. Residual risk is what remains after controls are applied. Tracking both shows how much you depend on each control.
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.
