A cloud action that captures a point in time copy of a disk, volume, or virtual machine state. In adversary hands, snapshots can bypass access restrictions, preserve compromised data, and support offline analysis or exfiltration. Because snapshot creation is often legitimate, it can be difficult to distinguish abuse from routine operations.
Expanded Definition
Create snapshot is a cloud control action that preserves the state of a disk, volume, or virtual machine at a specific moment, usually so the state can be restored, cloned, or analysed later. In normal operations, snapshots are a standard administration feature; in security incidents, the same action can become a data access and persistence tactic when an attacker uses legitimate cloud permissions to copy live content out of band. The security meaning of the term therefore depends less on the mechanics of capture and more on who initiated it, what was included, and whether the resulting copy was governed by policy.
In practice, the term sits at the boundary between cloud operations, backup, and incident response. A snapshot is not the same as a backup strategy, because it may inherit the source system’s permissions, encryption context, and exposure profile. It is also distinct from imaging for forensic purposes, which usually demands stronger chain-of-custody handling. For governance and control mapping, the NIST Cybersecurity Framework 2.0 is useful for anchoring asset protection, logging, and response expectations around the action. The most common misapplication is treating snapshot creation as harmless routine activity, which occurs when teams do not distinguish approved administration from privileged abuse.
Examples and Use Cases
Implementing snapshot controls rigorously often introduces operational friction, because faster recovery and easier troubleshooting must be weighed against exposure from copied data and misused privileges.
- A cloud operator creates a snapshot before patching a production volume so the system can be restored if the update fails.
- An incident responder captures a snapshot of a compromised virtual machine to preserve volatile disk state for later analysis.
- An attacker with excessive permissions creates snapshots of attached storage to collect secrets, configuration files, or customer records offline.
- A DevOps team uses snapshots for test cloning, but the cloned environment inherits sensitive data because masking was not applied before replication.
- A platform team restricts snapshot creation to approved identities and routes all actions into audit logs for review against expected change windows.
Snapshot activity is often discussed alongside backup and restore processes, but the security difference matters because snapshots can be created instantly and quietly from the management plane. Cloud providers and identity teams often need to evaluate the action together with role assignment, approval workflows, and storage access controls. Where organisations formalise review, snapshot creation becomes a controlled administrative event rather than an open-ended copy mechanism.
Why It Matters for Security Teams
Create snapshot matters because it can bypass the assumptions defenders make about data movement. A snapshot may appear as a legitimate maintenance task while actually preserving evidence, sensitive records, or credentials for later extraction. That makes detection dependent on context: the identity used, the timing, the target asset, and whether the snapshot was immediately attached to another system or exported. Security teams need to treat snapshot permissions as high-impact cloud privileges and align them with least privilege, logging, and approval controls.
This is especially relevant in identity and NHI governance, where service principals, automation accounts, and delegated cloud roles may be allowed to manage volumes without strong human oversight. If those identities are over-permissioned or poorly monitored, snapshot creation becomes a straightforward path to data access rather than a simple recovery tool. Organisations typically encounter the full risk only after data has been copied, at which point snapshot governance becomes operationally unavoidable to address.
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 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Snapshot creation depends on tightly governing privileged access to cloud resources. |
Limit snapshot privileges to approved roles and review entitlements for least privilege.
Related resources from NHI Mgmt Group
- What is secrets sprawl and why does it create security risk?
- What is the core decision loop Agentic AI follows and why does it create security risk?
- How do third-party SaaS integrations create NHI risk and how should they be managed?
- Why do non-human identities create more risk than many human accounts?
