ID.RA-04 Impacts and likelihoods recorded: evidence guide

What ID.RA-04 asks you to record about likelihood and impact

A customer questionnaire, an auditor or your own board asks a simple question: are your risk scenarios scored for likelihood and business impact, and are those scores stored in a register someone actually maintains? ID.RA-04 is the CSF 2.0 Subcategory behind that question. Its outcome is that the potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded. In practice, this means each risk you track has an estimated chance of occurring, an estimated business consequence, and a written record of how you arrived at both. A list of findings with no scores does not meet the outcome, and a score with no recorded basis is hard for an assessor to test.

Unscored registers tend to fail in predictable ways. Entries accumulate from scans and incidents, but nobody assigns likelihood, so every item looks equally urgent or nothing gets prioritized at all. Impact is often recorded as a single word such as "high" with no link to a process, a revenue line or a regulatory duty, so the number cannot be defended when leadership asks what it means. The register also goes stale, because scores are set once during a workshop and never revisited after a change in architecture or a new threat. The Implementation Examples NIST publishes for ID.RA-04 point the reader toward risk scenarios estimated by business leaders and risk practitioners together, which is why the register needs named owners for each score.

The requirement also asks you to account for cascading failures. A single compromised identity provider, backup service or message broker can disable several business processes at once, and the impact of that chain is often larger than the sum of the components scored separately. Record the dependencies between systems in the scenario, not only the system where the threat enters. Before a customer or assessor accepts your evidence, confirm three things: who scored each scenario, what dependency map sits behind the impact estimate, and when the score was last reviewed. NIST CSF 2.0 is voluntary, NIST does not certify anyone against it, and an independent assessor is the party who tests whether this evidence holds up.

Scoping decisions that change the ID.RA-04 workload

ID.RA-04 asks for potential impacts and likelihoods to be identified and recorded, so the work grows or shrinks with a few early choices. The cards below cover the decisions that most change the number of scenarios, the depth of dependency mapping and how often the register must be revisited.

Which business processes get scored

Every business process you score needs its own scenarios, estimated likelihoods and impact statements. Scoring only the revenue-generating or regulated processes keeps the first cycle manageable, while scoring every process produces a register that few reviewers can maintain. Ask business owners to name the processes whose disruption would breach a customer commitment or a regulatory duty, and record the rest as out of scope with the reason. Check that the boundary matches the scope used in your other CSF assessments.

How deep dependencies are mapped

The third Implementation Example for ID.RA-04 addresses cascading failures, so the register needs to show how one system's failure reaches others. Mapping only direct links between applications is quick but misses shared identity services, message queues and databases that sit under many processes. Mapping transitive dependencies is more accurate but depends on an asset inventory (ID.AM) that is current. Decide the depth before workshops begin, and confirm who owns each dependency record.

Whether third-party outages are modeled

Scenarios that assume a cloud region, SaaS provider or managed service fails add a separate set of likelihood estimates, because you rarely control the provider's own controls. Including them improves the impact picture for outsourced processes, but it requires provider service history, contractual recovery commitments and exit terms, which many teams do not hold in one place. Check what each critical provider has committed to in writing and what evidence it will share, then decide whether provider outages sit in the register or in supplier risk records that feed it.

How often scenarios are rescored

Likelihood and impact estimates age as threats change, systems are added and controls are implemented. A rescoring cycle that runs only once a year keeps the workload small but leaves new exposures unrecorded until the next review. Tying rescoring to triggers such as major architecture changes, significant incidents and new threat intelligence (ID.RA-02) increases the number of reviews but keeps the register current. Agree the triggers and the owner for each in advance so the cadence is written down rather than improvised.

How many risk owners review scores

Scores recorded by one practitioner are quick to produce but hard to defend when leaders challenge them. Requiring business owners to confirm impact statements adds review time for each scenario, yet it is what makes the register usable for risk decisions under GV.RM. Decide early which scores need a second reviewer, such as those above your agreed threshold, and budget the meeting time that involves. Ask whether your organization has a written scoring scale to apply consistently.

How an assessor tests ID.RA-04

This table sets out how an independent assessor is likely to test ID.RA-04, what evidence they will ask for, and the gaps they commonly find in risk registers. Read each row as a question the register must answer before an assessor arrives, and confirm the exact sampling method and scope with your chosen assessor.

