They capture configuration intent and version history, not a point-in-time snapshot of what was running. If a change happened through the console, manually, or outside the IaC pipeline, those artifacts may miss the very difference that caused the outage. Recovery needs live-state evidence, not just source control and state metadata.
Why source control can tell you what changed, but not what was actually broken
Code and Git history are excellent for tracing intent, review, and deployment lineage, but they are not a live inventory of runtime reality. In cloud incidents, the failure is often the gap between what should exist and what is actually running: a console tweak, a hotfix, or a one-off permission change can create the outage without appearing in the repo history.
That is why recovery cannot start from source control alone. If you rebuild from the last known code commit and state file without validating the live environment, you may faithfully restore the wrong configuration, reintroduce the defect, or miss the out-of-band change that caused the blast radius in the first place.
This distinction matters most when infrastructure is managed through multiple paths at once, including IaC, portal actions, scripts, and emergency console work. The more ways operators can mutate cloud resources, the less trustworthy code history becomes as a sole recovery record.
Why state files help, but still do not equal recovery evidence
State files are useful because they record resource relationships, identifiers, and some current values at the moment they were last written. They are often the best bridge between intent and implementation, which is why they belong in troubleshooting and drift analysis. But they still represent a managed view of the environment, not a complete operational snapshot of every control plane change or runtime condition.
That means state can be stale, partial, locked behind the wrong backend, or simply unaware of manual edits made after the last plan or apply. When an outage is caused by drift, the recovery question is not only “what did our automation think existed?” but “what was the actual cloud state when service failed?”
In practice, teams recover faster when they treat state as one evidence source among several: deployment logs, cloud audit events, console activity, resource metadata, and service health data. The point is to reconstruct the active configuration before deciding what to restore.
Why live-state evidence is the missing piece in cloud recovery
Cloud recovery needs evidence from the running environment because the outage condition often lives in runtime configuration, permissions, or dependency state rather than in source artifacts. A point-in-time snapshot of live resources can reveal the difference that mattered: an altered security group, a replaced secret reference, a disabled policy, a changed route, or a resource created outside the pipeline.
That is also why recovery procedures should separate diagnosis from redeployment. If you redeploy first and investigate later, you can overwrite the evidence needed to understand the fault and make the same mistake again. The practical order is: capture live state, compare it against intended state, then restore only after the drift is understood.
For teams that manage cloud infrastructure through GitOps or IaC, this becomes a control problem as much as a technical one. Recovery succeeds when the process can answer three questions quickly: what changed, where was it changed, and which source of truth is authoritative for restoration.
Risk and Threat Considerations
The main risk is silent drift: changes made outside the IaC pipeline can bypass review, leave no obvious trace in source control, and survive long enough to cause an outage or expose data. If recovery assumes the repo is complete truth, teams may restore the wrong baseline or miss the real fault path.
Failure mechanism: Out-of-band console changes, stale state, or incomplete reconciliation hide the actual runtime difference, so the restore action reproduces the broken or insecure condition instead of eliminating it.
Impact: Recovery time increases, post-incident analysis becomes unreliable, and the same misconfiguration can recur after rollback or redeployment.
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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Execution | Cloud recovery depends on restoring from verified live state and not just version history. |
| DE.CM-01 — Anomalies and Events | Out-of-band changes and unexpected runtime differences must be detected before recovery. | |
| Recommendation — Validate runtime drift before executing restoration actions. Monitor cloud control-plane and configuration changes for unexpected drift. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | The issue is a mismatch between intended configuration and actual runtime settings. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Audit evidence is needed to reconstruct who changed the live environment and when. | |
| Recommendation — Baseline configuration and compare deployed settings against it. Review audit records to identify the change that caused drift. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Recovery must account for controlled configuration and deviations from the intended state. |
| Recommendation — Track and reconcile configuration changes across deployed cloud assets. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Cloud recovery fails when the deployed configuration diverges from the expected baseline. |
| Recommendation — Compare deployed cloud settings to hardened baselines before restoring service. | ||
Practitioner Guidance
What to verify: Before trusting a restore point, verify that live cloud resources, audit logs, and IaC state agree on the specific object that failed, not just on the intended configuration. If they do not align, treat the drift as the primary incident clue, not a secondary detail.
Decision rule: If the outage could have been caused by manual console work, emergency access, or cross-tool changes, prioritise live-state capture and drift comparison before any rollback. Source control can guide restoration, but it should not be the only evidence you use to rebuild the environment.
Practitioner takeaway: Recovery is about reconstructing runtime truth, not replaying repository history; the safer restore is the one that explains the live-state deviation before it replaces it.