ID.RA-05 inherent risk: requirements and evidence

What ID.RA-05 asks for and why the NIST CSF 2.0 risk assessment is hard to show

ID.RA-05 asks the organization to combine threats, vulnerabilities, likelihoods and impacts so that it understands its inherent risk and can prioritize risk responses. It is a Subcategory of the Risk Assessment (ID.RA) Category in the Identify Function of NIST CSF 2.0, and it carries the same identifier as CSF 1.1 ID.RA-5, so a compliance lead can trace the outcome from the earlier version without renumbering. NIST publishes two Implementation Examples for it: one on developing threat models to understand risks to data and choose responses, and one on prioritizing resources and investment by estimated likelihood and impact. Those examples are the closest thing to a checklist, and they describe what good looks like rather than a required method.

The difficulty is that the outcome is about consistency. An assessor will not accept a single workshop that ranks a handful of systems. They will look for one scoring approach applied across assets, with threat and vulnerability inputs traceable to the sources that informed them, and with the resulting ranking feeding the risk register and the response decisions recorded under ID.RA-06. If each business unit scores differently, or the ranking never reaches the register, the outcome is hard to demonstrate even when the team is working hard. Confirm early whether your existing risk method already produces comparable inherent risk ratings across asset classes, because retrofitting consistency later is usually the costly part.

Because NIST does not certify anyone and offers no conformity assessment program, no external body will issue a badge that says ID.RA-05 is met. Your organization owns the scoring method and its outputs. An implementation partner can help build the method, populate the threat models and connect the ranking to the register, but only an independent assessor can give an opinion on it, and only if you can produce the records. Ask any partner or assessor to show you which artifacts they will sample, such as the threat model, the scoring criteria, the prioritized list and the dated decisions that followed, before you commit to the scope.

Which systems, data, teams and suppliers ID.RA-05 covers

Inherent risk scores are only as complete as the scope behind them. The decisions below determine which assets, threats, processes and suppliers feed the likelihood and impact estimates that drive ID.RA-05 prioritization, and each one changes how much work the scoring takes.

Asset inventory as the starting point

Every score begins with a list of assets, so gaps in the inventory become blind spots in the risk ranking. Check whether hardware, software, cloud services and data stores are all recorded, and whether each entry carries an owner and a data classification. The number of assets and how often the inventory changes set the refresh workload for every score. Ask how new assets reach the register before they go live.

Internal and external threat sources

Threat modeling must cover both outside actors and people already inside the organization, such as staff, contractors and privileged administrators. Each threat source adds scenarios to score, and scenarios multiply when threat intelligence on likely actors is added. Decide which sources are in scope for each system before scoring, and record why any source was excluded so an assessor can follow the reasoning.

Business processes whose impact is estimated

Likelihood alone does not set priority. Impact depends on the business processes that a system supports, such as payments, patient records or production scheduling. Identify which processes depend on each asset, who can state the financial, operational and legal consequences of disruption, and how often those impact statements are reviewed. A larger process map raises the effort to estimate impact but reduces the chance that a high-consequence system is scored too low.

Supplier services that carry risk

Cloud platforms, managed service providers and software vendors can create inherent risk that sits outside the organization's own systems. Decide which supplier services are included in the scoring, and whether a supplier's failure is scored as a dependency of a business process. The number of critical suppliers and the depth of their own supply chains determine how much data must be gathered for each estimate. Confirm how supplier risk data is refreshed when contracts change.

System boundary for the risk register

The boundary defines which systems, networks and data flows appear in the risk register and which are treated as external dependencies. A narrow boundary keeps the register manageable but can hide cascading failures between systems. A wide boundary captures more interactions at the cost of more entries to score. Document the boundary in writing, state which data classifications fall inside it, and confirm that scores are refreshed when the boundary moves.

How an assessor tests ID.RA-05 and what usually fails

This table compares five areas an independent assessor examines for ID.RA-05, the test approach, the evidence requested and the findings that appear most often. Read each row as a question the assessor will ask the owner of the risk process, and check your own records against the evidence column before the review begins.

