Beyond the IT Checklist: Engineering a Reasonable Standard of Care for Cyber Safety Matthew E. Jablonski, Linton Wells II, Kathryn B. Laskey, F. Brett Berlin
arXiv:2606.13612v1 [cs.CR] 11 Jun 2026
College of Engineering and Computing George Mason University Fairfax, VA {mjablons, lwells, klaskey, fberlin}@gmu.edu
Abstract—Current U.S. cyber policy, centered on security, often treats documentation of controls and incident reports as a proxy for safety in the built environment. This paper argues that such an approach is inadequate for cyber-physical systems, where digital failures can produce kinetic harm. We construct and code a corpus of critical infrastructure policy documents (N = 292, 2000–2025) to examine how “reasonable care” is operationalized across the NIST SP 800-160 Vol. 2 resilience lifecycle. The resulting maps show that obligations are concentrated in the Anticipate phase and emphasize administrative compliance, while Withstand and Recover phases rely heavily on delegated references to IT-focused control catalogs that are poorly aligned with physics-based hazards. We identify three major disconnects: miscalibrated delegated standards, recovery defined as notification rather than engineered navigation, and uneven adaptation requirements across sectors. We then propose a modernized standard of care anchored in hazard-specific traceability, structured assurance cases, and cyber resiliency engineering. Finally, we recommend that federal policy pair these engineering obligations with targeted incentives so that resilient architectures for critical infrastructure become a viable business decision rather than an unfunded expectation. Index Terms—Cyber-physical systems, Critical infrastructure protection, Safety engineering, Government policy, Cyber Security, Resilience
I. I NTRODUCTION Operational Technology (OT) and Information Technology (IT) have converged to turn the built environment into a cyberphysical contested environment with conflicting objectives. Current U.S. policy ignores this hybrid reality. Rather than treating Cyber Safety as a distinct engineering discipline, regulators overlay data-centric IT security controls onto physicscentric systems. This creates a structural gap where asset owners can be fully compliant with major federal standards even though their systems are not engineered to tolerate failures or attacks. The failure of this compliance-centric model is empirically evident in the defense industrial base. A 2025 industry survey found that while 69% of contractors claimed National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 compliance, only 30% passed verified assessments [1]. Concurrently, malware infections at major defense contractors [2] demonstrate that IT-focused checklists do not ensure the engineering rigor required to prevent adversary access.
This failure stems from a misapplication of “reasonable care.” Legally defined as the prudence of a rational person [3], this standard is typically interpreted in cybersecurity as adherence to accepted best practices [4], such as NIST Cybersecurity Framework (CSF) or Cybersecurity Maturity Model Certification (CMMC). However, for Cyber Safety, where digital failure creates physical harm, administrative adherence is insufficient. Therefore, we argue that in the context of cyberphysical systems, Reasonable Care requires the verifiable application of systems security engineering (SSE) principles— specifically traceability, assurance, and resilience—to ensure that a system remains safe even when it is not secure. We argue that a valid standard of care for the built environment must shift from administrative compliance checklists in favor of systems engineering rigor. Through a policy mapping of the U.S. critical infrastructure policy corpus (2000–2025), we classify requirements by obligation (Administrative, Coordination, or Engineering). The analysis reveals a systemic “Verification Gap”: while policies mandate activity (plans, meetings, notifications), they lack mandates for efficacy (engineering evidence that the hazard is neutralized). We propose closing this gap with a three-part engineering standard, (1) traceability from hazard to control (e.g., CyberInformed Engineering [5]), (2) structured assurance cases (e.g., ISO/IEC/IEEE 15026-2 [6]), and (3) the mandatory capacity to withstand attack (NIST SP 800-160 Vol. 2 [7]), supported by a fourth economic pillar: a federal resilience incentive structure designed to offset the operational costs of these rigorous constraints. II. D IVERGENT O BJECTIVES : S AFETY C ONSTRAINTS VS . S ECURITY C ONTROLS A fundamental safety gap exists in the built environment because current policy often conflates the data-centric goals of Information Technology (IT) with the physics-centric constraints of Operational Technology (OT). While used interchangeably in regulation, Cyber Security and Cyber Safety govern distinct system properties. Security, as defined in NIST SP 800-160 vol. 1 [8], protects assets from adversarial compromise, prioritizing the CIA Triad (Confidentiality, Integrity, Availability). In contrast, Safety is an emergent property concerned with preventing loss of life, injury, or environmental damage [9].
The conflict arises because standard IT security controls frequently enforce “fail-secure” states (e.g., locking access to protect data) that directly contradict the “fail-safe” requirements of physical systems (e.g., venting pressure or maintaining manual overrides). As shown in Table I, compliant security controls like account lockouts and automated patching have actively introduced latent physical hazards into operational environments. In these scenarios, the security control becomes the safety risk.
as the seed corpus, the dataset skews toward Department of War (DoW) and CNSS issuances, with the remaining sectors represented by their principal sector-specific regulations. We filtered this corpus using Boolean searches for keywords such as “safety” and “resilience,” verified applicability to the sixteen critical infrastructure sectors defined under PPD-21 [17] (a framework retained and superseded by NSM-22 [18] in 2024), and restricted the timeline to 2000–2025. This process eliminated outdated guidance while capturing the significant acceleration in policy issuance illustrated in Figures 1 and 2.
TABLE I T HE C OMPLIANCE PARADOX : S ECURITY C ONTROLS VS . S AFETY C ONSTRAINTS Security Control Account Lockout (3 failed attempts) Fail-Secure Defaults (Electronic Locks) Automated Patching
Encryption Overhead
Intended IT Benefit Prevents Brute Force Attacks Prevents Physical Theft Vulnerability Remediation
Data Confidentiality
Real-World Safety Failure KNX Devices (2023): Restrictive lockouts denied operator access to building control systems during emergency conditions [10]. Tesla (2025): Electronic door latches failed during battery fires, trapping occupants and delaying rescue (15 fatalities linked to egress failure) [11]. Advantech WebAccess: Flawed patches introduced authentication bypasses and forced unplanned Supervisory Control and Data Acquisition (SCADA) downtime [12]. Real-Time Control: Transport Layer Security (TLS) handshakes introduced latency exceeding the sub-100 ms budgets required by real-time safety loops [13].
To resolve this, policy must shift the engineering objective from pure security towards Cyber Resilience. NIST SP 800160 Vol. 2 defines resilience as the ability to “anticipate, withstand, recover from, and adapt to” adverse conditions [7]. For the built environment, withstanding is the critical differentiator. Unlike IT systems that can reboot to restore integrity, critical infrastructure must possess graceful extensibility—the capacity to stretch under stress and continue operating in a degraded state to preserve life [14]. This shift redefines the legal concept of “Reasonable Care” beyond simple checklist compliance to a duty of professional judgement, where engineers must demonstrate that they have actively identified and mitigated foreseeable cyber-physical risks [15].
Fig. 1. Temporal Distribution of Policy Corpus. The analysis highlights a significant acceleration in policy issuance from 2020–2025 (highlighted in red), reflecting increased federal focus on cyber-related policies.
Fig. 2. Distribution by Issuing Authority. The resulting corpus is heavily weighted toward defense and engineering authorities (DoW, CNSS, NIST).
III. M ETHODOLOGY To determine how U.S. policy currently defines “reasonable care” for cyber-physical systems, we conducted a systematic mapping of critical infrastructure standards. A. Corpus Selection and Filtering We constructed the primary dataset (N = 292) by extending the foundational, but single department, CSIAC DoW Cybersecurity Policy Chart [16] with operational guidance from the sixteen critical infrastructure sectors (e.g., America’s Water Infrastructure Act). Because the CSIAC chart served
B. Systematic Policy Mapping We coded each document (N = 292) across three analytical dimensions to evaluate alignment with Cyber Safety engineering requirements. First, we coded the primary requirement of each document into six mutually exclusive categories to distinguish between static compliance activities and active systems engineering. Strategic Mandates define the legal duty without the technical method (e.g., “manage risk”), while Administrative Compliance focuses on bureaucratic artifacts such as workforce codes
rather than system behavior. Lifecycle Management covers process-oriented requirements tied to acquisition timelines (e.g., NIST RMF steps). Control Checklists are enumerated lists of static security controls (e.g., NIST SP 800-53) focused on component configuration. Incident Coordination mandates reactive reporting and command chains. Finally, Engineering Constraints are technical requirements linking controls to physics-based hazards or firm architectural constraints (e.g., Anti-Tamper, TEMPEST, FDA Medical Device guidance). Second, we mapped the operational intent of each document to the four phases of the NIST SP 800-160 Vol. 2 resilience lifecycle: Anticipate (threat modeling and planning), Withstand (maintaining essential functions during attack), Recover (restoration of services), and Adapt (forensic redesign). Simultaneously, we classified the target environment to isolate the distinct requirements of the built environment. Policies were coded as Enterprise IT if they governed generalpurpose business systems (confidentiality-focused) or CyberPhysical Systems (CPS) if they governed systems where real-time availability and safety are the primary criteria (e.g., ICS, weapons systems). This mapping reveals the structural emphasis of the current regulatory environment for both IT and CPS (see Figure 3). Anticipate Admin Compl. Lifecycle Mgmt. Incident Coord. Control Checklist Eng. Constraint
n = 48
Withstand n=4
NSM-22
TSA SD-02C DoDD 3020
n = 40
n=5
AWIA 2018
CNSSD 504
n = 11 DHS STCP
n=0
n = 17
n = 39
CISA CPG
CMMC
n = 23 CISA SbD
n = 12
Recover n=1 n=0
Adapt n=0 n=3 DoDI 5000.02
n = 10
n=2
CIRCIA
FISMA 2014
n=0
n=0
n=1
10CFR73.54 CNSSI-1015
n=2
expansion, including release of the full coded dataset, is reserved for a forthcoming extended study. IV. F INDINGS AND P ROPOSED S TANDARD OF C ARE The application of the policy mapping framework reveals a critical divergence: while the volume of cybersecurity guidance has exploded, the core definition of “reasonable care” remains misaligned with verifiable safety outcomes. As shown in Figure 4, federal policy has successfully universalized Administrative Compliance and Incident Coordination, effectively defining care as the ability to document defenses and report failures. However, this regime emphasizes governance artifacts at the expense of engineering evidence about system behavior. To resolve this, we identify three major disconnects and propose a modernized standard of care that re-anchors liability protection in verifiable engineering artifacts. Anticipate Admin Compl. Lifecycle Mgmt. Incident Coord. Control Checklist Eng. Constraint
n = 23
Withstand n=3
NSM-22
TSA SD-02C
n = 12
n=2
AWIA 2018
CNSSD 504
n=6 DHS STCP
n = 10
n=0 n = 29
CISA CPG
CMMC
n = 17
n = 12
FAA AC-20 115D
Recover n=0 n=0 n=7 CIRCIA
Adapt n=0 n=1 PHMSA API-1173
n=0
n=0
n=0
n=1
n=2
10CFR73.54 CNSSI-1015
FERC 18CFR12
Fig. 4. Distribution of Policy Clauses by Requirement Type for CPS in critical infrastructure (the built environment). This heat map visualizes the frequency of clauses (n = 125) across five requirement categories (rows) and four resilience phases (columns). Darker cells indicate a higher density of mandates.
A. Finding 1: The “Delegated” Defense Strategy
FERC 18CFR12
Fig. 3. Distribution of the Full Policy Corpus (All Domains). This heat map visualizes the frequency of mandates (n = 218) across the NIST resilience lifecycle for the entire filtered dataset, excluding high-level strategic mandates. The distribution reveals a strong bias toward the Anticipate phase (n = 139), dominated by administrative compliance and lifecycle management obligations. This represents the broad cyber regulatory volume, including generic enterprise IT governance.
Finally, to resolve the ambiguity of regulations that act as administrative “shells,” we performed a Pointer-Target analysis. We identified documents acting as “Pointers” (e.g., 10 CFR 73.54) that mandate external “Targets” (e.g., NIST SP 800-53). We coded obligations based on the engineering rigor of the target standard to ensure the analysis reflects the technical reality rather than the administrative language. C. Analytical Constraints The corpus was constructed and coded by the authors. This methodology maps regulatory text by mention frequency, not organizational implementation or adoption maturity. Policies drafted for IT environments are coded as written, without assuming CPS-specific operational adjustments, and the scope is restricted to the U.S. federal corpus. A sector-balanced
The dataset reveals a distinct “Delegated” defense posture in the Withstand phase. As shown in Table II, while the majority of policy mandates are concentrated in the Anticipate phase (dominated by administrative preparation), the mission-critical Withstand phase (n = 46) shifts strategy. Of these Withstand obligations, 87% utilize “pointers” that link legal compliance to external technical standards rather than defining specific performance criteria. This delegation strategy is not inherently flawed, it leverages the specialized expertise of standard-setting bodies. However, analysis reveals a critical calibration failure in the selection of these targets: • The Miscalibrated Pointer (61%): The majority of pointers (n = 28) delegate defense to generic IT frameworks (e.g., NIST SP 800-53). These references are effectively hollow for CPS: they enforce data confidentiality rules (e.g., logging, passwords) on systems that require physical resiliency. While excellent for IT data, they lack the hazard analysis requirements necessary for the built environment. • The Resilient Pointer (26%): A minority (n = 12) delegates to domain-specific engineering standards (e.g.,
International Society of Automation (ISA) / International Electrotechnical Commission (IEC) 62443 [19], IMO MSC.428 [20]). We note that these standards do prescribe the missing elements of reasonable care. For example, ISA/IEC 62443-3-2 mandates risk assessment based on physical segmentation (Zones/Conduits), and IMO MSC.428 ties cyber risk directly to the vessel’s Safety Management System (SMS). TABLE II D ELEGATED D EFENSE S TANDARDS AND T HEIR T REATMENT OF “R EASONABLE C ARE ” Obligation Type Control Checklists
Engineering Constraints
Delegated Standard Details Primary Tar- Nature of “Reasonable Care” gets NIST SP Administrative: Mandates audit 800-53 trails, password complexity, and (IT General) boundary protection. NIST SP Gap: Prescribes controls without 800-171 requiring a hazard analysis to jus(CUI Data) tify them. ISA/IEC Functional: Mandates safe-state 62443 failures, zone partitioning, and de(Industrial) terminable degradation. IMO Value: Explicitly links security MSC.428 controls to physical consequence (Maritime) (e.g., HAZOP/SMS).
Proposed Standard I: Hazard-Specific Traceability A valid standard of care must require hazard-specific traceability. Policy should mandate the risk assessment framework of engineering standards (such as ISA/IEC 62443-3-2 [19]) that require partitioning systems based on physical consequence rather than network connectivity. However, because traditional component-based assessments cannot model complex system interactions, regulation must endorse a holistic, systems-based methodology, such as Cyber-Informed Engineering (CIE) [5] or System-Theoretic Process Analysis (STPA) [21], [22], to derive the underlying hazard scenarios. Reasonable care is demonstrated only when an asset owner can prove, via bi-directional traceability, that a digital control was selected explicitly to mitigate/prevent a physical consequence identified in a Consequence-Driven Cyber-Informed Engineering (CCE) or systems-theoretic analysis. B. Finding 2: The “Misplaced” Recovery Standard Current policy creates a resilience gap in the Recover phase (n = 8 for CPS) by substituting “Notification” for “Navigation.” Our analysis shows that CPS Recover obligations consist almost exclusively (88%, n = 7) of Incident Coordination mandates (e.g., PPD-41, Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA)). These policies enforce a standard of informing the government of failure (Notification) or executing organizational Continuity of Operations Plans (COOP), but fail to enforce a standard for engineering the system to safely override or degrade during that failure. While COOP mandates ensure personnel know where to go during a crisis, they rarely prescribe the technical logic required
for a cyber-physical system to recover its safe state without digital connectivity. The single Engineering Constraint in this phase (n = 1) shows where the line is currently drawn. The Committee on National Security Systems Instruction (CNSSI1015) does its own job well, standardizing the generation and retention of audit logs so that an incident can be reconstructed after the fact. That evidence is necessary, but it sits alongside the recovery problem rather than solving it. Nothing in the Recover phase obligates an operator to engineer the system so that it can reach a safe state on its own when the digital layer is degraded or gone. The engineering that real recovery would require, such as fail-safe logic and determinable degradation, does exist in the corpus, but it lives in a narrow place. It appears inside the small set of delegated technical standards identified in Finding 1, where references like ISA/IEC 62443 [19] and IMO MSC.428 [20] do call for safe-state behavior and graceful degradation. The gap is one of reach, not knowledge. Those standards bind only the operators who fall under a regulator that points to them, while the generally applicable Recover obligations across the corpus ask for notification and continuity planning rather than for evidence that the system itself can return to a safe state. For most asset owners, then, engineered recovery is available in principle but never actually required by policy. By treating Recover as a reporting step, the broadly binding policy leaves the connection between an incident and the engineering work done to survive it unmade, so an operator can satisfy its recovery duties without ever showing the system was built to ride through the event. We note a methodological caveat. Because each clause is mapped to a single resilience phase, some safe-state requirements that a reader might place in Recover were coded under Withstand. This boundary is a feature of the coding scheme rather than of the standards, which treat withstanding and recovering as a continuum. The finding does not rest on that boundary. It rests on the observation that the broadly binding obligations are notification while the engineered safe-state requirements are confined to a small set of delegated standards. Proposed Standard II: The Assurance Case as the Recovery Link To close the verification gap, regulation must mandate structured assurance cases (e.g., ISO/IEC/IEEE 150262) that link Recover obligations back to Withstand engineering constraints. An assurance case acts as the “Navigation Plan” for recovery, allowing an operator to claim reasonable care not by showing a phone log to the Cybersecurity and Infrastructure Security Agency (CISA) (Notification), but by organizing existing engineering evidence into a cohesive argument proving the system is designed to recover to a safe state. C. Finding 3: The Adaptation Anomaly The final phase of the resilience lifecycle, Adapt (n = 3), reveals a critical divergence in how “Reasonable Care” is applied. This phase contains the only significant “Right-ofBoom” engineering constraints (n = 2 for the built en-
vironment), and they are exclusively driven by established sector-specific regulators: TSA SD 1582-21-01 [23] for public transportation and passenger rail and FERC 18 CFR Part 12 for dams. Our data highlights a possible regression in the rail industry: the 2024 Transportation Security Administration (TSA) Surface Cyber Risk Management (SCRM) Notice of Proposed Rulemaking (NPRM) [24] falls into the Anticipate/Control Checklist category. While the preceding SD 1582-21-01 explicitly mandated network segmentation, the NPRM replaces this hard constraint with a “performance-based” Cyber Risk Management Program [25]. By allowing operators to substitute physical adaptation architectures with administrative remediation plans (Corrective Action Plans), the NPRM effectively sunsets the requirement for resilience. This confirms that “Reasonable Care” is currently a function of regulatory geography. If an asset falls under the jurisdiction of a safety-critical regulator such as the Federal Energy Regulatory Commission (FERC), it is required to be resilient. If it falls under general cyber policy, where the permanent standard is merely a plan, then it is only required to be compliant. Proposed Standard III: Cyber Resiliency Engineering Reasonable care must mandate the capacity to withstand and adapt to attacks: reporting incidents is necessary, but regulations should also require that systems maintain or return to a safe state during and after an incident. We propose that the standard of care for critical infrastructure must align with NIST SP 800-160 Vol. 2 (Cyber Resiliency Engineering). This requires engineering “Left-of-Boom” capabilities (e.g., adaptive response) and explicitly mandating non-digital fallbacks (e.g., mechanical interlocks and analog governors) that provide deterministic safety guarantees, ensuring that the system can “fight through” a compromise without entering a hazardous state. D. Further Recommendation: Incentivizing the Cost of Care Implementing the engineering-based standard of care proposed in the findings imposes a “safety premium.” Because resilient architectures (e.g., segmentation, diversity) are inherently less efficient than converged IT networks, the market will naturally optimize for fragility. To ensure the safe state is a viable business decision, federal policy must bridge this cost delta by incentivizing the specific technologies that enable systems to withstand and adapt to compromise. A “Resilience Incentive Program” should subsidize the high-friction architectures that compliance checklists ignore, specifically deterministic out-of-band recovery networks, hardware-enforced segmentation (e.g., unidirectional gateways), and non-digital fallbacks (e.g., analog governors). By offsetting the lifecycle costs of these right-of-boom capabilities, the government can make it financially feasible for operators to deploy resilient architectures. Policy Takeaway: A higher standard of care requires a lower barrier to entry. Policymakers must incentivize technologies that reduce the friction of Withstand and Adapt capabilities,
ensuring that the “Safe State” becomes not just a legal obligation, but a viable business decision. V. C ONCLUSION Current U.S. cyber policy, centered on security, gives a false impression that safety in cyber-physical systems is assured. By prioritizing administrative compliance, the federal government has established a regime where critical infrastructure owners can demonstrate formal diligence while their systems still lack the ability to withstand disruption. Our analysis confirms that the current “Standard of Care” is defined as the ability to document defenses and report failures, rather than engineering to survive them. For the built environment, this must change. As the kinetic consequences of cyber insecurity escalate, reasonable care must evolve from a static checklist to a dynamic engineering discipline. We must move beyond validating the presence of digital controls (e.g., “is the firewall installed?”) to verifying the preservation of safety properties (e.g., “will the system fail safe if the firewall is breached?”). This demands a standard anchored in three engineering imperatives: Traceability from hazards to requirements, Structured Assurance cases that evolve with the threat, and Resiliency that guarantees physical safety through non-digital fallbacks. Implementing this engineering rigor imposes a “safety premium,” and federal policy must incentivize the necessary investment. But ultimately, we cannot paper over the risks of the physical world. If the United States intends to secure its critical infrastructure against determined adversaries, it must align regulatory obligations with the physical behavior of systems rather than solely with documentation practices. R EFERENCES [1] CyberSheath, “From readiness to reality: The 2025 state of the DIB on CMMC compliance,” Sep. 2025, Accessed: 2026-01-01. [Online]. Available: cybersheath.com/resources/downloads/from-readiness-to-realitythe-2025-state-of-the-defense-industrial-base-on-cmmc-compliance/ [2] A. Gal, “Infostealing malware infections in the U.S. military & defense sector: A cybersecurity disaster in the making,” Feb. 2025, Accessed: 2025-12-29. [Online]. Available: www.infostealers.com/article/infostealing-malware-infections-inthe-u-s-military-defense-sector-a-cybersecurity-disaster-in-the-making/ [3] Legal Information Institute, “reasonable care,” Nov. 2020, Accessed: 2026-01-14. [Online]. Available: www.law.cornell.edu/wex/reasonable care [4] Center for Internet Security, “Cis controls: A guide to defining reasonable cybersecurity,” Oct. 2024, Accessed: 2026-01-14. [Online]. Available: learn.cisecurity.org/defining-reasonable-security [5] A. A. Bochman and S. G. Freeman, Countering cyber sabotage : introducing consequence-driven, cyber-informed engineering (CCE). Abingdon, Oxon: CRC Press, 2021. [6] ISO/IEC/IEEE, ISO/IEC/IEEE 15026-2:2022 Systems and software engineering — Systems and software assurance — Part 2: Assurance case, International Organization for Standardization Standard ISO/IEC/IEEE 15 026-2:2022, Oct. 2022, Accessed: 2025-12-29. [Online]. Available: www.iso.org/standard/80625.html [7] R. Ross, V. Pillitteri, R. Graubart, D. Bodeau, and R. McQuaid, “Developing cyber-resilient systems: A systems security engineering approach,” National Institute of Standards and Technology, Gaithersburg, MD, Tech. Rep. NIST Special Publication 800-160 Vol. 2 Rev. 1, 2021. [8] R. Ross, M. McEvilley, and J. Carrier Oren, “Engineering trustworthy secure systems,” National Institute of Standards and Technology, Gaithersburg, MD, Tech. Rep. NIST Special Publication 800-160 Vol. 1 Rev. 1, 2022.
[9] N. Leveson, Engineering a safer world : systems thinking applied to safety, 1st ed., ser. Engineering systems. Cambridge: The MIT Press, 2011. [10] CISA. (2023, Aug.) ICS Advisory (ICSA-23-236-01) KNX Devices. Accessed: 2025-12-29. [Online]. Available: www.cisa.gov/newsevents/ics-advisories/icsa-23-236-01 [11] D. Hull. (2025, Dec.) 15 people have died in crashes where Tesla doors wouldn’t open. Accessed: 2025-12-29. [Online]. Available: www.bloomberg.com/news/features/2025-12-22/tesla-doorsafety-tied-to-at-least-15-auto-accident-deaths [12] Eduard Kovacs. (2023, Jan.) Advantech Failed to Patch Serious Flaws in SCADA Product. Accessed: 2025-12-29. [Online]. Available: www.securityweek.com/advantech-failed-patchserious-flaws-scada-product/ [13] M. Hlayel, H. Mahdin, and H. A. M. Adam, “Latency analysis of websocket and industrial protocols in real-time digital twin integration,” International Journal of Engineering Trends and Technology, vol. 73, no. 1, pp. 120–135, 2025, Accessed: 2025-12-29. [Online]. Available: doi.org/10.14445/22315381/IJETT-V73I1P110 [14] K. Guttieri, “Fighting through disruption: Reframing cyber resilience for power projection and strategic credibility,” The cyber defense review, vol. 10, no. 1, pp. 93–114, 2025. [15] L. Niemeyer and D. Haegley, “Developing an engineering standard of care for cyber safety,” The Military Engineer, vol. 116, no. 749, pp. 68–71, 2024. [16] Cyber Security and Information Systems Information Analysis Center (CSIAC), “The DoD Cybersecurity Policy Chart,” Department of Defense Information Analysis Center, Nov. 2025, Accessed: 2025-1230. [Online]. Available: csiac.dtic.mil/resources/the-dod-cybersecuritypolicy-chart/ [17] Office of the Press Secretary, “Presidential policy directive 21 (ppd-21): Critical infrastructure security and resilience,” February 2013. [18] Administration of Joseph R. Biden, Jr., “National Security Memorandum on Critical Infrastructure Security and Resilience (NSM-22),” White House, Apr. 2024, Accessed: 2025-12-29. [Online]. Available: www.govinfo.gov/content/pkg/DCPD-202400358/pdf/DCPD202400358.pdf [19] ISA, ANSI/ISA-62443-3-2-2020: Security for industrial automation and control systems, Part 3-2: Security risk assessment for system design, International Society of Automation Standard ANSI/ISA62 443-3-2, Aug. 2020, Accessed: 2025-12-29. [Online]. Available: www.isa.org/products/ansi-isa-62443-3-2-2020-security-for-industrial-a [20] International Maritime Organization, “Resolution MSC.428(98): Maritime Cyber Risk Management in Safety Management Systems,” Maritime Safety Committee (MSC), Jun. 2017, Accessed: 2025-12-30. [Online]. Available: wwwcdn.imo.org/localresources/en/KnowledgeCentre /IndexofIMOResolutions/MSCResolutions/MSC.428(98).pdf [21] N. G. Leveson and J. P. Thomas, “Stpa handbook,” Massachusetts Institute of Technology, Tech. Rep., March 2018. [22] W. Young and N. Leveson, “Systems thinking for safety and security,” in Proceedings of the 29th Annual Computer Security Applications Conference. New York, NY, USA: ACM, 2013, pp. 1–8. [23] Transportation Security Administration, “Security Directive 158221-01E: Enhancing Public Transportation and Passenger Railroad Cybersecurity,” Dec. 2021, Accessed: 2026-01-07. [Online]. Available: www.tsa.gov/sites/default/files/signed security-directive-1582-2101e-and-transmittal-memo 508c.pdf [24] ——, “Enhancing Surface Cyber Risk Management,” Federal Register, vol. 89, no. 216, pp. 88 488– 88 566, November 2024, Accessed: 2025-12-29. [Online]. Available: www.federalregister.gov/documents/2024/11/07/202424704/enhancing-surface-cyber-risk-management [25] Grand Trunk Corporation and Illinois Central Railroad Company, “Petitioners’ Opening Brief, Grand Trunk Corp. v. Transportation Security Administration,” United States Court of Appeals for the Seventh Circuit, Nos. 24-2109 & 24-2156, November 2024, Accessed: 2025-12-29. [Online]. Available: www.wileyconnect.com/assets/htmldocuments/Petitioners%20Opening %20Brief%20Grand%20Trunk%20v%20TSA.pdf
A PPENDIX A P OLICY ACRONYMS The following acronyms denote the policy instruments referenced in the figures and findings. 10 CFR 73.54 Protection of Digital Computer and Communication Systems (Nuclear) AWIA America’s Water Infrastructure Act (Sec. 2013) CIRCIA Cyber Incident Reporting for Critical Infrastructure Act CISA CPG Cross-Sector Cybersecurity Performance Goals CISA SbD CISA Secure by Design Pledge CMMC Cybersecurity Maturity Model Certification CNSSD 504 Protecting National Security Systems from Insider Threat CNSSI-1015 Enterprise Audit Management for National Security Systems DHS STCP DHS Soft Targets and Crowded Places Resources DoDD 3020.40 Mission Assurance DoDI 5000.02 Operation of the Adaptive Acquisition Framework FAA AC-20 Airborne Software Development Assurance 115D FERC 18 CFR Safety of Water Power Projects (Dam Pt. 12 Safety) FISMA Federal Information Security Modernization Act of 2014 NSM-22 National Security Memorandum on Critical Infrastructure Security and Resilience PHMSA API Pipeline Safety Management Systems (API 1173 RP 1173) PPD-21 Critical Infrastructure Security and Resilience (superseded by NSM-22) PPD-41 United States Cyber Incident Coordination TSA SD-02C TSA Security Directive Pipeline-2021-02C TSA SD 1582- TSA Enhancing Public Transportation and 21-01 Passenger Railroad Cybersecurity