Notifications
Clear all
Topic starter
10/06/2026 11:34 pm
TL;DR: Enterprise resilience now fails as often in the network control plane as in the data layer, because DNS, routing, CDN, and firewall changes can take services offline even when backups and databases remain intact, according to ControlMonkey. Data recovery is necessary, but it no longer defines uptime, because configuration recoverability is what determines whether users can actually reach the service.
NHIMG editorial — based on content published by ControlMonkey: Rethink your network disaster recovery strategy when the network fails
Questions worth separating out
Q: What breaks when network control-plane configuration is not recoverable?
A: When network control-plane configuration is not recoverable, services can appear healthy internally while remaining unreachable to users.
Q: Why do backups not solve downtime caused by network misconfiguration?
A: Backups protect data, but they do not restore the path to the application.
Q: How do you know if network disaster recovery is actually working?
A: You know it is working when a team can restore reachability quickly, accurately, and repeatably from a known good configuration.
Practitioner guidance
- Map the recoverable control plane Inventory DNS zones, routing rules, CDN policies, firewall settings, and edge configurations that determine service reachability.
- Version network configuration alongside infrastructure Store network control-plane changes in the same reviewable workflow as infrastructure-as-code, including approvals, diffs, and rollback references.
- Test recovery as a reachability exercise Run DR exercises that validate whether users can actually reach applications after DNS, routing, and edge policy loss.
What's in the full article
ControlMonkey's full article covers the operational detail this post intentionally leaves for the source:
- How its daily snapshot and rollback approach is applied to cloud infrastructure state
- The specific network-layer controls it says should be versioned, including DNS, CDN, routing, and firewall policy
- The operational case it makes for treating reachability as part of disaster recovery rather than an afterthought
- Examples of how configuration history reduces reliance on tribal knowledge during incidents
👉 Read ControlMonkey's analysis of network disaster recovery and configuration resilience →
Network control plane recovery gap: are your controls keeping up?
Explore further
12/06/2026 5:48 am
Network control-plane resilience is now a governance problem, not an infrastructure afterthought. The article shows that modern outages often occur when DNS, routing, edge, or firewall configuration fails, even while data remains intact. That means recovery ownership cannot stop at backup teams or storage metrics. Practitioners need to govern the change surface that determines reachability, because business continuity now depends on configuration integrity as much as data durability.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when a service goes dark because of network control-plane drift?
A: Accountability sits with the teams that own configuration change, recovery design, and operational validation across the network layer. If the organisation cannot explain who controls the last known good state, then no one truly owns resilience. Governance has to cover configuration provenance, rollback authority, and recovery testing.
👉 Read our full editorial: Network control plane recovery is the new resilience problem