Test area	Test approach and evidence requested	Common findings
Risk method and scoring criteria	The assessor reviews the written method for estimating likelihood and impact, the scale definitions, and who approved them. They ask for the scoring criteria and a sample of scored risks to confirm the method was applied as written.	Scoring scales exist but are not defined tightly enough for two analysts to reach the same score. Criteria are dated or owned by no one.
Threat model for a sample of systems	The assessor selects systems with the owner and reviews the threat models, including the data flows, threat actors considered and the responses chosen. They interview the system owner about how the model informed design decisions.	Threat models are produced once at design and never revisited. Models describe generic threats without reference to the system's actual data or dependencies.
Link between scores and the risk register	The assessor traces sampled scores from threat models and vulnerability records into the risk register, checking that the inherent score, its inputs and its owner are recorded together.	Scores in the register cannot be traced to the inputs that produced them. Threat model findings never reach the register, so high-risk scenarios are missing.
Prioritization of responses and investment	The assessor compares the ranked list of risks with the list of funded or scheduled responses. They ask how likelihood and impact determined the order and request the decision record for a sample of deferred items.	Priorities follow asset importance or the loudest stakeholder and ignore likelihood. Deferred high-impact items have no recorded rationale.
Score refresh after changes	The assessor asks for evidence that scores were revisited after significant changes such as new systems, new threat intelligence or material vulnerabilities, and reviews the change records that triggered reassessment.	Scores are reviewed on a calendar cycle only. Changes to architecture or new threat reports do not trigger any update to inherent risk.

How threat modeling feeds inherent risk scores

A threat model for a system or data set answers three questions before anyone scores anything: who or what could act against it, which paths those actors could take to exploit a weakness, and what would happen to the data involved if they succeeded. For ID.RA-05, the first of NIST's two Implementation Examples asks for exactly this kind of model, built to understand risks to data and to choose responses. In practice, the team lists threat sources such as external criminal groups, malicious insiders, misconfigured integrations and failed third-party services, then traces each path from the source through an entry point, such as an exposed API, a privileged account or a build pipeline, to the records or processes at stake. The output is a set of named scenarios, each tied to a specific data asset and a plausible impact, which can be carried into the risk register.

Inherent risk is the score a scenario carries before the effect of existing controls is credited. That discipline matters: if a scenario is scored after assuming MFA, encryption and monitoring already work, the result hides the exposure those controls exist to reduce. Teams should record the inherent likelihood and impact with the assumptions behind them, then list the controls that currently act on each scenario as a separate input. Ask the owner of each data set to confirm the impact estimate, and confirm with the people who run the systems which entry points are truly reachable. The residual view, which subtracts what controls actually achieve, comes later under the response Subcategories, notably ID.RA-06, where choices to accept, transfer, mitigate or avoid are planned and tracked.

Implementing inherent risk scoring step by step

This sequence turns ID.RA-05 into a repeatable routine: a documented scoring method, an inventory of what is being scored, threat models for priority systems, a combined inherent score, a ranked list tied to funding decisions, and a review cycle that reacts to change.

Fix the scoring method and scales
Risk owners, the CISO function and business leads agree on how threat, vulnerability, likelihood and impact will be rated, including the numeric or qualitative scales, the rules for combining them and the thresholds that separate priority levels. Record the method in a short document that names who approves changes to it. The step is complete when the method is approved and every scale has a written definition that two different assessors would read the same way. Your risk management strategy under GV.RM should already set the risk method this step relies on.
Build or confirm the asset and data inventory
Confirm that the systems, applications, data sets and supplier services in scope are listed with an owner, a business function and the data classes they hold. Inherent risk cannot be scored for assets nobody has recorded, so gaps here distort every later step. Data flows between systems should be visible enough to show where a threat could reach sensitive data. The output is an inventory extract covering the scoring scope, reviewed by the asset owners who will answer for those entries. This work usually draws on the ID.AM inventories.
Run threat models for priority systems
For the highest-value systems, the security team and system owners walk through how an attacker or failure could reach the data and services, using a structured method such as a data flow diagram with threats listed per component. NIST's Implementation Examples for ID.RA-05 describe developing threat models to understand risk to data and choose responses. The output is a threat model record per priority system that names the threat scenarios, the affected assets, the existing controls and the open questions. Ask each team which threat actors they assumed and why, since assumptions drive the likelihood ratings in the next step.
Combine threat, vulnerability, likelihood and impact
For each threat scenario, pair it with the vulnerabilities found through ID.RA-01 and ID.RA-02 and rate the likelihood and business impact using the approved scales. The combined rating is the inherent risk: the level before any planned response is applied. Record the rating, the evidence behind each input and the assessor's name in the risk register. The output is a scored register extract in which every row traces back to a threat model, a vulnerability record and an owner. Scores that cannot be traced to evidence should be marked as provisional rather than presented as settled.
Rank risks and link the ranking to response and budget
Sort the scored risks by the approved priority thresholds, then review the top of the list with the risk owners and finance or executive sponsors. The NIST implementation example on prioritizing resources and investment by estimated likelihood and impact is the basis for this discussion. Each ranked item should carry a proposed response under ID.RA-06 and an estimate of the work needed to act on it, so decision makers can see what they are funding. The output is a signed-off priority list, with the approver and date recorded and any items deferred or accepted noted with a reason.
Set a review cycle triggered by change and intelligence
Agree how often the register and threat models are re-scored, and list the events that force an earlier review, such as a major system change, a new threat advisory affecting your technology, a significant incident or a change in supplier services. Route these triggers through the ID.RA-07 change process so scores update when the environment does. The output is a documented review schedule and trigger list, and a dated record of the most recent review. Confirm the cadence with your governance body, since the frequency that suits a regulated bank may differ from that of a small public body.

