TL;DR: Cyber resilience is the ability to keep critical business operations running and recover after prevention fails, but ControlMonkey argues that most organisations still cannot restore the configuration layer that makes cloud, identity, SaaS, and networking work together. The practical risk is that data may come back while the business stays down because the last known-good operating state is missing.
At a glance
What this is: ControlMonkey argues that cyber resilience breaks down when teams can restore data but cannot recover the configuration layer that lets the business operate.
Why it matters: For IAM and security teams, this means identity, access, cloud, and SaaS configuration must be recoverable as part of business continuity, not treated as separate technical chores.
Context
Cyber resilience is not just about surviving an attack. It is about restoring the business service that depends on cloud infrastructure, identity, networking, SaaS, security controls, and observability, and many organisations still lack a way to bring those layers back together cleanly.
The core governance gap is recoverability of the operating state. Data backup may be mature, but if identity policies, firewall rules, DNS, certificates, or third-party integrations are missing or inconsistent, the business can remain offline even after the incident is contained.
Key questions
Q: What breaks when cyber resilience planning ignores configuration recovery?
A: Recovery can appear successful on paper while the business remains unavailable. Data may be restored, but authentication, routing, certificates, secrets, or SaaS integrations may still be wrong, which blocks users and services. The failure is not the backup itself, but the assumption that data restoration automatically restores the operating environment.
Q: Why does configuration drift make recovery slower and riskier?
A: Because the team no longer has one reliable version of the environment to restore. Drift creates a gap between what engineers think exists and what actually runs in production, so recovery turns into reconstruction. That increases outage time, introduces human error, and makes the last known-good state harder to prove.
Q: How should organisations prioritise configuration recovery against data backup?
A: They should treat them as complementary, but not equivalent. Data backup protects information, while configuration recovery protects the operating model that makes that information usable. If the business depends on cloud, identity, or SaaS controls to function, those settings need the same restoration discipline as the database itself.
Q: How can teams tell whether their cyber resilience plan is actually complete?
A: Test whether a critical service can return to operation after a realistic disruption. If the team can restore data but cannot authenticate users, route traffic, re-enable integrations, or validate monitoring, the plan is incomplete. Completion means the business capability comes back within the recovery assumptions, not just that one system is online.
Technical breakdown
Why data recovery does not equal service recovery
Modern recovery environments are layered. A restored database is only one dependency in a wider stack that includes identity, access policy, networking, certificates, SaaS settings, and monitoring. Cyber resilience fails when teams treat those layers as separate projects instead of one operating state. The technical problem is not only restoration, but sequencing and dependency integrity: what must exist, in what order, and at what version, for the service to function again.
Practical implication: Map service dependencies before an incident so recovery plans cover the full operating stack, not just the data store.
The recoverability gap in configuration-heavy environments
Infrastructure as Code improves repeatability, but it does not guarantee that every live configuration state is represented, versioned, or restorable. Console changes, SaaS settings, API-driven updates, and automation can all create drift between declared state and actual state. Once that drift exists, the team may know how to rebuild parts of the environment but not how to recover the exact working configuration that supported production yesterday.
Practical implication: Treat configuration drift as a resilience risk and test whether live state can be reconstructed from known-good versions.
Why the last known-good state matters
Recovery is fundamentally a versioning problem. Teams need a trusted way to identify what changed, compare current state to earlier state, and restore the version that was functioning before disruption. Without that history, engineers end up manually reconstructing the environment under pressure, which extends outage time and increases the chance of introducing new errors. In cloud and SaaS estates, the absence of configuration history is often the difference between recovery and guesswork.
Practical implication: Maintain versioned snapshots and change history for critical configuration so restoration can target a verified known-good state.
Threat narrative
Attacker objective: The objective is to create or extend operational disruption by forcing the organisation into a recovery process that cannot fully restore service.
- Entry occurs through a routine disruption or successful cyber incident that knocks critical systems out of their normal operating state.
- Escalation follows when recovery teams can restore data but cannot reconstruct the identity, network, SaaS, and cloud configuration that the service depends on.
- Impact is prolonged business outage, because the technical incident is resolved while the business remains unable to operate.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Configuration recoverability is now a resilience control, not an administrative convenience. Cyber resilience programmes have often focused on prevention, detection, and backup, but this article shows that the business still fails if the operating configuration cannot be restored. That shifts configuration history, versioning, and known-good state recovery into the same governance tier as data restore. Practitioners should treat recoverability of the live environment as a board-relevant continuity control.
The recoverability gap is the modern blind spot in cloud resilience. Cloud, SaaS, identity, and security tooling each introduce their own configuration surface, and those surfaces drift faster than most organisations can reconstruct them during a crisis. The specific failure mode is not lack of tooling, but fragmentation of the operating state across systems that are assumed to come back together automatically. Practitioners should measure whether their critical services can be reassembled, not just whether their components are backed up.
Identity and access settings are part of the business recovery path. When production access policies, authentication rules, or third-party integrations are missing, the data may be intact while users and operators remain locked out. That makes identity governance part of resilience planning, especially where cloud and SaaS platforms define who can access what during recovery. Practitioners should include identity configuration in every recovery scenario, because authentication failure can turn a recovered system into an unusable one.
Minimum Viable Business is the right recovery lens for configuration governance. Teams should stop thinking only in terms of applications and start with the business capability that must come back first. Once that is defined, the relevant configuration dependencies become visible, including routing, security policy, observability, and SaaS connections. Practitioners should use this model to decide which configurations need continuous discovery and versioned recovery first.
What this signals
Configuration recovery is becoming a first-class resilience requirement. As cloud and SaaS environments change faster, the ability to restore the last known-good state is what separates a recoverable incident from a prolonged outage. Practitioners should fold configuration history, change tracking, and environment reconstruction into the same recovery governance they already apply to data.
Identity, network, and SaaS settings now sit inside the business recovery path. If those layers cannot be recovered alongside the application, the organisation may technically finish incident response while still being unable to operate. That makes recovery design a cross-domain governance issue, not a narrow infrastructure task.
Recoverability must be tested at the service level. A restore test that proves only the database came back is no longer enough. Teams need exercises that validate the service can authenticate, route, monitor, and integrate again before they can call the environment resilient.
For practitioners
- Define the Minimum Viable Business Identify the customer journeys, revenue flows, and regulatory functions that must recover first, then map the technical dependencies required to run them.
- Inventory the full recovery dependency chain Document which identity policies, DNS records, firewall rules, certificates, SaaS settings, and monitoring controls must return before a service is considered operational.
- Test configuration restoration, not only backup restore Run exercises that prove the live operating state can be rebuilt from versioned configuration, including cloud, identity, and third-party settings.
- Track configuration drift as a resilience metric Compare declared state to live state and flag drift that would prevent you from recovering the last known-good version during an incident.
Key takeaways
- Cyber resilience fails when organisations confuse backup success with recovery success and leave the operating configuration unrecoverable.
- The missing layer is the last known-good state across identity, networking, cloud, SaaS, and observability, not only the data set.
- Teams should test whether critical services can come back as services, because restored components do not automatically restore the business.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Implementation | The article centres on restoring business operations after disruption. |
| RC.IM-01 — Recovery Plan Execution Improvements | The article argues recovery plans fail when configuration cannot be restored reliably. | |
| Recommendation — Define and test recovery plans against the service dependencies that must return before operations resume. Use post-incident lessons to improve configuration restore procedures and update recovery assumptions. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | The piece focuses on restoring systems and configurations after disruption. |
| Recommendation — Extend data recovery testing to include the configuration needed to make recovered systems usable. | ||
| NIST SP 800-53 Rev 5 | CP-9 — System Backup | Backup is necessary, but the article shows backup alone does not restore operating state. |
| CP-10 — System Recovery and Reconstitution | The core issue is reconstituting cloud and SaaS operating state after an incident. | |
| Recommendation — Pair backup controls with restore testing that proves the live service can operate again. Validate that recovery procedures can reconstitute the full configuration required for service delivery. | ||
Key terms
- Cyber Resilience: Cyber resilience is the ability to continue operating, recover, and make safe decisions during and after a cyber incident. It goes beyond backup availability by combining visibility, prioritisation, and restoration discipline so the organisation can restore what matters without amplifying harm.
- 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.
- Last Known-Good State: The last known-good state is the most recent configuration, policy, or system state that was verified as working correctly. It is the reference point used during rollback and recovery. In AI operations, it helps teams restore service after an agent changes access, routing, security, or observability settings incorrectly.
- 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 Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps security and identity practitioners connect governance decisions to the access and lifecycle controls that shape resilience.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org