K05 assurance architecture
Critical-function recovery objectives
Direct answer
Define and test function-specific safe-state, recovery-time, recovery-point, evidence, and service-priority objectives rather than a single enterprise metric.
Evidence boundary. These records describe architecture, control relationships, test requirements, and legal-source status. They do not certify a facility, authorize a mission, prove deployment, or replace current facility-specific engineering and legal review.
Objective
Define and test function-specific safe-state, recovery-time, recovery-point, evidence, and service-priority objectives rather than a single enterprise metric.
Implementation evidence
- approved design and scope
- exact configuration or policy artifact
- test result
- defect and exception record
- operating observation where deployment is claimed
- last review and evidence owner
Evidence of failure or insufficiency
- missing or stale artifact
- control bypass
- unresolved defect
- scope mismatch
- unsupported compliance label
- unavailable operating evidence
Qualified source mappings
- NIST SP 800-82 Rev. 3 — INFORMSOT security program, architecture, risk, and control guidance
Applies as guidance when OT is in scope; Revision 3 remains final while Revision 4 is under development.
Source record - NIST SP 800-207 — INFORMSZero Trust Architecture principles
Applies to identity- and resource-centric access design; does not replace OT safety analysis.
Source record - INL Consequence-driven Cyber-informed Engineering — INFORMSConsequence prioritization and critical-function assurance
Useful for high-consequence pathway analysis; not a regulatory certification.
Source record
Assurance claims
Authority boundary. Control design and mapping do not create mission authority, license approval, certification, or universal applicability.