Evidence that passes ID.RA-05 and how to keep it current

An assessor testing ID.RA-05 looks for proof that threats, vulnerabilities, likelihoods and impacts were combined into inherent risk scores and that those scores drove priorities. The six artifacts below connect method, analysis, ranking and decisions, and each one needs a routine that keeps it current between assessments.

Documented risk method and scales

The written method defines how threats, vulnerabilities, likelihood and impact are scored and combined into an inherent risk rating, including the scale definitions (for example, what a "high" likelihood means). Assessors check that the method exists before they check any scores. Keep it under version control, record an approver and date for each version, and review it at least once a year and after any major change in the risk environment. Store every superseded version so older rescores can be explained against the method that produced them.

Threat model records per system

Threat models show how the organization identified threats to each system or data set and chose responses, which is the first Implementation Example NIST publishes for ID.RA-05. Each record should name the asset, its data classification, the threats considered, the attack paths and the responses chosen. Update the record when the architecture changes, when a new integration is added or when threat intelligence shows a relevant new technique, and date each revision so the assessor can see when the model last reflected reality.

Risk register extract with scores and rationale

A register extract lists risks with their inherent scores and the reasoning behind each score, so an assessor can trace a rating back to the threat, vulnerability and impact evidence. Pull the extract at a fixed date and keep a copy. Rationale fields matter more than the numbers: a score with no stated basis will not show that likelihood and impact were actually weighed. Confirm with your GRC tool whether it keeps history of score changes or whether you must export snapshots yourself.

Prioritized list with date and approver

The prioritized list shows the order in which risks will receive resources, with the date it was produced and the name of the person who approved it. It is the output that ties ID.RA-05 to the second NIST Implementation Example, which covers prioritizing resources and investment by estimated likelihood and impact. Re-issue the list on a set cycle and whenever the register changes materially, and keep prior versions. Missing approval records are a common reason an otherwise sound ranking is not accepted as evidence.

Change records showing rescoring

Change records show that a risk was rescored when something changed, such as a new vulnerability on an asset, a shift in threat actor activity or a control that was deployed or retired. Each record should note the trigger, the old and new inherent scores, the reviewer and the date. Link these records to the change and exception process described under ID.RA-07 so the rescoring is traceable. Assessors often sample changes to test whether the register reflects the environment as it was on a given day.

Governance minutes linking rankings to investment

Meeting minutes and recorded decisions show that leaders reviewed the prioritized risks and made funding or resourcing choices based on them. The record should name the risks discussed, the decision taken and the owner of any follow-up. Assessors use these records to judge whether ID.RA-05 feeds real governance rather than sitting in a spreadsheet. Schedule a standing agenda item for the risk review and keep the minutes, because a ranking that never reaches a decision-maker is hard to defend.

What meeting ID.RA-05 costs in money and effort

This table lists the cost components of meeting ID.RA-05, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to see where open-source tooling removes license spend and where staff time remains, then ask each vendor or partner for a written, fixed-scope quote with named deliverables.