Test area	What the assessor does	Evidence requested	Common findings
Sampling of register entries	Selects a sample of risk scenarios from the register across business units and system types, then checks each entry against the outcome of ID.RA-04.	Current risk register export, scenario list with owners and dates, and the sampling basis the assessor agreed with you.	Entries exist for only a few systems, or the register covers IT assets but omits business processes that depend on them.
Likelihood and impact recorded	Confirms that each sampled scenario has both a likelihood and an impact value, and that the scale used is defined and applied consistently.	Scoring method, scale definitions, and the completed likelihood and impact fields for each sampled scenario.	Scores appear with no rationale, the scale changes between teams, or impact is recorded only as a severity label.
Rationale for ratings	Reads the reasoning behind each rating and checks that it refers to threat information, vulnerability data or past events.	Written justification, references to threat intelligence or vulnerability records, and reviewer sign-off.	Ratings are copied from a template or prior year with no evidence that they were reconsidered.
Business impact tied to consequences	Checks that impact statements describe business outcomes such as service interruption, data exposure, regulatory exposure or financial loss, not only technical effects.	Business impact analysis extracts, service dependency records and the named business owner for each scenario.	Impacts are written as technical outcomes only, such as host compromise, with no link to what the business loses.
Traceability to vulnerabilities and threats	Traces sampled scenarios back to the vulnerability and threat records that support them, and checks the links run in both directions.	Cross-references between the register and vulnerability and threat records, with dates showing when each link was made.	Scenarios cite threats that no longer appear in the threat record, or vulnerabilities are open with no scenario attached.
Cascading failures across dependent systems	Tests whether the register considers how a failure in one system could propagate to dependent systems, shared services and third parties.	Dependency or data flow maps, scenarios that describe chained failures, and records of how the chains were chosen.	The register treats each system in isolation, and shared identity, network or cloud services never appear as a failure point.
Currency after architecture change	Compares register dates with recent change records to see whether entries were reviewed after significant architecture or supplier changes.	Change management records, architecture diagrams with version dates, and the register revision history.	The register is not updated after migrations, new integrations or new suppliers, so scores describe a system that no longer exists.
Confirm with your assessor	Agrees the sample size, scope, evidence format and test method in writing before fieldwork starts.	Written engagement scope and the assessor's test plan, which you should request during scoping.	Expectations differ between the organization and the assessor because the scope was never written down.

Steps to record impacts and likelihoods that hold up under review

This sequence turns vulnerability and threat records into scenarios with agreed scales, documented likelihood and impact estimates, cascading dependencies and owned register entries that an assessor can trace from evidence to conclusion. Each step closes with a named output so the record can be checked at every stage.

Agree the scoring method and scales
The risk owner, the risk practitioner and the business leaders who will accept impacts agree in writing on a likelihood scale, an impact scale and how the two combine into a rating. Define each level in terms the business uses, such as customer records affected, hours of service disruption, regulatory exposure or financial loss, so two assessors would assign the same level to the same scenario. The output is a short scoring standard approved by the accountable executive, with its version and approval date recorded. Confirm that the method matches the organization's enterprise risk management approach under GV.RM.
Select threat scenarios from existing records
Pull candidate scenarios from the vulnerability records (ID.RA-01), threat intelligence (ID.RA-02) and threat records (ID.RA-03) rather than inventing them during the workshop. Each scenario should name a threat source, the vulnerability or condition it would exploit, and the asset or business process affected. Remove duplicates and group scenarios that share the same asset. The output is a numbered scenario list where every entry traces back to at least one source record, so an assessor can follow the chain.
Assign likelihood and impact with rationale
For each scenario, the practitioner assigns a likelihood level and an impact level using the agreed scales, then writes one or two sentences of rationale citing the evidence used, such as exploit availability, control coverage, exposure of the system, or the data and services at stake. Business leaders review impact ratings because they know the service dependencies, while technical staff review likelihood because they know the controls. Record disagreements and how they were settled. The output is a scored scenario list in which every rating has a written reason and a named reviewer.
Model cascading dependencies across connected systems
For scenarios that touch shared identity, networks, data stores or third-party services, trace how a single failure could spread to dependent systems and business functions. Use the asset inventory and data flow maps from ID.AM to identify those links, and record the downstream effects that change the impact rating, such as a directory outage that blocks authentication to several applications. Note where the impact is higher than the initial rating once cascades are included. The output is a dependency note for each affected scenario, with the revised impact level where it changed.
Record results in the risk register with owners
Enter each scored scenario in the cybersecurity risk register with its threat, vulnerability, asset, likelihood, impact, rating, rationale, dependencies and a named risk owner. The owner is a person with authority to accept or fund a response, not a team alias. Link each entry to the response record used under ID.RA-06 so that the register shows what happens next. The output is a register extract in which no entry lacks an owner, a rating or a rationale, and the register version and date are logged.
Set a review trigger for each entry
Define the conditions that force a re-estimate of likelihood or impact, such as a new exploit affecting the same component, a material change to the system through change management under ID.RA-07, a new supplier dependency, or an incident involving the scenario. Also set a periodic review that the governance body approves, with the cadence stated in the risk management policy. Confirm the cadence with your own policy rather than assuming a standard interval. The output is a trigger column in the register and a dated review record that shows each entry was checked against its trigger.

