pith. sign in

arxiv: 2606.13612 · v1 · pith:Y4FC4GKInew · submitted 2026-06-11 · 💻 cs.CR

Beyond the IT Checklist: Engineering a Reasonable Standard of Care for Cyber Safety

Pith reviewed 2026-06-27 06:10 UTC · model grok-4.3

classification 💻 cs.CR
keywords cyber policycritical infrastructureresilience lifecyclestandard of carecyber-physical systemsassurance casescyber resiliency engineeringhazard traceability
0
0 comments X

The pith

U.S. cyber policy concentrates obligations in threat anticipation and administrative compliance while leaving physical hazard response to mismatched IT controls.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper maps 292 critical infrastructure policy documents spanning 2000-2025 onto the NIST SP 800-160 Vol. 2 resilience lifecycle to show how reasonable care is currently defined. Obligations cluster in the Anticipate phase with emphasis on documentation and compliance, whereas Withstand and Recover phases delegate to IT control catalogs that do not address physics-based consequences of digital failure. Three disconnects emerge: miscalibrated standards, recovery treated as notification rather than engineered response, and uneven adaptation duties across sectors. The authors therefore argue for a revised standard of care built on hazard-specific traceability, structured assurance cases, and cyber resiliency engineering, supported by incentives that make resilient design a practical choice.

Core claim

Analysis of the policy corpus shows that reasonable care for cyber-physical systems is operationalized mainly through administrative compliance in the Anticipate phase, while Withstand and Recover phases rely on delegated IT-focused catalogs poorly aligned with kinetic hazards; this produces three disconnects that a modernized standard anchored in hazard-specific traceability, structured assurance cases, and cyber resiliency engineering would correct.

What carries the argument

Mapping of policy obligations to the three phases of the NIST SP 800-160 Vol. 2 resilience lifecycle (Anticipate, Withstand, Recover), which reveals concentration in administrative tasks and misalignment with physics-based hazards.

If this is right

  • Policy documents should require explicit traceability between digital controls and specific physical hazards rather than generic compliance checklists.
  • Recovery obligations should shift from incident notification to engineered navigation of system states that limit physical damage.
  • Assurance cases must replace sole reliance on control catalogs to demonstrate that systems can withstand and recover from cyber events.
  • Federal incentives should accompany the new engineering obligations so that resilient architectures become economically viable for operators.
  • Adaptation and update requirements should be standardized across sectors instead of varying by delegated reference.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Operators in energy, transportation, and water sectors would need to integrate systems engineering teams earlier in design to meet traceability demands.
  • Regulators could develop sector-specific pilot programs that test structured assurance cases on existing infrastructure.
  • The approach might extend naturally to supply-chain risk management where digital components affect physical outcomes.
  • Long-term, this framing could influence liability standards in litigation involving cyber-induced physical damage.

Load-bearing premise

The selected 292 documents and their assignment to resilience phases accurately reflect how reasonable care is understood and enforced across critical infrastructure sectors.

What would settle it

Empirical evidence that current IT control catalogs, when applied to cyber-physical systems, have prevented or limited kinetic harms at scale without additional engineering practices such as hazard traceability or assurance cases.

Figures

Figures reproduced from arXiv: 2606.13612 by F. Brett Berlin, Kathryn B. Laskey, Linton Wells II, Matthew E. Jablonski.