Cost component	One-time or recurring	What drives it	How to keep it down
Risk method design	One-time, revised periodically	Number of business units, existing risk scales, and how many risk decisions must be traceable to ID.RA-05 outcomes	Reuse an existing enterprise risk method and document only the scoring rules that ID.RA-05 needs
Asset and data inventory build	One-time, then recurring upkeep	Number of systems, data stores and data flows that threats and impacts must be attached to	Start from an inventory already maintained under ID.AM and limit the first pass to business-critical systems
Threat modeling effort per system	Recurring, per system and per material change	System complexity, number of trust boundaries, and whether threat models are produced in-house or by an outside team	Use a common template, scope models to systems with sensitive data, and reuse models across similar services
Tooling or licenses for the risk register	Recurring license or hosting cost, or none for self-hosted open source	Commercial GRC licenses priced per user or module, hosting in your own cloud, and integration needs	Self-host open-source GRC software to remove license spend, but budget staff time for administration and configuration
Engineering time to connect scanner and intelligence feeds to scores	One-time integration, recurring maintenance	Number of scanners and feeds, data formats, and how often scores must refresh	Standardize on a few feeds, map severity fields once, and automate ingestion where tools support it
Evidence upkeep	Recurring	Frequency of re-scoring, how many prioritization decisions are recorded, and retention periods set by your own policy	Record decisions at the point of change in the register rather than rebuilding them before each assessment
External review or threat modeling support	Optional, one-time or recurring	Whether internal teams lack threat modeling skills, and whether an outside reviewer is needed to challenge scores	Ask for a fixed-scope review of the method and a sample of models, not open-ended support
Auditor sampling	Recurring at each assessment cycle	Number of prioritization decisions sampled, how traceable the links are from threats to responses, and how the auditor chooses samples	Ask the auditor for its sampling approach early and keep each scoring decision linked to its inputs and approver

Who owns ID.RA-05 and what an implementation partner can take on

Your organization owns ID.RA-05 in full. Only your people can decide how threats, vulnerabilities, likelihoods and impacts are combined, which scores are accepted as the inherent risk view, and which risks are prioritized for response. NIST's CSF 2.0 Core describes outcomes, not a scoring method, so the risk method is a choice your leadership must document and defend.

Risk method: Define the scale, scoring formula and the criteria for likelihood and impact, and approve them as part of your risk management strategy.
Score acceptance: Review and accept the inherent risk scores and threat models before they drive decisions. A partner's draft is not your sign-off.
Response decisions: Decide which risks are mitigated, transferred, accepted or avoided, and who holds each decision.
Register ownership: Keep the risk register as the system of record, with named owners, review dates and links to ID.RA-06 response tracking.
Budget and priority: Approve the resource and investment priorities that follow from the scores.

Before engaging anyone, confirm that a named executive owns the risk method and that the register can be exported for an assessor.

Where organizations fall short on inherent risk prioritization

Most organizations that score risk already have threat models, vulnerability lists and likelihood estimates somewhere in the program. The gaps appear where these inputs fail to connect: in a method nobody can reproduce, in models that stay in a workshop folder, or in rankings that never reach a budget decision. Each card below names one gap and the action that closes it.

Scores that cannot be reproduced

A score is only useful if a second assessor, given the same inputs, arrives at the same result. Many programs assign High or Medium ratings without writing down the scale, the factors weighed or the threshold that separates one rating from another. Close this by documenting the scoring method, including the likelihood and impact scales, the formula or matrix used to combine them and the owner who approves changes. Evidence: a versioned method document, plus a sample of scored risks that a reviewer can recalculate by hand.

Threat models that never reach the register

NIST publishes an Implementation Example for ID.RA-05 that calls for threat models to inform risk understanding and response choices. In practice, threat models often stay in architecture reviews and never create or update entries in the risk register. Close this by requiring each threat model to list the risks it identifies, with a register ID and a score, before the model is marked complete. Evidence: a traceable link from each threat model to its register entries, and register records dated after the model was approved.

Likelihood ignored when ranking

Ranking by impact alone pushes rare but severe scenarios to the top and hides frequent, moderate ones. The Implementation Example for ID.RA-05 links prioritization to estimated likelihood and impact together. Check whether your ranking formula uses both factors, and whether the likelihood estimate has its own basis such as threat intelligence, incident history or control testing results. Evidence: a ranked list showing both factors, with the basis recorded for each likelihood value.

Inherent and residual scores blurred

Inherent risk is the exposure before controls are applied, and residual risk is what remains after them. When a program records only one score, reviewers cannot tell whether a control is doing work or whether the underlying exposure is small. Close this by recording inherent and residual scores as separate fields, with the controls credited in the residual score named explicitly. Evidence: a register that shows both scores for each risk, and a control reference for every reduction in the residual score.

Rankings that do not drive budget

A prioritized list has no effect if funding and staffing decisions are made on other grounds, such as the loudest executive request or the last audit finding. Close this by linking the top-ranked risks to named response decisions (accept, transfer, mitigate or avoid) and to the budget line or work item that funds each mitigation. Evidence: meeting minutes or planning records that show top-ranked risks reviewed against budget requests, with the outcome of each decision recorded.

Stale scores after architecture changes