Evidence that satisfies ID.RA-04 and how to keep it current

ID.RA-04 is met by records, not by a one-time workshop: an assessor looks for impact and likelihood estimates that are written down, traceable to a method, and refreshed when the environment changes. The six artifacts below work together, so each one should point to the others rather than repeat them.

Risk register extract

The register is the primary record that ID.RA-04 asks for: each threat scenario that exploits a vulnerability, with its likelihood, business impact, owner and date of last review. Pull a dated extract that shows the fields populated for in-scope systems, not a blank template. Between audits, update the affected rows when an asset, vendor or exposure changes, and keep an edit history so an assessor can see when an estimate moved and why.

Scoring method document

This document defines the scales used for likelihood and impact, such as what a rating of high means in financial loss, patient harm or service downtime. Assessors check that the method is written, approved and applied consistently across the register. Keep it stable: revise it through the governance process, record the version, and re-score only the scenarios whose inputs the revision changes.

Scenario worksheets with rationale

A worksheet records how one scenario was estimated: the threat, the affected assets, the inputs considered, the assumptions and the reasoning behind each rating. A rating without a rationale is hard to defend, so ask each analyst to write the reason in plain sentences. Reuse the worksheet for recurring scenarios and annotate it when a control is added or removed, so the rationale stays tied to the current environment.

Dependency and cascade diagrams

The Implementation Examples for ID.RA-04 call for accounting for cascading failures, so diagrams should show which systems depend on which, including identity providers, shared databases, cloud regions and key suppliers. Confirm that each cascade scenario in the register is traceable to a path on the diagram. Regenerate the diagram from configuration or asset data where possible, because a hand-drawn map goes stale after the first infrastructure change.

Review minutes and sign-off

Minutes show that people with authority reviewed the register and accepted its estimates. They should list the scenarios reviewed, the changes approved, the attendees and the decisions on disputed ratings. Ask the organization to confirm the review cadence it has committed to in policy, then keep the minutes in a location assessors can reach. Missing minutes are a common reason an otherwise complete register does not show that it is maintained.

Change-triggered updates

Some changes should reopen estimates without waiting for the scheduled review: a new internet-facing service, a major vendor change, a significant incident or a new vulnerability class affecting a core system. Define these triggers in the change management process so each change ticket asks whether the register must be updated. Record the link between the change and the revised scenario, which lets an assessor see that the register tracks the environment as it actually is.

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

This table lists each cost component of recording impacts and likelihoods for ID.RA-04, who carries it, whether it is one-time or recurring, and what drives it up or down. Use it to scope a quote, since the largest recurring cost is usually staff time rather than software licenses.

Cost component	One-time or recurring, and who is paid	Main cost drivers
Tooling or licenses	Recurring for commercial risk platforms (license fees to the vendor). One-time for setup and integration, paid to the implementer if outsourced.	Number of users, number of risk scenarios held in the tool, and whether the tool is commercial or open source. Self-hosted open-source GRC software can remove license spend but not the setup or hosting work.
Engineering and risk staff time	Recurring. Paid from the internal budget or to an implementation partner for defined deliverables.	Number of scenarios to estimate, how many business owners must review them, and how often the register is re-scored.
Dependency mapping effort	Largely one-time for the first map, then recurring as systems change. Often outsourced in part.	System count, depth of cross-system dependencies, and whether an up-to-date asset inventory and data flow map already exist (ID.AM outputs).
Impact and likelihood workshops	Recurring, usually tied to review cycles. Internal staff time, with facilitation possibly outsourced.	Number of business units, the agreed impact scale, and how much historical incident data is available to support likelihood estimates.
Evidence upkeep	Recurring. Paid to internal staff or an implementer who maintains the register and its history.	Change frequency of systems and threats, the number of register revisions retained, and how well the register links to vulnerability and threat records.
External review	Periodic. Paid to an independent reviewer or advisor who challenges scoring. Not an audit or certification.	Risk appetite complexity, regulatory expectations for the sector, and whether the review covers cascading failure scenarios.
Auditor sampling	Recurring at each assessment cycle. Paid to the independent auditor or assessor, who issues any report.	Number of register entries sampled, the age of the entries, and whether the rationale for each likelihood and impact score is documented.

