Data Destruction When You Do Not Own the Hardware
Cloud computing has shifted vast amounts of data from on-premises infrastructure to shared platforms managed by third-party providers. When organisations need to decommission cloud resources, whether because of a migration, a change of provider, or the end of a project, they face a fundamentally different data destruction challenge. You cannot physically destroy a drive in someone else’s data centre, and you have limited visibility into how the underlying hardware manages your data.
Understanding how cloud data destruction works, and where the gaps may lie, is essential for organisations that need to meet compliance obligations for data disposed of in cloud environments.
The Shared Responsibility Model
Cloud providers operate under a shared responsibility model. The provider is responsible for the security and management of the underlying infrastructure, including the physical hardware, networking, and facilities. The customer is responsible for managing their data within the cloud environment, including deciding when and how to delete it.
For data destruction, this means the provider handles the physical disposal of hardware at end of life (including drive sanitisation and destruction), while the customer is responsible for deleting their data from cloud storage, decommissioning virtual machines and databases, and verifying that data has been removed from all cloud services and regions.
The gap between these responsibilities is where data destruction risks often emerge.
How Major Cloud Providers Handle Hardware Disposal
The major cloud providers (AWS, Microsoft Azure, and Google Cloud Platform) all publish documentation describing their media sanitisation and disposal practices. Generally, these providers use a combination of cryptographic erasure and physical destruction for end-of-life storage hardware.
AWS states that storage devices are decommissioned using techniques detailed in NIST 800-88, and devices that cannot be sanitised are degaussed and physically destroyed. Microsoft Azure describes using NIST 800-88 compliant sanitisation processes and physically destroying drives that cannot be sanitised. Google Cloud describes encrypting all data at rest and destroying the encryption keys as part of the data deletion process, in addition to physical destruction of decommissioned hardware.
These practices are generally robust, but the customer has no ability to independently verify them. Trust in the provider’s processes is based on their published documentation, third-party audit reports (such as SOC 2 Type II), and certifications (such as ISO 27001).
Customer-Side Data Deletion
When decommissioning cloud resources, the customer must actively delete their data. Simply stopping payment or letting a subscription lapse does not immediately destroy data. Most providers retain data for a grace period after account closure, and some services retain data in backups or archives for extended periods.
A thorough cloud decommissioning process should address compute resources (virtual machines, containers, serverless functions), storage services (object storage, block storage, file shares), database services (managed databases, data warehouses, caches), networking resources (VPNs, load balancers, DNS records), identity and access management (service accounts, API keys, certificates), logging and monitoring (CloudWatch, Azure Monitor, Stackdriver logs), and backup and disaster recovery (snapshots, backup vaults, replication targets).
Each of these services may retain data that needs to be explicitly deleted.
Data Remanence in Cloud Environments
Cloud storage systems are designed for durability and availability, which means data is typically replicated across multiple physical locations. When you delete an object from cloud storage, the deletion propagates across all replicas, but the timing of physical overwriting on the underlying storage hardware is managed by the provider and is not under the customer’s control.
Cloud providers generally guarantee that deleted data is not accessible through the cloud APIs after deletion, but they do not guarantee immediate physical overwriting of the underlying storage sectors. The use of encryption at rest provides additional protection: even if data remnants persist on physical media after deletion, they are encrypted and the encryption keys are managed (and eventually destroyed) by the provider.
For most compliance frameworks, including the Privacy Act 1988 and GDPR, the combination of logical deletion (removing API accessibility) and encryption at rest is generally considered adequate. However, organisations with very high sensitivity requirements should review their specific compliance obligations and the provider’s published practices.
Multi-Region and Cross-Account Considerations
Data in cloud environments can be distributed across multiple geographic regions and multiple accounts. Cross-region replication, global load balancing, and content delivery networks (CDNs) can result in copies of data existing in regions that the organisation may not be fully aware of.
Before decommissioning, audit all regions and accounts where data may reside. Cloud provider tools like AWS Config, Azure Resource Graph, or Google Cloud Asset Inventory can help identify resources across regions. CDN caches may need to be explicitly invalidated and purged to remove cached copies of data.
Third-Party SaaS Applications
Many organisations use Software-as-a-Service (SaaS) applications that store data in the provider’s cloud infrastructure. When decommissioning a SaaS application, the customer typically has limited control over data destruction. The process depends on the provider’s data deletion policies, which should be reviewed before signing up and again before decommissioning.
Key questions to ask SaaS providers include how long data is retained after account closure, whether data is deleted from backups as well as primary storage, whether the provider can provide a certificate of data destruction, and what standards the provider follows for media sanitisation at the infrastructure level.
Contractual and Compliance Considerations
Cloud service agreements should include provisions for data destruction at the end of the relationship. Review your agreements with cloud providers to understand what commitments they make regarding data deletion timelines, whether they provide written confirmation of data destruction, their obligations regarding backup and archive copies, and your rights to audit or verify data destruction.
For organisations subject to Australian privacy legislation, it is important to note that the APPs require organisations to take “reasonable steps” to destroy personal information that is no longer needed. Using a major cloud provider with documented NIST 800-88 compliant destruction practices and appropriate certifications generally satisfies the “reasonable steps” test, but organisations should document their assessment of the provider’s practices as evidence of due diligence.
Cloud decommissioning requires a different mindset than on-premises disposal, but the underlying principle is the same: ensure that all copies of your data are identified and eliminated, and document the process to demonstrate compliance.