A side note here: that can be impossible on a cloudy service where your data may have moved between many nodes over its life, and difficult to guarantee in other circumstances. On future projects consider encryption at rest for all data then all you have to worry about is destroying all copies of the relevant keys. Still try a wipe at the end of course, in the name of security in depth, in case there are keys errantly floating around out there.
If you are performing a secure wipe, don't go OTT with 37 sequenced passes (if your threat model "requires" that then you have other matters to concentrate on!) don't make the final stage zeros: fill the volumes with cat pictures/videos, or if you are feeling evil use shock images instead. Give the cracker that tries to poke around something to look at!
> ... and services by trying to overwrite data with junk values before canceling
Also impossible unfortunately, though again you should try if only to show due diligence. Always assume that once your data is out there it is out there for good. Just like a delete is not often a real delete (just a soft delete where a "deleted" flag is set), an update often only affects the current value leaving it and any previous values still present in history or audit structures.
(not that I'm saying this piece of your advice is bad, I just feel it just needs a few caveats to be explicitly stated)
Yes. Do the best you can. Especially if they use something like paper_trail on Rails or other soft deletes. Maybe ask to the vendor to search/purge databases/files and overwrite free disk space manually too.
For certain types of data and with experise, it might be wise to run your own servers (colo) and encrypt the drives. After surviving to a certain scale, you'll want to save money by running hybrid bare metal+cloud anyhow. Then, you'd have control to nuke your servers (DBAN), local snapshots and encrypted backups. Hybrid infrastructure should allow pinning systems to prevent migrating to or sending snapshots to third-parties.
Aye. While guaranteeing the information is absolutely gone is often impossible, you should at least do what you can make it more difficult to retrieve or be accidentally revealed.
> and encrypt the drives
If you are using VMs then full disk encryption within the VM will work just as well, and most cloud services can offer effectively the same thing with their containers.
You just have to be very careful with key management, which in some cases may be inconvenient (blocking restart until you intervene to provide keys, if you don't want them stored on or directly accessible by the same provider) depending on how paranoid you feel the need to be. Of course if you are truly paranoid, by character or by contractual necessity, keys in memory on shared infrastructure even temporarily could be an issue at which point you need "dedicated cloud" resource or colo/self-host for the affected parts of your apps/infrastructure.
A side note here: that can be impossible on a cloudy service where your data may have moved between many nodes over its life, and difficult to guarantee in other circumstances. On future projects consider encryption at rest for all data then all you have to worry about is destroying all copies of the relevant keys. Still try a wipe at the end of course, in the name of security in depth, in case there are keys errantly floating around out there.
If you are performing a secure wipe, don't go OTT with 37 sequenced passes (if your threat model "requires" that then you have other matters to concentrate on!) don't make the final stage zeros: fill the volumes with cat pictures/videos, or if you are feeling evil use shock images instead. Give the cracker that tries to poke around something to look at!
> ... and services by trying to overwrite data with junk values before canceling
Also impossible unfortunately, though again you should try if only to show due diligence. Always assume that once your data is out there it is out there for good. Just like a delete is not often a real delete (just a soft delete where a "deleted" flag is set), an update often only affects the current value leaving it and any previous values still present in history or audit structures.
(not that I'm saying this piece of your advice is bad, I just feel it just needs a few caveats to be explicitly stated)