Data You Deleted Can't Be Stolen

Hour six of the incident response call. The forensics lead is on the bridge, and someone asks how many records are in the compromised table. The database administrator says eleven million. The room goes quiet. The company only has four hundred thousand active customers. The other ten and a half million rows are closed accounts from 2009, duplicate rows from a botched CRM migration, test records with realistic-looking Social Security numbers, and an email list a marketing vendor appended in 2017.

The number in the breach notification letter is a retention decision.

We treat data as an asset because storing a terabyte in object storage costs a few dollars a month. We ignore the liability side of the ledger. The true cost of a row of data is not the disk space. It is the legal notification, the credit monitoring, the e-discovery review, and the regulatory fines when that row is exfiltrated. Storage is cheap. Breach notifications are not.

Ask the general counsel for the approved data retention schedule. Ask the lead database administrator for the data map. They will not match. The retention schedule was approved in 2016, lists fourteen systems, and sits in a SharePoint library. A policy saved on a SharePoint drive deletes zero database rows. The database contains fifteen years of transaction history because nobody ever wrote the purge job, and the business users never complained about the storage bill.

Retention schedules fail at the handoff, not at the writing. Records management writes the schedule. Legal owns the hold. Security owns the breach. IT owns the deletion. Four owners, four vocabularies, one massive gap.

Legal holds make this worse. A hold gets applied liberally at the start of a matter and released rarely. A litigation hold placed on a folder, a mailbox, or a database schema in 2019 and never released is just a permanent retention policy written by a paralegal’s inbox. Nobody audits the release side. When legal finally lifts the hold, the notice reaches the records team, but nobody sends the release to the database administrators running the nightly backups.

Every system has a delete button. Almost none have a deletion process. Deletion is a supply chain, not a button.

Trace a record from creation to disposal. The application sets an is_deleted = 1 flag when a user closes their account. The user interface hides the record. The database retains the plain text. An attacker dumping the table gets it all. Setting a boolean flag to false is an application feature, not a security control.

Even when a hard delete runs, the chain is long. Soft delete, hard delete, storage-level purge, snapshot expiry, replica convergence, backup rotation, vendor attestation. There are six or seven links. Typically, two work. The chain is only as strong as the weakest link, and the weakest link is usually the one nobody owns.

Consider the lower environments. Production is locked down and monitored. Developers need realistic data to test against, so the database team clones production into staging, UAT, and integration environments. These environments have weaker controls, wider access, and are rarely purged. Every enterprise has a database named something like PROD_COPY_2019 sitting on a developer subscription. It has a public IP, no patch cycle, and four million rows of real customer data that were refreshed once and never sanitized. If you clone production to UAT without masking, your security perimeter is UAT.

The problem compounds in the backup infrastructure. Ransomware defense requires immutable, air-gapped, write-once storage. Privacy regulations require expiration and purge. These are the same control with opposite requirements.

During a breach, the backup team is asked to delete one data subject from the immutable backup set. They cannot. The tape or the object lock holds forty other customers, and a litigation hold from 2014 froze the rotation at ten years. You cannot selectively delete from an immutable backup. You can only set backup retention at or below the legal schedule, expire media on a defined rotation, and document the post-restore purge process. If a restore brings deleted records back, the restore procedure is part of the retention procedure.

A migration is the best deletion window you will ever get, and the easiest way to double your copies. You have to touch every record anyway. But migration teams keep a full production extract until reconciliation is complete. The reconciliation sign-off happens, the new system goes live, and the extract remains in an S3 bucket through two reorganizations. The archive of the old system is the breach you haven’t had yet.

The copies multiply in other ways, outside the control of any database administrator. A business analyst requests a custom report. A DBA exports the results to a CSV and emails it. The analyst downloads it, uploads it to a departmental SharePoint drive, and runs a pivot table. The CSV now exists in an email outbox, an email inbox, a local Downloads folder, and a SharePoint server. None of these locations are tracked by the data retention policy.

Deletion requires engineering. It demands dedicated sprint cycles, specialized scripts, and automated workflows. It is not an administrative task you can hand to a junior DBA on a Friday afternoon. If the delete script takes fourteen hours, requires an exclusive lock, and forces an outage, it will never run. It will sit on the maintenance window agenda for six quarters and get cancelled five times.

Start with the architecture review. Ask how the system deletes a data subject and how long it takes. Ask where the data gets copied after it lands in the primary database. Ask if the delete propagates upstream and downstream, or only locally. If the system does not support hard deletion, that is a finding for the architecture review, not an excuse. Add the delete path to the design doc template.

For analytics and reporting, replace identifiers with a surrogate key before the data enters the pipeline. The raw data keeps a short clock. The analytics store falls out of scope. Aggregates do not need identifiers. This is cheaper than deletion at the end of the line, and almost nobody does it.

When a customer exercises a right to erasure, you must remember that you deleted them, or the next nightly ETL run will resurrect them. Deletion has to propagate to the system of record or be enforced downstream permanently via a suppression list. The first data subject access request or erasure request will take six weeks, a war room, and produce the most accurate data inventory the company has ever built. That artifact should be a permanent program asset, not a one-off compliance exercise. Use it to build the actual data map.

The problem extends to the supply chain. A vendor contract ends, and the master services agreement says they delete data within 90 days. Their subprocessor keeps backups for three years. Nobody asks for the attestation. Procurement can require a vendor to return data at contract end while leaving unclear what happens to the vendor’s operational copies. The contract needs to mandate deletion on termination with a stated period and an attestation, disclosure of subprocessor backup retention, and the right to audit the deletion claims.

The metric that matters is the ratio of records you would have to notify about to the records you actually need. Track it. Report it to the same audience that sees the vulnerability counts.

You cannot misconfigure the access policies on a file that no longer exists. The safest record is the one you deleted on schedule, in the ordinary course of business, with a log entry to prove it.