{"data":{"id":"RA-09","name":"Criticality Analysis","family":"RA","family_name":"Risk Assessment","withdrawn":false,"description":"Identify critical system components and functions by performing a criticality analysis for [Assignment: organization-defined systems, system components, or system services] at [Assignment: organization-defined decision points in the system development life cycle].","supplemental_guidance":"Not all system components, functions, or services necessarily require significant protections. For example, criticality analysis is a key tenet of supply chain risk management and informs the prioritization of protection activities. The identification of critical system components and functions considers applicable laws, executive orders, regulations, directives, policies, standards, system functionality requirements, system and component interfaces, and system and component dependencies. Systems engineers conduct a functional decomposition of a system to identify mission-critical functions and components. The functional decomposition includes the identification of organizational missions supported by the system, decomposition into 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 many components within and external to the system.\n\nThe operational environment of a system or a system component may impact the criticality, including the connections to and dependencies on cyber-physical 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. Component and function criticality are assessed in terms of the impact of a component or function failure on the organizational missions that are supported by the system that contains the components and functions.\n\nCriticality analysis is performed when an architecture or design is being developed, modified, or upgraded. If such analysis is performed early in the system development life cycle, organizations may be able to modify the system design to reduce the critical nature of these components and functions, such as by adding redundancy or alternate paths into the system design. Criticality analysis can also influence the protection measures required by development contractors. In addition to criticality analysis for systems, system components, and system services, criticality analysis of information is an important consideration. Such analysis is conducted as part of security categorization in RA-02.","enhancements":[],"baseline_low":false,"baseline_moderate":true,"baseline_high":true,"nist_800_53":{"rev5":{"id":"RA-09","name":"Criticality Analysis","description":"Identify critical system components and functions by performing a criticality analysis for [Assignment: organization-defined systems, system components, or system services] at [Assignment: organization-defined decision points in the system development life cycle].","discussion":"Not all system components, functions, or services necessarily require significant protections. For example, criticality analysis is a key tenet of supply chain risk management and informs the prioritization of protection activities. The identification of critical system components and functions considers applicable laws, executive orders, regulations, directives, policies, standards, system functionality requirements, system and component interfaces, and system and component dependencies. Systems engineers conduct a functional decomposition of a system to identify mission-critical functions and components. The functional decomposition includes the identification of organizational missions supported by the system, decomposition into 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 many components within and external to the system.\n\nThe operational environment of a system or a system component may impact the criticality, including the connections to and dependencies on cyber-physical 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. Component and function criticality are assessed in terms of the impact of a component or function failure on the organizational missions that are supported by the system that contains the components and functions.\n\nCriticality analysis is performed when an architecture or design is being developed, modified, or upgraded. If such analysis is performed early in the system development life cycle, organizations may be able to modify the system design to reduce the critical nature of these components and functions, such as by adding redundancy or alternate paths into the system design. Criticality analysis can also influence the protection measures required by development contractors. In addition to criticality analysis for systems, system components, and system services, criticality analysis of information is an important consideration. Such analysis is conducted as part of security categorization in RA-02.","related_controls":["CP-02","PL-02","PL-08","PL-11","PM-01","PM-11","RA-02","SA-08","SA-15","SA-20","SR-05"],"baseline_low":null,"baseline_moderate":true,"baseline_high":true,"baseline_privacy":null,"new_in_rev5":true,"changes_from_rev4":"New control in Rev 5."}},"compliance_mappings":{"iso_27001_2022":["8.2","A.5.22"],"iso_27002_2022":[],"cobit_2019":["APO12","EDM03"],"pci_dss_v4":[],"nist_csf_2":["GV.OC-04","GV.SC-04","GV.SC-07","ID.AM-05","ID.RA-04"],"cis_controls_v8":[],"soc2_tsc":["CC3.1","CC9.1"],"finos_ccc":[],"iso_42001_2023":["A.5.2"],"iec_62443":["2-1 4.3"],"asd_e8":[],"nis2":["Art. 21(2)(f)"],"apra_cps_234":[],"mas_trm":["4","13"],"pra_op_resilience":["SS1/21-3.1","SS1/21-5.2","SS1/21-9.1","SS2/21-4.1"],"bsi_grundschutz":[],"anssi":["Hygiene.36","Hygiene.41","RGS.3.1","SecNumCloud.7.2"],"osfi_b13":["B-13.1.3","B-13.3.1","B-13.3.5"],"finma_circular":["IV.A(42)","IV.B.c(54)","IV.B.c(55)","IV.B.d(58)","IV.E(88)","IV.E(94)","IV.E(95)","IV.E(96)","V(101)"],"gdpr":[],"dora":["Art.6(2)","Art.8(4)","Art.11(2)","Art.11(3)","Art.29(1)","Art.30(3)"],"bio2":[],"rbi_csf":["Annex1.1","ITGRCA.9"],"fisc":["FISC.O1"],"lgpd_bcb":["BCB.Art.3-Supp","BCB.Art.5-Supp","BCB.Art.12"],"hkma_tme1":["TME1.2.3","TME1.6.1","TME1.6.2","TME1.12.1","TME1.12.5"],"mlps_2":[],"dnb_good_practice":["DNB.4.2"],"cra":[],"swift_cscf":[],"cbb_tm":["TM-4","TM-14","TM-15"],"cbuae":["CR-2","CR-10"],"nca_ecc":["1-5","2-1"],"qatar_nia":["RM"],"sama_csf":["1.8","2.1"],"uae_ia":["T2"],"bog_cisd":["CISD-III"],"bom_ctrm":["1.4","2.1","3.7","4.3"],"cbe_csf":["CRM-1","CRM-2","OVM-3"],"cbn_csf":["Part2.1","Part2.3","Part3.1","Part5.1"],"sa_js2":["JS2-6.1","JS2-6.2","JS2-7.7"],"bcbs_239":["Principle 4","Principle 8"],"bot_cyber":["Ch1.2","Ch2.1","Ch3.2"],"cpmi_pfmi":["CG.ID","PFMI.P3"],"eba_ict":["3.3.2","3.3.3","3.7.1"],"ecb_croe":["CROE.2.2.1","CROE.2.2.2"],"ffiec_is":["II.A","II.B","II.C.5"],"hipaa_sr":["§164.308(a)(1)(ii)(A)","§164.308(a)(7)(ii)(E)"],"iosco_cyber":["ID-1","ID-2","RR-2"],"nydfs_500":["500.9"],"sebi_cscrf":["DE.VA","GV.OC","GV.RM","ID.AM","ID.RA","VAPT"],"cmmc_2":["RA"],"nerc_cip":[],"nrc_73_54":["RG5.71-C-PL"],"tsa_psd":[],"ieee_1686":[],"ferc_cip":[],"doe_c2m2":["THREAT"],"api_1164":["Sec 4"],"awia":["Sec 2013(a)"],"iaea_nss":["Sec 4"],"pci_pts":[],"fips_140":[],"cbest":["CBEST.3"],"tiber_eu":[],"pci_hsm":[],"common_criteria":[],"isae_3402":["Clause 3"],"fca_sysc_13":["SYSC 13.5.2"],"fda_21_cfr_11":[],"fda_cyber":["CRA-2","SPDF-2"],"hitrust_csf":["00.b","03.a","07.a","12.a"],"iso_27799":[],"lloyds_ms":["MS9.1","MS9.3","MS10.2"],"naic_ds":["4A"],"nhs_dspt":["NDG-5.3","NDG-8.3"],"pra_ss1_23":["P1.1","P1.2"],"solvency_ii":["Art.44(1)","Art.45","Art.49(2)","EIOPA-Cloud-GL3","EIOPA-ICT-4.2","EIOPA-ICT-4.3"],"owasp_masvs_v2":[],"csa_ccm_v4":["BCR-02"],"csa_aicm":["BCR-02"],"ccss_v9":[],"mica":["Art.35(1)"],"basel_sco60":[],"bssc":[],"sec_custody_digital":[],"dpdpa":[]},"attack_techniques":[{"id":"T1495","name":"Firmware Corruption","tactics":["impact"],"mapping_type":"mitigates","mapping_rationale":"Criticality analysis identifies firmware components essential to system operation, enabling prioritised hardening and integrity monitoring that limits adversary ability to corrupt firmware on the most impactful systems without detection."},{"id":"T1542","name":"Pre-OS Boot","tactics":["defense-evasion","persistence"],"mapping_type":"mitigates","mapping_rationale":"By identifying critical boot-chain components through criticality analysis, organisations can prioritise Secure Boot enforcement, firmware integrity checks, and enhanced monitoring on systems where pre-OS boot manipulation would have the greatest operational impact."},{"id":"T1553","name":"Subvert Trust Controls","tactics":["defense-evasion"],"mapping_type":"mitigates","mapping_rationale":"Criticality analysis identifies systems where trust control subversion would be most damaging, enabling targeted deployment of code signing enforcement, certificate pinning, and trust store hardening on the most operationally significant assets."},{"id":"T1601","name":"Modify System Image","tactics":["defense-evasion"],"mapping_type":"mitigates","mapping_rationale":"Identifying critical network infrastructure through criticality analysis ensures that system image integrity monitoring and change detection are prioritised on devices where image modification would most severely compromise network security and availability."},{"id":"T1195.003","name":"Compromise Hardware Supply Chain","tactics":["initial-access"],"mapping_type":"mitigates","mapping_rationale":"Criticality analysis of hardware supply chains identifies the most operationally significant components, enabling targeted provenance verification, tamper-evident packaging requirements, and enhanced inspection for hardware that would cause maximum impact if compromised."},{"id":"T1542.001","name":"System Firmware","tactics":["defense-evasion","persistence"],"mapping_type":"mitigates","mapping_rationale":"Criticality analysis directs firmware integrity verification resources to systems where UEFI/BIOS compromise would be most damaging, ensuring that Secure Boot, firmware attestation, and TPM-based measurements are prioritised on mission-critical assets."},{"id":"T1542.003","name":"Bootkit","tactics":["defense-evasion","persistence"],"mapping_type":"mitigates","mapping_rationale":"By classifying systems by criticality, organisations ensure that bootkit countermeasures—including Secure Boot, measured boot chains, and boot integrity monitoring—are deployed first on systems where boot-level persistence would have the greatest operational impact."},{"id":"T1542.004","name":"ROMMONkit","tactics":["defense-evasion","persistence"],"mapping_type":"mitigates","mapping_rationale":"Criticality analysis identifies network infrastructure where ROMMONkit installation would be most disruptive, enabling prioritised firmware signing validation and physical access controls on critical routers and switches."},{"id":"T1542.005","name":"TFTP Boot","tactics":["defense-evasion","persistence"],"mapping_type":"mitigates","mapping_rationale":"Identifying critical network devices through criticality analysis ensures that TFTP boot protections—such as authenticated boot image sources and secure boot validation—are enforced on infrastructure where boot manipulation would cause maximum operational disruption."},{"id":"T1553.006","name":"Code Signing Policy Modification","tactics":["defense-evasion"],"mapping_type":"mitigates","mapping_rationale":"Criticality analysis identifies systems where code signing policy modification would pose the greatest risk, enabling prioritised enforcement of immutable signing policies and enhanced monitoring on the most sensitive platforms."},{"id":"T1601.001","name":"Patch System Image","tactics":["defense-evasion"],"mapping_type":"mitigates","mapping_rationale":"By identifying critical network infrastructure, criticality analysis ensures that system image patching controls—including cryptographic signature verification and change management gates—are rigorously enforced on devices where unauthorised image patches would be most impactful."},{"id":"T1601.002","name":"Downgrade System Image","tactics":["defense-evasion"],"mapping_type":"mitigates","mapping_rationale":"Criticality analysis prioritises image version enforcement and downgrade protections on the most operationally significant network devices, ensuring adversaries cannot revert critical infrastructure to vulnerable firmware versions without triggering enhanced detection."}],"metadata":{"last_reviewed":"2026-10-03","review_notes":"2026-10-03: iso_27001_2022 A.5.22 added from NIST's SP 800-53 Rev 5 to ISO/IEC 27001:2022 crosswalk (OLIR entry 155), which OSA's mapping now takes as its base. 2026-10-03: nist_csf_2 GV.OC-04, GV.SC-04, GV.SC-07, ID.AM-05, ID.RA-04 added from NIST's CSF 2.0 to SP 800-53 Rev 5.2.0 crosswalk (OLIR entry 186), which OSA's mapping now takes as its base.","mapping_status":"complete"},"function":"detective","used_by_patterns":["SP-018","SP-034","SP-045","SP-046"]}}