What secure deletion means for documents stored in the cloud

Secure deletion means making the target document inaccessible within a defined boundary, then removing or putting beyond use every controlled copy that could reconstruct it. Hiding a row in the interface is not enough.

The boundary may include the original, previews, print files, storage mirrors, links, encryption keys and sensitive metadata. Backups may disappear later under a published rotation. External copies remain outside it.

A trustworthy deletion claim explains all of those limits.

Why "deleted" can mean several things

Software teams use the same word for different operations:

A soft delete marks a record as inactive but leaves the data available to the application.
An interface delete removes an item from the user's view while background objects may remain.
A logical delete removes references to stored data so the normal application can no longer retrieve it.
Cryptographic erasure destroys the keys needed to decrypt properly encrypted data.
Media sanitisation makes recovery from the storage medium infeasible for the required level of effort.

These operations are not interchangeable.

The US National Institute of Standards and Technology defines media sanitisation as making access to target data infeasible for a given level of effort. Its current SP 800-88 Revision 2 covers sanitisation programmes, validation and cryptographic erase, including logical cloud storage where customers cannot touch the physical device.

Map every document component

Deletion design begins with a data map. Follow one upload through acceptance, scanning, preview generation, review, printing, optional download, expiry and backup.

Component	What deletion should do	What may remain
Uploaded original	Remove the active object and its application reference	A protected backup copy until rotation completes
Browser previews	Remove raster pages, thumbnails and cached derivatives under provider control	A screenshot or browser cache outside the defined service boundary
Temporary print output	Remove generated print files after use or at document deletion	A physical printout managed by the customer
Object-storage mirror	Remove the mirrored object and retry failed requests	Provider-level recovery data until its retention window ends
Viewer and upload links	Revoke tokens and reject later requests	A message containing the now-useless link
Encryption material	Destroy document-specific wrapped keys and references where the design uses them	Higher-level keys that cannot decrypt the deleted object by themselves
Sensitive metadata	Remove filenames, sender details and storage paths from active systems	A deliberately minimal, non-sensitive tombstone
Audit events	Retain only what is needed to show access and deletion	Event time, action, actor reference and outcome without document contents
Backups	Expire the copy under a defined schedule and keep it beyond normal use meanwhile	The encrypted backup until it is overwritten or expires
External copies	Record the limit and rely on customer policy	Downloads, screenshots, photos, forwarded attachments and the sender's source file

A provider should be able to describe each row in its security, privacy or retention documentation.

Delete the live workflow as one operation

A document intake service creates several related records. The deletion job should treat them as one unit even when storage systems complete their work at different times.

A practical sequence is:

Stop new viewing, printing and download authorisations.
Revoke active viewer links and any submission-specific access tokens. Review reusable intake links separately so deleting one submission does not disable unrelated collection.
Remove the original and all generated derivatives from active storage.
Remove any mirrored application objects.
Destroy document-specific wrapped keys where encryption design permits it.
Remove sensitive metadata from the database and job queues.
Write a minimal deletion outcome that contains no document content.
Retry any failed step until the full operation completes.

The order should close access early. If a worker stops midway, running it again should safely finish without recreating derivatives or failing because one object is already gone.

Backups need a separate, honest statement

Most production services keep backups so they can recover from hardware failure, corruption or operator error. Instant removal from every backup generation may not be technically available, and promising it can create a misleading deletion claim.

The ICO's right to erasure guidance recognises that live systems may erase data before backup copies are overwritten. It says organisations should be clear about what happens, keep backup data beyond use and replace it under an established schedule. Its storage limitation guidance also warns that moving data offline is not the same as deleting it.

A useful backup deletion statement answers:

How long backup generations normally remain
Whether backup data is encrypted
Who can access the recovery environment
Whether deleted data is excluded from ordinary use
What happens if an old backup is restored
When the backup copy becomes unrecoverable under the schedule

The restore question is easy to miss. Restoring an older database or object snapshot can reintroduce data deleted from the live service. Recovery procedures should replay deletion markers or reconcile restored data against a current deletion ledger before the application returns to service.

Where cryptographic erasure fits

Encryption at rest protects stored data only while the relevant keys remain protected. If every document has distinct key material, deleting its wrapped key can make the encrypted object unreadable even if storage media still contains its ciphertext.

This is often called cryptographic erase. NIST notes that its effectiveness depends on the encryption implementation, key pedigree and required preconditions. A shared key may not provide document-level erasure, and copies encrypted under another key still need deletion.

Ask the provider:

Is key material unique per document, workspace or storage volume?
Which key is destroyed when a document expires?
Can any remaining key decrypt the object without the deleted material?
Are previews and temporary files inside the same key boundary?
Is key deletion monitored and retried?

Avoid claiming cryptographic erasure unless the architecture and operating procedure support the claim.

Keep a tombstone, not a shadow copy

Businesses may need evidence that a submission existed and was removed. That does not require keeping the filename, sender's identity, document category or a hash that could become a stable identifier for sensitive content.

A minimal tombstone can contain:

A random internal submission reference
The workspace reference
The deletion trigger, such as manual closeout or scheduled expiry
The event time
The result and retry status
The authorised actor reference when deletion was manual

The tombstone needs its own retention period. "Non-sensitive" does not mean "keep forever." Decide why the audit evidence is needed and when it can be aggregated or removed.

Audit logs also need protection against alteration and unauthorised access. They should help investigate document access without becoming another repository of sensitive metadata.

Deletion must survive account and billing changes

An expired trial, cancelled subscription or delinquent invoice does not create a new reason to retain documents. Scheduled deletion should continue even when the customer can no longer use paid features.

Account closure has two timelines: active documents and their derivatives, then account, billing and required legal records. Do not merge them. Billing records may follow a different obligation and should not contain document filenames or contents.

The organisation collecting the files should cover this in its document retention policy, including who can place a legitimate hold and how often the hold is reviewed.

External copies remain external

No cloud service can erase a file that a reviewer downloaded to a laptop, a page photographed with a phone or an attachment stored in a separate mailbox.

View-only review reduces routine delivery of originals. Watermarked pages and audited printing can make exceptions more visible. They cannot stop someone who is authorised to see the content from reproducing it.

Original downloads should be deliberate, limited and recorded. Customer policy should state where a required download may be stored, how long it remains and who deletes it.

The same limit applies to senders. Deleting a submission does not remove the source file from their device or an email they sent before using the portal.

Test deletion rather than trusting the button

A useful deletion test checks the service from several directions:

Upload a harmless test PDF and wait for preview processing.
Open it through every authorised review path.
Generate a print view if the feature exists.
Record the active links and expected deletion date.
Delete the submission or let a short test expiry run.
Confirm that old links fail and workspace routes no longer return content.
Confirm that the original, previews, temporary output and mirror are gone from active storage.
Check that sensitive metadata no longer appears in application records or logs.
Confirm that a failed storage call is retried.
Verify that the tombstone contains no filename or document content.

Providers should test the internals and publish the scope. Customers can test links, interface state, account closure and the documented answers.

The broader secure document collection workflow should end with this same closeout action rather than treating deletion as a later clean-up project.

Questions to ask a cloud document provider

Use these questions during procurement and contract review:

Which exact objects and metadata does a manual or scheduled deletion remove?
Are originals, previews, print files and mirrors deleted together?
What prevents access while a multi-step deletion is still running?
How are partial failures retried and reported?
Does deletion remove or destroy document-specific encryption keys?
How long can the data remain in backups, and is it beyond ordinary use?
What happens after a backup restore?
Does automatic deletion continue after cancellation or payment failure?
What non-sensitive evidence remains, and for how long?
Which copies are explicitly outside the provider's control?

Precise answers are more useful than a certification logo or a general claim that data is "permanently deleted."

Frequently asked questions

Is a deleted cloud file gone immediately?

It may disappear from active systems immediately while remaining in encrypted backups until their scheduled expiry. The provider should explain both timelines. During the backup window, the data should stay outside ordinary use and protected by access controls.

Is deleting an encryption key the same as deleting the file?

Destroying the correct key can make encrypted data unreadable and may be an effective cryptographic erase technique. Its value depends on the encryption design, key scope, copies and implementation. The storage object and related metadata should still follow the provider's deletion process.

Should a service keep any record after deletion?

A minimal tombstone can support accountability and failure investigation. It should avoid filenames, sender identities, document contents and object paths. The tombstone also needs a stated purpose and retention period.

Can a provider delete a document from screenshots and downloads?

No. Those copies are outside the service once another device or system holds them. The customer needs access, device and records policies for downloads, prints and captures.

What should happen if deletion partly fails?

The system should keep the document inaccessible, record the failed step without exposing sensitive data and retry safely until every controlled component is removed. It should not report successful deletion while an active original or valid access link remains.

Does account cancellation delete documents automatically?

It should not stop an existing deletion schedule. The exact account-closure behaviour depends on the service contract and documented policy, so confirm the timing before use. Sensitive intake documents should not remain merely because the workspace lost access to paid features.