The DR iceberg: why configuration recovery now drives resilience

At a glance

What this is: ControlMonkey frames disaster recovery as a configuration problem as much as a data problem, because the hidden cloud, SaaS, identity and network settings often determine whether recovery actually works.

Why it matters: For IAM, NHI and broader security teams, this matters because recovery plans that ignore configuration drift can leave identities, access paths and service dependencies unrecoverable even when data is intact.

Context

Disaster recovery fails when teams treat backups as equivalent to recoverability. In modern environments, the working state depends on cloud configuration, identity policy, network routing, SaaS settings and dependencies that can drift independently of the data.

This creates a governance gap for identity and access teams because restore success depends on whether IAM policies, service dependencies and access paths can be returned to a known-good state, not just whether data is available.

The article’s core claim is typical of cloud-native recovery reality: organisations usually know how to restore data, but far less often know how to reconstruct the configuration that makes that data usable.

Key questions

Q: What breaks when disaster recovery only covers backups and failover?

A: Recovery breaks when the environment needed to use the data is missing or inconsistent. Backups may restore files or databases, but applications still need identity policies, DNS, routing, security rules, certificates, and dependencies to function. Without those control-plane elements, organisations get data back but cannot return to service safely or predictably.

Q: Why do cloud configuration gaps make recovery slower and riskier?

A: Because incident teams must first reconstruct what changed before they can safely restore service. When configuration is incomplete, drifted or unmanaged, recovery becomes an investigation exercise rather than a controlled rollback. That increases downtime, raises the chance of restoring the wrong state and leaves identity and access dependencies outside the recovery boundary.

Q: How can organisations tell whether their DR plan is actually usable?

A: A usable DR plan can restore the minimum viable business, not just the workload. If the plan cannot bring back access paths, network settings, identity policy and SaaS dependencies in a trusted order, it is not operationally complete. The test is whether the business can function after restoration, not whether a backup exists.

Q: How should teams govern identity and access settings for disaster recovery?

A: They should treat IAM policies, service access and dependency settings as versioned recovery assets with known-good states and clear restore ownership. In practice, that means the same governance applied to data backup must also apply to access configuration, because a recovered environment that cannot authenticate or authorise correctly is still broken.

Technical breakdown

Why backup does not equal operational recovery

Backup protects copies of data, but operational recovery depends on the surrounding control plane. In cloud and SaaS environments, identity policy, DNS, routing, security groups, load balancers, certificates and service dependencies determine whether restored data can actually be reached and used. If those settings have drifted, been deleted or were never captured, the environment can look recovered on paper while remaining unusable in practice. This is why disaster recovery has moved beyond storage and snapshots into configuration state management.

Practical implication: treat configuration state as a recoverable asset alongside backups and failover.

How configuration drift breaks restore confidence

Configuration drift is the gap between the intended state and the actual state of cloud or SaaS controls. It appears when teams make manual console changes, automation misses resources, or emergency fixes bypass the system of record. During an incident, that drift forces teams to investigate what changed before they can restore anything safely. The result is slower recovery, more guesswork and higher risk of restoring the wrong state. For identity-heavy environments, even small policy changes can block service access or overexpose resources after failover.

Practical implication: version and continuously monitor cloud, SaaS and identity configuration so restore points reflect reality.

Minimum viable business depends on the right control plane

Minimum viable business is the smallest service set an organisation needs to keep operating during recovery. That concept only works if the critical control plane is also recoverable. Identity, routing, access policy, SaaS configuration and security dependencies often sit beneath the visible recovery plan, yet they decide whether the business can resume operations. A working backup without the right permissions, network paths or SaaS settings is not enough. The recovery objective has to include the environment that makes the business function, not only the workload that stores its data.

Practical implication: define recovery objectives for control-plane dependencies, not just for applications and data.

NHI Mgmt Group analysis

Configuration recovery has become a resilience control, not an implementation detail. Traditional DR thinking assumes the hard part is preserving data and recreating compute. That assumption no longer holds in cloud and SaaS estates where identity policy, routing, security groups and service settings determine whether the business can resume. The practitioners who still treat those settings as secondary metadata are underestimating the real recovery boundary. The practical conclusion is that recovery readiness now starts with configuration governance, not with backup retention.