Who owns ID.RA-04 and what can be outsourced

Your organization owns the control. Your risk owners decide how likely each threat scenario is to exploit a vulnerability, what the business impact would be, and whether the resulting rating is acceptable. Those decisions belong to people who understand the services, customers and obligations affected, and they must be recorded under your name. No outside firm can make them for you.

Scoring decisions: Business and risk leaders agree on the likelihood and impact scales, the criteria behind each rating and the rationale for every entry.
Business impact ownership: Named owners for each service or data set state the consequences of unauthorized access, outage or data loss in their own terms.
Register approval: An accountable executive or risk committee approves the risk register and records when it was last reviewed.
Cascading failure judgment: Owners decide which dependent systems could fail together and how far those failures would spread.
Ongoing updates: Your team revisits ratings when systems, threats or suppliers change.

Check that each rating in the register names a decision owner, a date and the basis for the score.

Where ID.RA-04 registers usually fall short

ID.RA-04 asks for the potential impacts and likelihoods of threats exploiting vulnerabilities to be identified and recorded. Registers that look complete often fail on meaning, linkage and currency, which is where assessors and incident reviews tend to find problems.

Scores without business meaning

A register that rates a risk as 4 out of 5 says little to a board member deciding where to spend money. Each likelihood and impact rating should be tied to a defined scale that names the business consequence, such as hours of downtime, records exposed or regulatory notification duties triggered. Check that every rating can be explained in one sentence by the person who assigned it, and that the scale definitions are written down and approved.

Dependent services left out

Many entries record the impact on the system where a weakness sits and stop there. ID.RA-04 expects cascading failures across systems of systems to be considered, so an authentication service outage may stop payments, reporting and customer portals at once. For each high-impact scenario, trace upstream and downstream dependencies and record the aggregate impact, not just the local one.

Scenarios not linked to vulnerabilities

A scenario such as ransomware on a file server should point to the specific vulnerabilities, misconfigurations or access paths that make it plausible. Without that link, likelihood is guesswork and the register cannot show whether a patch or control change lowers the risk. Confirm that each scenario references the vulnerability records it depends on, and that closing a vulnerability triggers a review of the scenarios it supports.

Stale likelihood and impact values

Likelihood changes when threat intelligence, exposure or controls change, and impact changes when systems, data volumes or contracts change. Entries last reviewed years ago often reflect a previous architecture. Ask the register owner for the date of each last review, set a review trigger tied to asset changes and major advisories, and flag any entry whose underlying system has been replaced since it was assessed.

Unowned and unclear entries

Entries with no named owner tend to stay open or get closed without review. ID.RA-04 outcomes depend on people who understand the business impact, so each row needs an accountable business owner and a technical contributor. Check that owners have agreed to their ratings, and that the register records who approved any change to a likelihood or impact value.

Impact of unauthorized access missing

NIST's Implementation Examples for ID.RA-04 list the business impacts of unauthorized access as a distinct item to record. Registers often describe a breach in technical terms only, leaving out customer harm, contractual penalties and reporting obligations. Add a column or section for these outcomes, and confirm that the legal and privacy teams have reviewed the wording for regulated data.

Questions buyers ask about ID.RA-04

How much effort does recording impacts and likelihoods take in-house?

The effort depends mainly on how many threat scenarios you model, how many systems and business services they touch, and how much evidence already exists. Most of the work is not technical. Someone must define the scenarios, agree a scoring scale for likelihood and impact, gather asset and dependency data, and then get business owners to estimate the consequences. Teams that already keep an asset inventory (ID.AM) and a vulnerability record (ID.RA-01) start further ahead. Ask any partner or internal lead to break the effort into scenario workshops, data collection, register build, and periodic review, so you can see which parts recur each year.

