Your disaster recovery plan assumes the environment is gone. A tenant-level breach assumes the environment is available and lying to you. When a cloud provider loses a region, you failover. When an attacker takes the management plane of your tenant, you cannot trust the failover.
Cloud providers spend billions securing hypervisors and physical data centers. That security model works until an attacker logs into your management plane with a stolen session token. At that point, the provider’s physical security is simply protecting the attacker’s operations from you. The attacker does not need to exploit a zero-day to destroy the environment. They just use the tools built for the administrators.
When an attacker breaches a tenant control plane, the immediate question is who still holds the administrative keys.
Most enterprise landing zones put backups and logging in separate accounts, which feels like isolation. But if the same compromised administrator identity can change permissions in the log account, or if the backup vault shares an identity provider with production, the boundary is an illusion. When backups and logs live in an account reachable by the same credentials that just got compromised, they are a second copy of the problem. An immutable backup encrypted with a deleted key is just permanent ciphertext. If the attacker controls the management plane, they can schedule the KMS keys for deletion.
In commercial IT, a breach means downtime and ransom negotiations. In law enforcement and military IT, it means the evidence chain is broken. If an attacker owns the tenant, they own the timestamps, the access logs, and the storage volumes. Every prosecution relying on digital evidence from that environment is compromised unless the audit trail lives in an entirely separate, isolated cryptographic boundary.
Consider an internal investigations unit trying to pull access logs to trace a suspicious download of surveillance footage from a classified network. The query returns a blank table. The attacker did not delete the logs. Three weeks earlier, they altered the logging role’s IAM policy to silently drop events originating from their specific IP block. In a control plane breach, the logs are not evidence. They are an alibi written by the attacker.
Recovery in this context has two clocks. One measures how quickly a service can return. The other measures how long it takes to establish that the restored data, permissions, and audit trail can be trusted. Bringing an application online does not settle the second question.
The incident response plan usually assumes you have logs to read, backups to restore, and an identity provider that tells the truth. A tenant-level compromise removes all three at once. When the primary identity provider is compromised, incident response fails before it begins. The network engineers cannot log in to sever the connection, and the security team cannot access the console to pull logs.
This exposes the break-glass illusion. During a tabletop exercise, an incident commander calls for the break-glass credentials. The security lead retrieves the physical hardware tokens from a safe and plugs them into a clean terminal, only to realize the administrative endpoint requires routing through a VPN appliance hosted inside the compromised cloud tenant. If your break-glass procedure requires the corporate identity provider or the primary network to function, you do not have one. Break-glass is an organizational artifact before it is a technical one. It requires a hardware token, a separate identity provider, no federation, and a named person who is neither the cloud admin nor the identity admin.
Assuming the team can actually log in, the rebuild begins. You cannot rebuild a compromised environment using orchestration tools hosted inside it. The clean room is not a physical room. It is a separate account with no VPC peering, no shared DNS, no shared CI, and no trust relationship to the one you lost. The infrastructure-as-code must come from a repository outside the compromised organization, pinned to a known-good commit verified by hash.
Even then, the rebuild team faces the reality of the environment they are replacing. They may need to recreate 1,200 IAM policies by hand because the person who wrote them left two years ago and the original repository is in the compromised tenant. Re-accreditation is the hidden tax on this recovery. A functionally identical environment is not an authorized environment. The technical rebuild may take weeks; the paperwork and security assessments may take quarters.
Authority becomes the bottleneck. The incident commander is often not the person who can authorize destroying the old environment or standing up a new one. The person who can authorize the rebuild is frequently not in the incident channel. For operational organizations, the hardest recovery decision may be what to keep using while trust is being re-established. A duty officer can still reach the cloud-hosted incident system, but the team cannot establish whether a recent change to access permissions was authorized. Continuing to use the system and taking it offline both have severe operational consequences. That decision cannot wait for a full forensic report, and the recovery plan must give the people making it more than a backup completion report.
The recovery plan and the evidence retention plan are the same plan. If you rebuild the system carelessly, you may break the chain of custody for every file in it. A detective’s case file restored from a compromised backup will not match the original hash, giving the defense a disclosure argument. A warrant application that references data from a system that was rebuilt without a verified audit trail will fail.
You will not know the full extent of the breach, only the extent of what you can independently prove. A successful restore proves that the data can be read, but it does not prove that the restored environment can be trusted.