Figure 1
Figure 1. Figure 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 [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Distribution by Issuing Authority. The resulting corpus is heavily weighted toward defense and engineering authorities (DoW, CNSS, NIST). B. Systematic Policy Mapping We coded each document (N = 292) across three analytical dimensions to evaluate alignment with Cyber Safety engineer￾ing requirements. First, we coded the primary requirement of each document into six mutually exclusive categories to distingu… view at source ↗
Figure 4
Figure 4. Figure 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 The dataset reveals a distinct “Delegated” defense posture … view at source ↗
Figure 3
Figure 3. Figure 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 cy… view at source ↗
read the original 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper constructs and codes a corpus of 292 critical infrastructure policy documents (2000-2025) and maps obligations onto the NIST SP 800-160 Vol. 2 resilience lifecycle phases. It reports that obligations concentrate in the Anticipate phase with emphasis on administrative compliance, while Withstand and Recover phases delegate to IT-focused control catalogs poorly aligned with physics-based hazards. Three disconnects are identified (miscalibrated delegated standards, recovery defined as notification, uneven adaptation requirements), leading to a proposal for a modernized standard of care anchored in hazard-specific traceability, structured assurance cases, and cyber resiliency engineering, together with targeted federal incentives.

Significance. If the corpus mapping is reproducible, the work supplies a systematic policy critique that could guide updates to standards for cyber-physical systems by shifting emphasis from documentation to engineered resilience. The explicit linkage of observed disconnects to NIST phases and the concrete engineering recommendations constitute a strength; however, the absence of validation for the mapping limits the immediate policy impact.

major comments (2)
  1. [Corpus construction and coding paragraph] The section describing corpus construction and coding (abstract and the paragraph beginning 'We construct and code a corpus...'): no protocol is supplied for identifying obligations, assigning language to Anticipate/Withstand/Recover phases, distinguishing 'administrative compliance' from 'physics-based hazards,' or for inter-rater reliability and sampling frame. Because the reported phase concentrations and the three disconnects rest directly on these maps, the central empirical claim cannot be evaluated for reproducibility.
  2. [Proposal paragraphs] The proposal for hazard-specific traceability and structured assurance cases (final two paragraphs): these recommendations are derived from the unvalidated maps rather than from any pilot implementation or falsifiable test within the manuscript, so their load-bearing status for the 'modernized standard of care' claim cannot be assessed.
minor comments (1)
  1. [Abstract] The abstract states N=292 but does not enumerate sector coverage or document types; adding a brief table or appendix listing the corpus composition would improve reproducibility without altering the argument.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on reproducibility and the grounding of our policy recommendations. We address each major comment below.

read point-by-point responses
  1. Referee: [Corpus construction and coding paragraph] The section describing corpus construction and coding (abstract and the paragraph beginning 'We construct and code a corpus...'): no protocol is supplied for identifying obligations, assigning language to Anticipate/Withstand/Recover phases, distinguishing 'administrative compliance' from 'physics-based hazards,' or for inter-rater reliability and sampling frame. Because the reported phase concentrations and the three disconnects rest directly on these maps, the central empirical claim cannot be evaluated for reproducibility.

    Authors: We agree that the submitted manuscript presents the corpus construction and coding at a summary level only. In revision we will insert a dedicated methods subsection that specifies: (1) the exact protocol and decision rules used to identify obligations within each document; (2) the mapping criteria that assign language to the NIST Anticipate/Withstand/Recover phases; (3) the operational definitions distinguishing administrative-compliance language from physics-based-hazard language, with illustrative coded excerpts; (4) inter-rater reliability statistics (including Cohen’s kappa) obtained during double-coding of a 10 % sample; and (5) the sampling frame and inclusion/exclusion criteria that produced the final N=292. The revised coding rubric and a sample of coded documents will be supplied as supplementary material. revision: yes

  2. Referee: [Proposal paragraphs] The proposal for hazard-specific traceability and structured assurance cases (final two paragraphs): these recommendations are derived from the unvalidated maps rather than from any pilot implementation or falsifiable test within the manuscript, so their load-bearing status for the 'modernized standard of care' claim cannot be assessed.

    Authors: The proposals are offered as normative engineering recommendations that follow directly from the three disconnects documented in the corpus analysis; they are not presented as the outcome of a pilot study or falsifiable experiment. We will revise the final section to state this distinction explicitly, to reference the relevant safety-engineering literature that supports the proposed practices, and to note that empirical validation of the framework lies outside the scope of the present policy-mapping paper. This clarification strengthens rather than weakens the manuscript’s contribution. revision: partial

Circularity Check

0 steps flagged

No circularity; derivation rests on independent corpus analysis

full rationale

The paper's chain proceeds from construction and coding of an external 292-document policy corpus (2000-2025), through interpretive mapping to NIST SP 800-160 Vol. 2 phases, identification of three disconnects, and a proposal for a modernized standard of care. No equations, fitted parameters, self-definitional loops, or load-bearing self-citations appear. The maps and disconnects are presented as outputs of the corpus coding rather than inputs redefined as results. The proposal is framed as a response to the observed disconnects, not a restatement of the coding protocol itself. This is a standard empirical policy analysis with no reduction of the central claim to its own inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the representativeness of the 292-document corpus and the appropriateness of the NIST SP 800-160 Vol. 2 lifecycle as the analytical frame; no free parameters, invented entities, or additional axioms are stated in the abstract.

axioms (1)
  • domain assumption The NIST SP 800-160 Vol. 2 resilience lifecycle provides a suitable structure for classifying obligations in critical infrastructure cyber policy.
    Invoked to organize the mapping of policy documents into Anticipate, Withstand, and Recover phases.

pith-pipeline@v0.9.1-grok · 5743 in / 1302 out tokens · 20104 ms · 2026-06-27T06:10:38.498034+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

26 extracted references

  1. [1]

    From readiness to reality: The 2025 state of the DIB on CMMC compliance,

    CyberSheath, “From readiness to reality: The 2025 state of the DIB on CMMC compliance,” Sep. 2025, Accessed: 2026-01-01. [Online]. Avail- able: cybersheath.com/resources/downloads/from-readiness-to-reality- the-2025-state-of-the-defense-industrial-base-on-cmmc-compliance/

  2. [2]

    Infostealing malware infections in the U.S. military & defense sector: A cybersecurity disaster in the making,

    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]. Avail- able: www.infostealers.com/article/infostealing-malware-infections-in- the-u-s-military-defense-sector-a-cybersecurity-disaster-in-the-making/

  3. [3]

    reasonable care,

    Legal Information Institute, “reasonable care,” Nov. 2020, Accessed: 2026-01-14. [Online]. Available: www.law.cornell.edu/wex/reasonable care

  4. [4]

    Cis controls: A guide to defining reasonable cybersecurity,

    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. [5]

    A. A. Bochman and S. G. Freeman,Countering cyber sabotage : introducing consequence-driven, cyber-informed engineering (CCE). Abingdon, Oxon: CRC Press, 2021

  6. [6]

    2022, Accessed: 2025-12-29

    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. [7]

    Developing cyber-resilient systems: A systems security engineering approach,

    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 V ol. 2 Rev. 1, 2021

  8. [8]

    Engineering trustwor- thy secure systems,

    R. Ross, M. McEvilley, and J. Carrier Oren, “Engineering trustwor- thy secure systems,” National Institute of Standards and Technology, Gaithersburg, MD, Tech. Rep. NIST Special Publication 800-160 V ol. 1 Rev. 1, 2022

  9. [9]

    Leveson,Engineering a safer world : systems thinking applied to safety, 1st ed., ser

    N. Leveson,Engineering a safer world : systems thinking applied to safety, 1st ed., ser. Engineering systems. Cambridge: The MIT Press, 2011

  10. [10]

    (2023, Aug.) ICS Advisory (ICSA-23-236-01) KNX Devices

    CISA. (2023, Aug.) ICS Advisory (ICSA-23-236-01) KNX Devices. Accessed: 2025-12-29. [Online]. Available: www.cisa.gov/news- events/ics-advisories/icsa-23-236-01

  11. [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-door- safety-tied-to-at-least-15-auto-accident-deaths

  12. [12]

    (2023, Jan.) Advantech Failed to Patch Serious Flaws in SCADA Product

    Eduard Kovacs. (2023, Jan.) Advantech Failed to Patch Serious Flaws in SCADA Product. Accessed: 2025-12-29. [Online]. Available: www.securityweek.com/advantech-failed-patch- serious-flaws-scada-product/

  13. [13]

    Latency analysis of websocket and industrial protocols in real-time digital twin integration,

    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. [14]

    Fighting through disruption: Reframing cyber resilience for power projection and strategic credibility,

    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. [15]

    Developing an engineering standard of care for cyber safety,

    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. [16]

    The DoD Cybersecurity Policy Chart,

    Cyber Security and Information Systems Information Analysis Center (CSIAC), “The DoD Cybersecurity Policy Chart,” Department of Defense Information Analysis Center, Nov. 2025, Accessed: 2025-12-

  17. [17]

    Available: csiac.dtic.mil/resources/the-dod-cybersecurity- policy-chart/

    [Online]. Available: csiac.dtic.mil/resources/the-dod-cybersecurity- policy-chart/

  18. [18]

    Presidential policy directive 21 (ppd-21): Critical infrastructure security and resilience,

    Office of the Press Secretary, “Presidential policy directive 21 (ppd-21): Critical infrastructure security and resilience,” February 2013

  19. [19]

    National Security Memorandum on Critical Infrastructure Security and Resilience (NSM-22),

    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/DCPD- 202400358.pdf

  20. [20]

    2020, Accessed: 2025-12-29

    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/ISA- 62 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

  21. [21]

    Resolution MSC.428(98): Mar- itime Cyber Risk Management in Safety Management Systems,

    International Maritime Organization, “Resolution MSC.428(98): Mar- itime Cyber Risk Management in Safety Management Systems,” Mar- itime Safety Committee (MSC), Jun. 2017, Accessed: 2025-12-30. [On- line]. Available: wwwcdn.imo.org/localresources/en/KnowledgeCentre /IndexofIMOResolutions/MSCResolutions/MSC.428(98).pdf

  22. [22]

    Stpa handbook,

    N. G. Leveson and J. P. Thomas, “Stpa handbook,” Massachusetts Institute of Technology, Tech. Rep., March 2018

  23. [23]

    Systems thinking for safety and security,

    W. Young and N. Leveson, “Systems thinking for safety and security,” inProceedings of the 29th Annual Computer Security Applications Conference. New York, NY , USA: ACM, 2013, pp. 1–8

  24. [24]

    Security Directive 1582- 21-01E: Enhancing Public Transportation and Passenger Railroad Cybersecurity,

    Transportation Security Administration, “Security Directive 1582- 21-01E: Enhancing Public Transportation and Passenger Railroad Cybersecurity,” Dec. 2021, Accessed: 2026-01-07. [Online]. Avail- able: www.tsa.gov/sites/default/files/signed security-directive-1582-21- 01e-and-transmittal-memo 508c.pdf

  25. [25]

    Enhancing Surface Cyber Risk Management,

    ——, “Enhancing Surface Cyber Risk Management,” Federal Register, vol. 89, no. 216, pp. 88 488– 88 566, November 2024, Accessed: 2025-12-29. [On- line]. Available: www.federalregister.gov/documents/2024/11/07/2024- 24704/enhancing-surface-cyber-risk-management

  26. [26]

    Petitioners’ Opening Brief, Grand Trunk Corp. v. Transportation Security Administration,

    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 %...