Personal data system audit: prove deletion and prevent restore from bringing data back

If an audit of an information system that processes personal data stops at a successful API response or an empty customer profile, its evidence is too shallow. A deletion request may remove the primary row while leaving a read replica, search document, cache entry, analytics export, object version, change-data-capture event, or recoverable backup untouched. A later restore can then make the record visible again.

This guide treats deletion as a distributed state transition with testable acceptance criteria. It does not determine whether a particular record must be deleted or retained. The operator and its legal advisers must supply the applicable purpose, retention decision, hold, and approved exception. The technical audit asks a narrower question: does the implemented system reach and preserve that decision across every in-scope copy?

For the broader division between legal, organizational, and technical work, start with the 152-FZ audit guide. The method below goes deeper on deletion and restoration and should not be presented as certification or a legal-compliance opinion.

Define deletion as an outcome, not an endpoint

“Delete user” is an interface action. The auditable outcome must state what becomes unavailable, where, to whom, and under which test. For each data class, choose one of three explicit outcomes supplied by the operator: remove it from active processing; retain it under a documented exception with restricted access; or sanitize the storage or key scope when selective removal is technically appropriate and authorized. Mixing these outcomes creates misleading evidence.

Build a copy graph before running tests. Begin with the authoritative record and follow every write and derivation: synchronous replicas, standby databases, event logs, CDC consumers, search indexes, caches, object storage, generated documents, support systems, data warehouses, exports, audit logs, backups, and vendor-held copies. Record the stable subject identifier and the version or generation of the entity. Email address alone is a poor join key because it can change or be legitimately reused.

The graph should also identify control planes. Who can pause a consumer, bypass retention, restore a snapshot, recover an encryption key, read the suppression ledger, or export data? Those permissions matter because deletion can be technically correct during normal operation and still fail through an administrative path.

Use synthetic canaries wherever possible. A deletion canary must be unique, searchable at every layer, safe to expose to testers, and linked to an expected deletion decision. Add a positive control that should survive. Without the positive control, an empty result can mean a broken query, disconnected replica, failed restore, or empty environment rather than successful deletion.

Turn the copy graph into a test matrix

The following matrix is original audit design, not a vendor requirement or a mandated control set. Adapt it to the actual architecture and record explicit exclusions.

For every row, store the test time, environment, subject generation, query or observation method, actual result, evidence location, and reviewer. An inventory screenshot is not enough if the serving path can bypass that inventory. Conversely, a raw disk scan may be inappropriate for managed storage where the customer has no physical-media access. State the assurance level actually achieved.

Database deletion is not the same as physical sanitization

Logical deletion and physical sanitization answer different questions. PostgreSQL illustrates the distinction. Under MVCC, an updated or deleted row version is not immediately removed; routine VACUUM later reclaims dead-row space for reuse. Standard vacuum generally does not return that space to the operating system. This is database behavior, not evidence that the row is still available through the application, and it is not a secure-erasure guarantee.

The audit should therefore separate four claims: the record is no longer visible to ordinary transactions; replicas applied the deletion; retained database history follows the approved backup and log policy; and end-of-life media sanitization uses a method appropriate to the storage. Do not turn VACUUM FULL, a file compaction, or cloud-provider deletion status into a universal physical-erasure claim.

Bulk index deletion has another trap. An Elasticsearch delete-by-query operation works from a snapshot, can encounter version conflicts, and can leave successful batches committed even if later batches fail. A success status without inspecting failures, conflicts, targeted aliases, backing indexes, and the final search result is incomplete evidence. Refresh affects search visibility; it does not prove that every snapshot, segment, or external export has been sanitized.

Audit CDC as a deletion protocol

Asynchronous propagation is where apparently deleted data often returns. A robust deletion protocol needs more than a database transaction. It needs an immutable event identity, the subject generation, a monotonic source position or comparable ordering signal, idempotent consumers, retry visibility, and a rule for late or replayed events.

Debezium is a useful mechanism example: a database delete can produce a delete event containing prior row data and a tombstone with the same key. Its transformation options can keep, rewrite, or drop these records. Kafka compaction can use a tombstone to remove older records for that key, while the tombstone retention setting bounds how long a rebuilding consumer can take to observe it. These are product mechanics, not personal-data retention deadlines and not proof that every sink processed the deletion.

Test at least four conditions. First, the live consumer receives the deletion and removes its sink record. Second, a deliberately delayed consumer still observes the deletion before the configured marker can disappear. If lag exceeds that window, do not silently restart from the old sink: rebootstrap it or reconcile it against the current authoritative deletion state, then verify the result. Third, rebuilding a sink from retained history does not recreate the deleted generation. Fourth, a late pre-deletion update cannot overwrite the newer deletion state.

Do not suppress an identifier forever. A person may later create a new lawful account using the same email or business identifier. Scope suppression to the deleted entity generation or another versioned identity. The test must show that replay of the old generation is rejected while a valid new creation remains possible. Otherwise the “privacy control” becomes silent data corruption.

Include caches, indexes, exports, and object versions

Caches need two checks: the deletion path invalidates known keys, and no fallback loader repopulates them from a stale source. Test direct key lookup, application behavior, and repopulation after expiry or restart. For search, enumerate aliases and hidden or historical backing indexes instead of querying only the public alias. For analytics, locate raw ingestion, curated tables, notebooks, extracts, dashboards, and scheduled recipient files.

