Resilience comes from knowing which services matter, what they depend on, how long each dependency can be unavailable, what capacity remains during failure, and who has authority to recover or degrade service. This guide turns those questions into an operating model.
Substantively reviewed . The current source baseline uses NIST cyber-resiliency and contingency-planning guidance plus CISA resilient-power, infrastructure-dependency, and emergency-communications resources.
Infrastructure resilience is the ability to anticipate disruption, continue the most important service functions, recover within an acceptable window, and adapt after failure. NIST SP 800-160 Volume 2 Rev. 1 frames cyber resiliency around the ability to anticipate, withstand, recover from, and adapt to adverse conditions.NIST SP 800-160 Vol. 2 Rev. 1 NIST contingency-planning guidance similarly begins with business-impact analysis, recovery requirements, plan development, testing, and maintenance.NIST SP 800-34 Rev. 1
The practical implication is simple: resilience should not be organized around a list of servers, generators, carriers, or vendors. It should be organized around services and their dependency chains. CISA's Infrastructure Dependency Primer emphasizes that energy, communications, IT, transportation, water, and other systems are interdependent; failure in one can disrupt several others.CISA Infrastructure Dependency Primer
This guide uses seven operating layers: service criticality, dependency mapping, resilient power and communications, recovery architecture, maintenance and spares, supplier/concentration risk, and exercises/evidence.
Start with the outcome users or operators need, then identify what can degrade. A service that normally uses ten application nodes, two network paths, and a full analytics stack may only need a smaller transaction path to continue safely during a disruption.
Do not automatically copy contractual SLA numbers into engineering recovery targets. A contractual availability percentage, a recovery-time objective, a safety requirement, and a user-experience objective answer different questions.
For each important service, map the dependencies that must be available for the minimum viable service to work:
Mark single points of failure and hidden common-mode dependencies. Two carriers that share the same local conduit, two cloud services that depend on the same identity tenant, or two backup systems that require the same administrator account are not truly independent.
CISA's Resilient Power Best Practices recommends defining resilience requirements, performing a gap analysis, planning operations and maintenance, testing readiness, and considering telecommunications together with power continuity.CISA Resilient Power Best Practices
CISA's National Emergency Communications Plan emphasizes operable, interoperable, resilient, and secure communications during response and recovery.CISA National Emergency Communications Plan Even organizations outside public safety can use the underlying principle: do not make the same communications system you are recovering the only way responders can coordinate.
For each service, document which recovery pattern is actually implemented rather than assuming the word "redundant" is sufficient.
Recovery plans should state what is intentionally not recovered first. Capacity, people, network paths, and supplier availability may not support restoring every service simultaneously.
Many outages are made worse by maintenance debt, undocumented changes, failed batteries, unavailable spares, or recovery equipment that was never tested under load. Maintain evidence for:
A recovery design that depends on a part with a six-month lead time is not a recovery design unless that lead time has been accepted explicitly.
Supplier resilience is not solved by collecting a questionnaire once. Maintain an inventory of dependencies whose failure can materially affect the service and record:
For detailed supplier governance, use Third-Party Technology Governance and Public-Sector Third-Party Cyber Risk.
NIST contingency-planning guidance includes testing, training, exercises, and plan maintenance as part of the lifecycle.NIST SP 800-34 Rev. 1 Build exercises around realistic loss of dependency rather than isolated component tests.
Capture actual recovery time, manual workarounds, missing access, missing contacts, data reconciliation issues, and decisions that required executive approval. Turn those findings into owned remediation rather than a presentation-only after-action report.
For remote sites and distributed estates, continue with Edge Infrastructure Resilience. For telemetry and service-health design, use Cloud Observability.
Follow the next implementation topic without returning to search.
Plan resilient edge deployments and carrier dependencies
Continue readingDefine useful observability outcomes, telemetry, and service signals
Continue readingUse the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.