Security requirement
Identify critical system components and functions by performing a criticality analysis for [Organization-defined: systems, system components, or system services] at [Organization-defined: decision points].
Discussion
Organizations conduct a functional decomposition of a system to identify mission-critical functions and system components. The functional decomposition includes the identification of organizational missions supported by the system, the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by components within and external to the system. The operational environment of a system or a system component may impact its criticality, including the connections to and dependencies on other systems, devices, system-of-systems, and outsourced IT services. System components that allow unmediated access to critical system components or functions are considered critical due to the inherent vulnerabilities that such components create. Criticality analysis is performed when an architecture or design is being developed, modified, or upgraded. If such analysis is performed early and throughout the system development life cycle, organizations may be able to modify the system design to reduce the critical nature of these functions and components, such as by adding redundancy or alternate paths into the system design. This requirement is sourced to a control tailored out of the SP 800-53B .13 moderate baseline in SP 800-171.
Tailoring decisions required
Resolve these values through the governing organization’s approved tailoring and risk-management process before declaring the requirement implemented.
Protection strategies supported
These classifications are carried from the official SP 800-172 OSCAL record and help explain the enhanced requirement’s defensive purpose.
Implementation perspective
Treat Criticality Analysis as an enhanced CUI protection outcome for elevated threat conditions that must be reflected in the system boundary, documented implementation, operational behavior, and assessment evidence. Pay particular attention to threat, vulnerability, likelihood, impact, criticality, and risk-response decisions for the CUI environment.
- Confirm the federal agency selected this enhanced requirement for the critical program or high-value asset and identify the CUI system components, services, users, and external connections in scope.
- Resolve every organization-defined parameter through an approved governance and tailoring process.
- Map each clause of the requirement to an accountable owner, implementation mechanism, and evidence source.
- Verify that inherited and shared implementations are supported by current provider evidence and responsibility boundaries.
- Collect evidence during normal operation and review changes, exceptions, and deficiencies on a risk-based cadence.
Questions to ask
- Which critical-program or high-value-asset CUI, data flows, users, and services are protected by this enhanced requirement?
- Which portions are implemented locally, inherited, shared, or not applicable, and what evidence supports that determination?
- Do the system security plan, deployed configuration, operating process, and assessment evidence tell the same story?
- What change, incident, or threshold should trigger reassessment?
Evidence and validation
- risk assessments and threat models
- vulnerability findings and prioritization records
- supply-chain risk assessments
- risk response and acceptance decisions
Common failure patterns
- risk registers detached from technical evidence
- vulnerability severity treated as business impact
- assessments not updated after material change
- accepted risks without owners or expiration
Assessment objectives and methods
Assessment objectives (1)
critical system components and functions are identified by performing a criticality analysis for [Organization-defined: systems, system components, or system services] at [Organization-defined: decision points].
Examine
- Risk assessment policy
- assessment reports
- criticality analysis and/or finalized criticality for each component and/or subcomponent
- audit records and/or event logs
- analysis reports
- system security plan
- other relevant documents or records
Interview
- Personnel with assessment and auditing responsibilities
- personnel with criticality analysis responsibilities
- system/network administrators
- personnel with information security responsibilities
Test
- Processes for assessments and audits
- mechanisms and/or tools supporting and/or implementing assessments and auditing
Source NIST SP 800-53 controls
These controls are referenced by the official SP 800-172 Rev. 3 OSCAL record. Open the corresponding control pages for complete control text, enhancements, D3FEND mappings, and related learning.
Authoritative sources
- NIST SP 800-172 Revision 3 official publication ↗
- NIST SP 800-172A Revision 3 official publication ↗
- NIST OSCAL Content release used for this import ↗
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. The official publications, the responsible federal agency, and the governing contract or agreement determine applicability, tailoring, assessment depth, and required implementation.