Exports deserve their own ledger because they leave the transactional control loop. Record file name or object ID, subject range, creation time, recipient, storage location, encryption owner, retention decision, and deletion or exception evidence. The application returning 404 says nothing about a spreadsheet already delivered to a support mailbox or vendor workspace.

Versioned object storage can produce particularly deceptive results. In an S3 Object Lock example, a simple delete can return success and add a delete marker while a protected prior version remains. Retention and legal holds apply to object versions, and governance permissions can change what an administrator may bypass. The test must enumerate versions and their lock state. This is an illustration of version semantics, not a recommendation of a cloud location or a claim of Russian legal compliance.

Reconcile immutable backups instead of pretending they disappear

Backups protect availability and can be intentionally immutable. That can conflict with immediate physical removal from every copy. The audit should not recommend breaking an approved hold or shortening a retention period. It should document which backups contain the deleted generation, why they remain, who can restore them, when they become eligible for disposition, and which control prevents ordinary use before then.

PostgreSQL point-in-time recovery shows why the restore path matters: a physical base backup plus archived WAL can reconstruct database state and replay changes to a chosen point. A restore before the deletion can therefore recover the old record. The deletion control is incomplete unless the recovery runbook reconciles deletions before the restored system becomes a source of truth.

NIST SP 800-88r2 ties cryptographic erase to verified encryption and key sanitization. Earlier plaintext and recoverable key copies defeat the claim; check escrow, backups and external KMS recovery. Match the key scope to the deletion unit: a shared key can affect unrelated data. Verify the implementation and completed key destruction; deleting a pointer is insufficient.

Restore into quarantine and reconcile before release

A safe restore test uses an isolated environment with blocked outbound integrations, restricted operator access, separate secrets, and no production consumers. The team first proves that the chosen pre-deletion snapshot actually contains the synthetic deletion canary. It also proves that the snapshot contains a separate positive control. This avoids passing a test against the wrong or empty backup.

The restore suppression ledger must cover deletions that occurred after the snapshot up to the planned cutover, not merely the ledger captured inside the old backup. Establish a cutover watermark or barrier: record the positions for each source or partition included in the first ledger export, keep recording later deletion requests, then apply the final delta through an agreed release boundary. Requests beyond that boundary must remain durably queued for the resumed live deletion path; none may fall between the restore process and normal processing. Keep only the minimum identifiers and metadata needed for suppression, protect access, justify its own retention, and version records by entity generation. The ledger itself is sensitive infrastructure and should not become a permanent shadow database.

1. Prepareisolate the target, block production integrations and establish the first ledger watermark
2. Restoreload the selected backup and prove deleted plus positive canaries existed in that snapshot
3. Reconcilerun controlled replay inside quarantine and apply generation-scoped deletions through rebuilt sinks
4. Validateapply the final deletion delta to a release watermark and verify deleted canary absence and positive control usability, with no unresolved failures
5. Releaseenable production integrations only after signed reconciliation and preserve the evidence bundle

Keep production and outbound integrations disabled until reconciliation completes. Controlled indexing and CDC replay must run inside quarantine because they are needed to rebuild sinks and verify deletion; they must not publish into production, send messages, or call live CRM endpoints. After the final delta is applied, search by all known identifiers in the database, replicas, indexes, caches, object manifests, and rebuilt sinks. Then connect production consumers in a controlled order and watch for old-generation recreation. A single resurrection blocks release.

A concrete acceptance package

Consider a clearly hypothetical retailer with a profile database, read replica, Kafka-based CDC, search cluster, nightly CSV export, and immutable backups. The audit seeds deleted canary A and retained control B, confirms both across all layers, then triggers A’s approved deletion. The live checks require A to disappear and B to remain. One consumer is paused to test lag; another sink is rebuilt from retained events. The export job is run before and after deletion, and object versions are enumerated.

For restoration, the team selects a backup known to contain A and B. It restores into quarantine, imports the current suppression ledger, applies deletions to the restored database and derived stores, and only then starts isolated consumers. Acceptance requires A to be absent under every known key, B to remain functional, no consumer failure or conflict to remain unresolved, and a new account generation using a deliberately reused non-secret identifier to work correctly. No real customer result is implied by this scenario.

The handoff should include the copy graph, retention and hold decisions supplied by the operator, canary definitions, test matrix, raw results, consumer offsets or equivalent positions, conflict and retry records, export inventory, object-version inventory, backup manifest, restore reconciliation record, exceptions, owners, and retest status. Findings should distinguish observed defects from untested areas and from accepted retention.

If remediation is required, track the same canary and acceptance test through the vulnerability remediation process. A green dashboard without the original failing case and a positive control is weak closure evidence.

When an independent pentest adds value

Most deletion assurance comes from architecture review, controlled data-lifecycle tests, and quarantined restoration. A penetration test adds value when the question includes who can bypass deletion, read retained copies, alter holds, recover keys, query hidden indexes, invoke restore, or access the suppression ledger. Those are authorization boundaries that benefit from adversarial testing under explicit rules.

Before commissioning work with Pentest.red, use the pentest scope planner to name systems, identities, synthetic-data rules, restore environment, prohibited actions, and expected evidence. A suitable engagement can combine review of deletion and restore controls with targeted web and API penetration testing of the access paths around retained data. The buyer should receive reproducible tests and limitations, not a promise that every physical medium or provider copy has been erased.