You cannot protect everything equally, so you need to know which parts matter most. RA-9 Criticality Analysis is how you find them. NIST 800-53 binds US federal systems, and reaches others through contracts. For everyone else it is a reference, and it supports risk assessment, supplier decisions and where to spend scarce security effort.
What it means in practice
The statement asks you to identify critical system components and functions by performing a criticality analysis for systems, components or services you define, at decision points in the life cycle that you define.
The guidance says not every component needs significant protection, and calls criticality analysis a key part of supply chain risk management. It describes a functional decomposition: identify the business missions the system supports, break them into functions, and trace those functions to the hardware, software and firmware that implement them, including shared ones. It also notes that dependencies on outsourced services and connected systems affect criticality, and that components giving unmediated access to critical functions are critical themselves.
For a software company this could mean tracing a customer facing feature down to its services, data stores, identity provider, build pipeline and the open source packages in its path.
Evidence to collect
- A list of business functions and their owners.
- A dependency map from each function to components, services and suppliers.
- The criticality rating for each, and the criteria used.
- The decision points where you rerun the analysis, with dates of the last runs.
- Use of the result: priorities for hardening, redundancy and supplier review.
Common gaps
- The inventory exists, but nothing says which items are critical.
- Third party services are missing from the dependency map.
- The analysis ran once at architecture time and was never updated.
- Shared components, such as a logging service or identity provider, are not rated as critical.
How to implement it
Start with five business functions that would hurt most if they stopped. Trace each to its parts. Mark what fails when each part fails. Rate the parts: critical, important, routine. Give critical parts stronger monitoring, tighter access, backup plans and closer supplier review.
Rerun it when you add a major service, change a provider or reorganize the architecture. An up to date asset inventory makes this far faster, which is what the asset discovery demo shows.
Click through it at your own pace, or open it full screen.
Quick check
Is criticality the same as risk?
No. Criticality describes how much a function depends on a component. Risk adds threat and vulnerability. Criticality helps you rank where risk matters most.
Why do shared services count as critical?
Many functions depend on them, so a failure spreads. The guidance also treats components that give unmediated access to critical ones as critical.
