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.
\n\nThe 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.
\n\nCriticality 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.
\n\nChoose 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.
\n\nMap 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.
\n\nFor 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.
\n\nValidate 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.
\n\nRetain 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.
\n\n