NIST Special Publication 800-160 Volume 2 Revision 1 describes cyber resiliency engineering as a systems discipline for developing systems that can anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises involving cyber resources. Its purpose is not to declare prevention unimportant. It recognizes that systems support missions over time and that determined adversaries, latent defects, and disrupted dependencies can defeat individual safeguards.
\n\nThe publication organizes cyber resiliency around goals, objectives, techniques, approaches, and design principles. Its techniques include adaptive response, analytic monitoring, coordinated protection, deception, diversity, dynamic positioning, non-persistence, privilege restriction, realignment, redundancy, segmentation, substantiated integrity, unpredictability, and deception. NIST does not prescribe every technique for every system. Organizations select and tailor constructs for their mission, system life cycle, threat environment, and risk.
\n\nCyber resilience is also broader than restoration. A system may need to continue a reduced but safe function during an attack, preserve trustworthy state for recovery, prevent one compromised component from controlling the whole service, and incorporate lessons into future architecture. Recovery time alone does not describe those outcomes.
\n\nStart with one business or safety outcome whose loss would matter. Name the accountable owner and describe the minimum acceptable service during normal, degraded, recovery, and emergency operation. Record maximum tolerable interruption, data-loss tolerance, integrity requirements, manual alternatives, safety constraints, and the decisions that only authorized people may make.
\n\nMap the complete service, not just its visible application. Include identity, name resolution, secrets, network paths, cloud control planes, data stores, time sources, facilities, vendors, communications, staffing, and recovery tooling. Mark single points of failure and dependencies shared with other critical services. A redundant application is not resilient when both instances rely on one administrative identity path or one corrupted data source.
\n\nExercise the service while a trusted component is assumed compromised. Remove a dependency, introduce delayed or suspect data, deny an administrative path, and require the team to identify trustworthy state. Observe whether essential outcomes continue, whether responders know the degradation limits, and whether recovery reconnects a still-compromised dependency.
\n\nRetain evidence for each objective: detection time, time to isolate, minimum service achieved, integrity decisions, recovery point, recovery time, operator workload, external coordination, and defects found. After each exercise or incident, decide whether the architecture, operating procedure, supplier requirement, or risk acceptance must change. Cyber resilience becomes credible when the organization can show how the service behaves through adversity—not when a diagram merely contains redundant boxes. Include unresolved weaknesses in the service risk record, with interim operating limits and an accountable decision-maker.
\n\n