Engineer critical services to anticipate, withstand, recover, and adapt

Source facts: resilience begins after prevention is assumed imperfect

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.

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

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

DSE recommendation: define the service outcome before selecting techniques

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

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

DSE recommendation: combine techniques around credible adverse conditions

Write adverse-condition scenarios. Include credential compromise, destructive administration, corrupted data, unavailable communications, supplier failure, malicious persistence, and loss of a shared dependency. State what the service must still accomplish.

Reduce propagation. Segment trust, restrict privilege, separate recovery authority, and define integrity checks so one compromise cannot silently rewrite every operating and recovery copy.

Create genuinely different paths. Redundancy that repeats the same vulnerability or administrative plane can reproduce the same failure. Use diversity where its operational cost is justified and test the alternate path independently.

Prepare controlled degradation. Document which features can stop, which transactions can queue, what becomes read-only, who may authorize a manual process, and how deferred work is reconciled.

Instrument adaptation. Collect evidence that reveals changing threats, failed assumptions, integrity loss, and recovery performance. Assign an owner to translate observations into design changes.

DSE recommendation: test survival, not only failover

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

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

Official references

National Institute of Standards and Technology, SP 800-160 Volume 2 Revision 1: Developing Cyber-Resilient Systems—A Systems Security Engineering Approach, December 9, 2021; reviewed August 11, 2026.