The hidden risk is not data loss but operating-state loss. Organisations can often recover files, snapshots and replicas while still failing to restore access, connectivity or trust relationships. That creates a false sense of recovery because the environment exists but cannot function. In identity terms, the issue is especially sharp when IAM policies, service permissions or delegated access paths drift out of sync with the restored estate. Practitioners should treat operating-state restoration as the real control objective.

Cloud and SaaS recovery now exposes an identity governance problem. If policy, access and dependency state are not versioned, restored environments can inherit stale entitlements, broken authorisation paths or blocked service accounts. That makes configuration recovery inseparable from IAM and NHI governance. The named failure mode here is recovery without trusted state, which leaves access controls and service dependencies outside the restore boundary. Teams should govern the recoverability of identity and access configuration as rigorously as the data itself.

Recovery maturity will increasingly be judged by reconstructability, not just backup coverage. Boards and auditors can already ask whether data is protected. The more useful question now is whether the organisation can reconstruct the full operating environment after a disruption. That requires version history, known-good states and proof that cloud, SaaS and identity dependencies are included in recovery design. The practitioner takeaway is simple: a DR plan that cannot restore the environment is only a partial plan.

The DR iceberg reframes resilience as a control-plane issue. Once organisations accept that recovery depends on the hidden layer beneath the visible backup stack, the governance conversation changes. The challenge is no longer whether a snapshot exists. It is whether the access model, routing model and service dependencies can be restored together without improvisation. The practical conclusion is that control-plane recoverability should be a standing resilience requirement, not a post-incident lesson.

What this signals

Configuration recovery will become a standard resilience expectation. As cloud estates, SaaS platforms and identity policies change continuously, recovery planning has to move from static backup checks to reconstructable operating state. The teams that can prove versioned, trusted recovery of configuration will recover faster and with less improvisation.

The identity angle is now unavoidable. If IAM policy, service access and dependency settings are not recoverable, disaster recovery can succeed technically while failing operationally. That means identity governance, not just infrastructure resilience, is now part of the recovery conversation.

Control-plane visibility is the new recovery baseline. Practitioners need to know what changed, what is authoritative and what can be restored with confidence before an incident forces manual reconstruction. The organisations that lack that visibility will keep discovering their real recovery gaps under pressure.

For practitioners

• Define recovery for configuration, not just data Map cloud, SaaS, identity and network settings into the formal DR scope so recovery requirements include the operating environment, not only backups and snapshots.
• Version critical configuration states Maintain trusted history for IAM policies, DNS, security groups, load balancers, SaaS settings and other dependencies so teams can return to a known-good state during restoration.
• Test the minimum viable business path Validate that the smallest operating service set can be restored with the access, routing and dependency controls it actually needs to function.
• Track configuration drift continuously Detect console changes, manual overrides and incomplete IaC coverage before an incident turns unknown state into manual reconstruction.
• Include third-party SaaS dependencies in DR plans Document which external platforms, service accounts and access settings must be restored or revalidated before recovery can be considered complete.

Key takeaways

• Traditional disaster recovery can protect data and still fail to restore a usable environment if configuration is missing or stale.
• The critical recovery problem is often the control plane, including IAM policy, DNS, routing and SaaS settings.
• Resilience teams should measure whether they can reconstruct the minimum viable business, not just whether they can restore a backup.

Key terms

• Configuration Recovery: Configuration recovery is the ability to restore the cloud settings, access controls, and service dependencies needed to make applications run again. It goes beyond data backup by preserving the operating state of infrastructure, identity, network, and security components so teams can return to a known-good environment after an outage or change.
• Operating State: The live combination of data, access controls, network paths, service dependencies and platform settings that lets a system function. In modern environments, operating state is often what recovery actually depends on, because restored data is useless if the surrounding controls cannot support it.
• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
• Minimum Viable Company: Minimum Viable Company is the smallest level of identity and application capacity needed for the business to operate after a recovery event. It shifts the recovery question from whether a system is online to whether enough trusted access exists for critical services to function.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management in the context of modern access control. It helps security and identity practitioners connect governance decisions to the resilience outcomes their programmes are expected to deliver.