Backups protect information, but they do not restore the path between users and the application. If DNS, routing, CDN, or firewall state is wrong, the service can remain invisible or unreachable while the database is fully intact. That is why reachability must be treated as part of resilience, not a separate operations problem.
Why healthy backups do not eliminate outage risk
Backups restore data, but availability depends on more than data alone. If the configuration that makes the service reachable is lost, the application can stay down even though the underlying database is intact. The practical issue is not just recovery of records, it is recovery of the service path, including how users reach it and how traffic is admitted.
A healthy backup can therefore give a false sense of resilience if the restore plan assumes the network and control-plane state will still be correct. In real incidents, the failure is often not “data gone,” but “service cannot be reached, resolved, or trusted enough to serve traffic.”
That distinction matters because reachability failures often sit in DNS, routing, load balancer rules, CDN settings, certificates, or firewall policy. Those components are part of the operational state of the system, and losing them can break production even when the application payload is fully recoverable.
What configuration loss actually breaks during recovery
Configuration loss removes the instructions that tell infrastructure how to behave. A database backup can restore rows and tables, but it does not recreate a valid DNS record, a working edge rule, a route table entry, or a security policy that allows traffic to pass. That is why recovery planning has to treat infrastructure configuration as a first-class dependency.
When the wrong setting is restored, the service may also fail in more subtle ways. Users might resolve the name but reach the wrong endpoint, traffic might be sent to an unhealthy target group, or a firewall may block the restored system because its source ranges no longer match the live environment.
This is also why configuration drift creates hidden fragility. The backup may be current, but the live environment may have changed after the backup was taken. If those changes are not captured, the restored service can appear technically “up” while still being functionally unavailable to the intended users.
Why resilience must include reachability, not just data durability
Resilience is the ability to restore a usable service, not simply to recover files or databases. That means teams need to define which control-plane elements are required for the application to be seen, routed to, and accepted by the environment. In many systems, those elements are as critical as the data itself.
Common resilience gaps appear when teams separate backup ownership from infrastructure ownership. Data teams may prove that restoration works, while platform or network teams assume configuration can be rebuilt manually. The result is a recovery path that is theoretically complete but operationally brittle.
NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because the problem spans configuration management, access control, and recovery discipline, not only data backup. CISA Secure by Design also reinforces the idea that secure defaults and correct system state are part of operational reliability, not an afterthought.
Risk and Threat Considerations
Configuration loss creates outage risk because it removes the state that governs routing, trust, and access paths. Even without any data loss, the service can become unreachable, misdirected, or blocked, which turns a recoverable event into a customer-visible outage.
Failure mechanism: The restore succeeds at the storage layer, but the surrounding control-plane state, such as DNS, routing, firewall policy, load balancer configuration, or CDN behavior, is missing, stale, or inconsistent.
Impact: Users cannot reach the application, traffic is sent to the wrong place, or the restored system is denied the very traffic it needs, extending downtime despite healthy backups.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Configuration loss and drift directly affect recovery and service availability. |
| CM-3 — Configuration Change Control | Untracked changes can break reachability even when backups are current. | |
| CP-10 — System Recovery and Reconstitution | Recovery must reconstitute the service path, not only the data. | |
| Recommendation — Maintain and restore approved configuration baselines for all recovery-critical components. Control and record changes to DNS, routing, firewall, and load-balancer settings. Test full reconstitution of application, network, and access dependencies during recovery exercises. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | Recovery practices must verify that restored systems are actually usable. |
| Recommendation — Include configuration and service-path validation in recovery testing, not just backup restore checks. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Execution | The recovery plan must restore operational service, including reachability dependencies. |
| Recommendation — Exercise the plan against real reachability dependencies and confirm the service can be served to users. | ||
Practitioner Guidance
What to verify: Validate that the restore process includes every component required for reachability, not just the data store. DNS records, network routes, firewall rules, edge settings, certificates, and dependency endpoints should be recoverable as part of the same service definition.
What good looks like: A recovery test brings back a usable application in the target environment without manual reconstruction of hidden settings. The test should demonstrate that the service is reachable by the intended users and that access controls still align with the restored topology.
Practitioner takeaway: Treat configuration as part of the service, because an intact database is not a live service if the path to it has been lost.
Related resources from NHI Mgmt Group
- Why does configuration drift create compliance risk even when controls look healthy?
- Why does a broken PagerDuty configuration create operational risk even when the underlying systems are healthy?
- Why do AI tools create data-loss risk even when users never download files?
- Why does mobile access create extra data loss risk even when identities are authenticated?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org