DC0049: Snapshot Deletion
The removal of a point-in-time backup of a cloud storage volume, virtual machine (VM), or database.
*Data Collection Measures:*
- AWS CloudTrail - Logs `DeleteSnapshot` API calls in EC2, RDS, and EBS services. - Azure Monitor Logs - Tracks snapshot deletions via `Microsoft.Compute/snapshots/delete` API calls. - Google Cloud Logging - Detects snapshot removal through `compute.disks.deleteSnapshot` events.
Analyst context for executives and security teams
Snapshot deletion matters because snapshots are often the fastest path to restoring cloud volumes, virtual machines, and databases after an outage, mistake, or security incident. Even without a mapped ATT&CK tactic or technique context, this data component is business-relevant: if an organization cannot see when point-in-time backups are removed, leaders may overestimate recovery readiness and incident responders may discover too late that recovery options have been reduced.
Executive priority
Treat snapshot deletion visibility as a resilience and audit-control question: can the organization prove who or what removed snapshots, when it happened, and whether the deletion was authorized? This should inform backup governance, cloud security monitoring, incident response readiness, and compliance evidence around recoverability. Priority is highest where snapshots protect critical databases, production VMs, regulated data, or systems with strict recovery time objectives.
Technical view
SOC, cloud security, and IR teams should validate that cloud control-plane logs capture snapshot deletion activity for relevant services. The supplied ATT&CK data collection measures identify AWS CloudTrail events for DeleteSnapshot API calls in EC2, RDS, and EBS; Azure Monitor Logs for Microsoft.Compute/snapshots/delete API calls; and Google Cloud Logging for compute.disks.deleteSnapshot events. Because ATT&CK provides no official detection analytic or relationship context here, teams should build environment-specific logic around authorized change windows, expected automation identities, snapshot retention workflows, and high-value assets.
Likely telemetry
- AWS CloudTrail records for DeleteSnapshot API calls in EC2, RDS, and EBS services
- Azure Monitor Logs containing Microsoft.Compute/snapshots/delete API calls
- Google Cloud Logging events for compute.disks.deleteSnapshot
- Cloud identity context associated with the deletion request, where available in the relevant provider logs
- Asset context linking deleted snapshots to cloud storage volumes, virtual machines, or databases
Detection direction
- Confirm that the relevant cloud control-plane logging is enabled, retained, and searchable for snapshot deletion events.
- Alert or review deletion of snapshots tied to production, critical databases, regulated workloads, or recovery-sensitive systems.
- Tune detections against approved lifecycle policies, backup rotation jobs, and infrastructure-as-code automation to reduce false positives.
- Pay special attention to deletions by unusual identities, new automation roles, unexpected source locations, or activity outside approved maintenance windows when those fields are available locally.
- Validate whether SOC workflows can connect a snapshot deletion event to the protected asset and responsible identity; without that context, alerts may not support fast incident decisions.
Mitigation priorities
- Establish clear ownership and retention requirements for snapshots supporting critical cloud volumes, VMs, and databases.
- Restrict snapshot deletion permissions to approved roles, service accounts, or controlled automation paths.
- Require logging and retention for the cloud services named in the data collection measures before relying on snapshot monitoring as a control.
- Use change management or approval workflows for deletion of recovery-critical snapshots where business impact warrants it.
- Periodically test recovery assumptions so backup governance is validated by evidence, not only by policy.
Analyst notes and limits
This object is a data component, not a technique. Its value is in confirming whether defenders collect the evidence needed to detect or investigate removal of cloud point-in-time backups. The most useful local enrichment will be identity, asset criticality, backup policy, and change-management context.
ATT&CK supplies no tactics, platforms, relationships, or official detection logic for this object. The summary is therefore limited to the official description, external reference, and listed data collection measures for AWS, Azure, and Google Cloud logging. Local architecture and logging configuration are required to determine actual coverage or risk.
Snapshot Deletion
The removal of a point-in-time backup of a cloud storage volume, virtual machine (VM), or database.
*Data Collection Measures:*
- AWS CloudTrail - Logs `DeleteSnapshot` API calls in EC2, RDS, and EBS services. - Azure Monitor Logs - Tracks snapshot deletions via `Microsoft.Compute/snapshots/delete` API calls. - Google Cloud Logging - Detects snapshot removal through `compute.disks.deleteSnapshot` events.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 5410f64fd6fc… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0049Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.