Rank critical components by mission consequence, not replacement cost

Source facts: criticality traces importance from goals to components

NIST Internal Report 8179 describes a Criticality Analysis Process Model for prioritizing programs, systems, and components by their importance to organizational goals and the impact that inadequate operation or loss could have on those goals. NIST notes that finite resources make equal protection of every asset impractical. A structured analysis supports more defensible security, privacy, project, acquisition, maintenance, and upgrade decisions.

The model follows a top-down path. It identifies organizational goals and objectives, the programs that support them, the systems that support those programs, the functions and capabilities those systems require, and the components and subcomponents that enable the functions. Baseline criticality is then adjusted using factors relevant to the operating environment, dependencies, threats, vulnerabilities, resilience, and other organizational considerations.

Criticality is not identical to purchase price, vulnerability severity, asset count, or a general business label. A low-cost component may be essential because many high-consequence functions depend on it, because no substitute exists, or because its failure is difficult to detect. NIST designed the process for use with broader risk-management methods, not as a replacement for risk assessment.

DSE recommendation: anchor analysis to one approved organizational goal

Choose a specific goal or essential outcome and name its accountable owner. Define what successful performance means, how degradation is recognized, which time periods or conditions matter, and what consequence follows from failure. Avoid beginning with an inventory and declaring familiar assets critical; that bottom-up approach can preserve historical assumptions.

Map the programs, services, and systems that materially support the goal. Include externally provided and manual capabilities. For each system, identify the functions required to deliver the outcome, then decompose those functions into components, subcomponents, people, data, facilities, communications, suppliers, and supporting services.

DSE recommendation: score consequence and dependency transparently

Define the criteria first. Examples include safety, financial loss, legal or contractual impact, duration, affected population, substitutability, detectability, restoration difficulty, and cross-service dependency.

Separate loss modes. Unavailability, corrupted output, unauthorized control, confidentiality loss, degraded performance, and intermittent behavior can have different consequences.

Expose concentration. Identify common identity, power, time, network, data, facility, supplier, and administrative dependencies whose failure reaches several systems.

Test alternatives. Confirm whether a spare, manual process, different supplier, alternate site, or degraded mode actually performs the required function within the tolerable window.

Record uncertainty. Mark unknown component composition, opaque supplier dependencies, incomplete architecture, assumptions, and disputed scores. Uncertainty is a finding, not a reason to fabricate precision.

DSE recommendation: turn the ranking into different treatment

For the highest-criticality components, decide what must change: stronger access and change controls, integrity verification, monitoring, diverse alternatives, protected spares, supplier evidence, shorter recovery objectives, more frequent tests, specialized skills, or executive exception authority. Tie procurement and maintenance priorities to the analysis, and ensure incident plans identify which components may be isolated or restored first.

Validate the map through walk-throughs and exercises with operators who understand hidden dependencies. Remove a supposedly critical component and see whether the alternate path works; remove a supposedly ordinary one and observe unexpected propagation. Reassess after mergers, architecture or supplier changes, new automated decisions, incidents, and altered organizational goals.

Retain the scope, hierarchy, criteria, evidence, scores, dependencies, assumptions, participants, approvals, and resulting decisions. Compare the result with asset, incident, maintenance, and recovery records so plans use the same priorities. A ranked list without traceable reasoning will decay into opinion. A useful criticality analysis shows exactly how a component’s condition can affect an organizational outcome and what the organization chose to do about it.

Official references

National Institute of Standards and Technology, NISTIR 8179: Criticality Analysis Process Model—Prioritizing Systems and Components, April 9, 2018; reviewed August 11, 2026.