Scores set during a design review can become wrong after a new integration, a cloud migration or a change in a third-party service. Because ID.RA-07 covers changes and exceptions separately, the ID.RA-05 question is whether a change triggers a re-scoring of the affected threats and vulnerabilities. Close this by naming the change types that require re-scoring and recording the date of the last review for each scored system. Evidence: change tickets that reference the affected risk entries, and review dates in the register that are later than the most recent architecture change.

Questions buyers ask about ID.RA-05 cost, effort and outside help

Can we meet ID.RA-05 in-house without an outside partner?

Yes, many organizations do. ID.RA-05 asks that threats, vulnerabilities, likelihoods and impacts be combined to understand inherent risk and set response priorities, and an internal risk team with the right data can do that. The harder question is whether your team has the time, the threat modeling skills and the independence to run it well. Ask whether the people who own the systems can state their own risk, and whether someone outside those systems reviews the ranking. If either answer is no, an outside partner can help with the groundwork, but the organization still owns the risk decisions.

What drives the effort of an ID.RA-05 risk prioritization?

Effort follows the number of systems, data flows and threat scenarios in scope, and how mature your inventories and vulnerability records already are. Teams with a current asset inventory and recorded vulnerabilities spend less time on setup. Effort rises when:

Asset ownership, data classification or dependencies are unclear
Threat models must cover many business processes or third parties
Likelihood and impact estimates have no agreed scales or evidence
Several teams must agree on one ranking and a single risk register

For a fixed scope, ask the provider to list which systems, threat models and workshops are included before work starts.

Does NIST certify that we comply with ID.RA-05?

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 voluntary for most organizations, so any claim of alignment is a statement your organization makes and can support with evidence. If a customer or regulator asks for proof, the evidence is your documented threat models, scored risk register and the prioritization decisions made from them. Be cautious with any vendor or consultant that offers a NIST certificate for this outcome.

Who is the assessor for ID.RA-05 and what do they test?

An assessor is an independent party you engage to test your program against the CSF outcome, such as an internal audit function, an external audit firm or a qualified assessor your customer accepts. Only an independent auditor or assessor issues reports or attestations. For ID.RA-05, an assessor typically asks whether threat and vulnerability inputs are actually combined, whether likelihood and impact are estimated on a consistent basis, whether threat models exist for important data and whether resource and investment decisions trace back to the ranking. They will sample records and interview owners rather than accept a policy alone.

What does our team need to provide for a partner engagement?

Your team owns the inputs and the decisions, so a partner will need access and time from people who know the business. Typically this includes:

Access to the asset inventory, vulnerability records and threat intelligence sources
Named owners for critical systems and data who can confirm impact
Existing risk register entries, scoring scales and risk appetite statements
Decision makers who will approve the final prioritization and response plan

Agree on these dependencies in the written scope, along with who signs off each deliverable and how often your team will be needed.

Does a fixed-scope partner engagement change the outcome?

A fixed scope changes how the work is bounded and paid for, but not who is accountable for the result. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. The partner can help prepare threat models, the scored risk ranking and the evidence trail, and can support ongoing reviews through a retainer if you want continuous updates. The organization still decides which risks to accept, mitigate or avoid, and an independent assessor still tests the outcome.

How DeployOpen scopes and prepares ID.RA-05 evidence

DeployOpen helps organizations prepare the systems, risk records and threat models that show how threats, vulnerabilities, likelihoods and impacts are combined for ID.RA-05. The organization owns its risk decisions and its controls, and an independent assessor reaches any conclusion about them. Our role is to set up the working inputs and evidence inside your own environment.

How we scope

Agree in writing which systems, data flows and business services fall inside the ID.RA-05 assessment boundary.
Confirm which risk method, scoring scale and likelihood and impact definitions your organization already uses.
List the threat models, risk register fields and vulnerability sources the written scope will include and exclude.

How we build

Configure self-hosted tooling in your cloud accounts or data centers to hold risk records linked to assets and vulnerabilities.
Build a threat modeling workflow that records the threats considered for each in-scope system and its data.
Test that scoring fields, prioritization views and risk owner assignments produce consistent, reviewable results before handover.

How we hand over

Deliver the threat models, risk register extract and prioritization method as documents your team can maintain.
Provide a short evidence map linking each artifact to the ID.RA-05 outcome and the SP 800-53 and ISO/IEC 27001 references you choose to track.
Walk your risk and security owners through how to update inherent risk ratings when systems, threats or findings change.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work ends.
Retainers can keep threat models and risk ratings current as systems change and new vulnerability data arrives.
Ask any provider which assessor will review the evidence, since DeployOpen prepares evidence but does not issue assessment conclusions.