Do we need an outside partner to build an ID.RA-04 risk register?

No. NIST CSF 2.0 does not require an outside party, and an organization can own the register entirely. A partner is useful when the team lacks risk-assessment experience, when systems span several clouds or data centers, or when the register must feed other frameworks at the same time. Be clear about roles: your organization owns the risk decisions and the register, an implementation partner can prepare the data, tooling and templates, and only an independent auditor or assessor can issue an assessment opinion. Ask any partner to state in writing which of these tasks it performs and which remain with your staff.

How long does it take to build a first risk register?

The honest answer is that it depends on scope. The duration follows from the number of scenarios, the number of business services in scope, how quickly business leaders can respond, and whether the asset and vulnerability data is already reliable. A narrow register covering one service with clean inventory data can be built far faster than one covering an enterprise with many suppliers. Ask for a schedule that separates scenario definition, impact workshops, data validation and sign-off, and confirm which dependencies (inventory, scanning results, owner availability) could delay each step.

What do business leaders need to contribute to impact estimates?

Business leaders supply the knowledge that technical teams cannot. They must describe which processes depend on each system, what a disruption or data exposure would cost in revenue, service levels, legal duties and customer trust, and how long the business could tolerate an outage. Their time is needed for scoping workshops, for agreeing the impact scale, and for reviewing results. Without this input, likelihood and impact scores become technical guesses. Plan a fixed number of working sessions with named owners, and record their assumptions in the register so assessors can trace each rating.

Does NIST certify that our CSF 2.0 risk assessment is compliant?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. Any claim that a risk register is NIST-certified is therefore inaccurate. CSF 2.0 is voluntary for most organizations, although some customers or suppliers may require alignment. Where a customer asks for evidence, the organization can show its own documented register and how it ties to the CSF outcome. Any independent review comes from an auditor or assessor chosen by the organization, and that party issues the report, not NIST or the implementation partner.

How should we scope a partner engagement for ID.RA-04?

Start with the register's boundary: which business services, systems, suppliers and threat scenarios it covers, and which decisions it must support. Then define deliverables, such as the scoring method, a populated register, scenario documentation, and a handover session. Ask the partner to specify what it will prepare, what your staff must provide, and what remains your responsibility. DeployOpen works on fixed scope, with scope, deliverables and timelines agreed in writing before work starts, and it prepares systems and evidence without issuing audit reports. Request a written scope and quote that lists assumptions about data availability and owner time.

Which NIST informative references should we use to support the register?

NIST's CSF 2.0 Reference Tool lists informative references for ID.RA-04, including SP 800-53 Rev. 5.2.0 controls PM-9, PM-11, RA-2, RA-3, RA-8 and RA-9, ISO/IEC 27001:2022 clauses 6.1.1, 6.1.2 and 6.1.3, and the SP 800-171 Rev. 3 requirement 03.11.01. Use these as starting points for evidence, not as proof of compliance on their own. Confirm each reference against your own environment and the current published text, because mappings are updated over time. The NIST CSF 2.0 Reference Tool export is the natural place to check them.

How DeployOpen prepares ID.RA-04 evidence

DeployOpen works on ID.RA-04 by preparing the systems and records an organization needs to show that likelihoods and business impacts of threats exploiting vulnerabilities are estimated and kept in a risk register. The organization owns its risk decisions and its controls, and an independent auditor or assessor reaches any conclusion about them.

How we scope

The written scope names which risk scenarios, asset groups and risk register fields are covered for ID.RA-04.
The scope states which systems of systems and cascading dependencies are included in the impact analysis.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

We configure the self-hosted risk register so each scenario records likelihood, business impact and its basis.
We connect vulnerability and asset data from the client's own tools to the register entries that depend on them.
We document how dependent systems are mapped so cascading failure scenarios can be traced and reviewed.

How we hand over

We deliver the register configuration, scoring method and a record of how each likelihood and impact estimate was set.
We provide a mapping of each register entry to the ID.RA-04 outcome and to the client's own control references.
We walk the client's risk owners through the records so they can maintain and defend the estimates themselves.

How we support

Ongoing support, upgrades and reviews of the register are available as a retainer after handover.
Retainer work can refresh likelihood and impact estimates when systems, suppliers or threat conditions change.
Confirm with DeployOpen which assessor will review the evidence, since DeployOpen prepares evidence but does not issue assessments.

ID.RA-04 Impacts and likelihoods recorded