How to verify data deletion.

"We deleted it" is a claim. To verify data deletion is to confirm, independently of the person making the claim, that the records are actually gone. How you do that depends on whether you can query the systems yourself, whether you are checking a vendor, or whether you have been handed a verification record.

Case 1: you own the systems

If you are the engineer who ran the deletion, verification is a query. But the query is only meaningful if you also ran it before. An empty result proves nothing on its own; the row might never have existed, or the query might be wrong. Verification is the pair: matching records before, none after, same query, same systems.

1. Enumerate every system that can hold the subject's data: primary database, replicas that lag, search index, cache, object storage, analytics warehouse, message queues with retention.
2. Write, per system, the query that defines "records about this person". Version it. A query you cannot reproduce cannot be re-run.
3. Run it before the deletion and record the counts or hashes with a timestamp.
4. Run the deletion with your normal tooling.
5. Re-run every query. Any non-empty result means the deletion is incomplete — a replication lag, a soft-delete flag, a denormalised copy.
6. Keep both observations, signed if you can, filed with the request.

Done by hand this is fragile: the "before" is easily skipped, and the evidence is still self-produced. BurnLedger automates the pair of observations with read-only credentials and signs the result; the mechanics are in the quickstart.

Case 2: you are checking a vendor or processor

You cannot query their systems. What you can do is decide what evidence you will accept, and write it into the contract before you need it.

Rank the evidence you might be offered:

• A statement or email. Testimony. Acceptable for low-risk data, weak for anything a regulator may ask about.
• A workflow-platform completion record. Shows the vendor's process marked the task done. Does not show a query against the datastore came back empty.
• A certificate of data destruction. Strong evidence that specific hardware was destroyed; silent about your records in their multi-tenant database. See verification record vs. certificate of data destruction.
• An independently signed deletion certificate. Before-and-after observations of the named systems, signed by a party that did not do the deleting, verifiable by you without the vendor's cooperation.

GDPR Article 28(3)(g) requires processors to delete or return personal data, and delete existing copies, at the end of the service; Article 28(3)(h) obliges them to make available the information needed to demonstrate compliance, but neither says what form that evidence must take. The Verifiable Deletion Addendum is free, CC0 contract language that requires the last kind.

Case 3: you have been handed a deletion certificate

You are an auditor, a DPO reviewing a vendor, or a person checking a company's answer to your own request. The verification record is a file. Verifying it means checking that it says what it appears to say, that the issuer really signed it, and that the issuer cannot have altered it or quietly withdrawn it since.

Check the signatures against published keys

The issuer should publish its signing public keys at a stable URL; BurnLedger's are at /.well-known/burnledger-keys. Fetch them from there — never trust a key only because the verification record contains it. Then verify each signature over the verification record's canonical bytes. If one byte of the verification record was changed after signing, the signature fails. Check the coverage as well as the signatures: every attested system should be verified exactly once, and no system should appear in the verification that was not attested, or a document could quietly gain or lose a store between the two measurements. Confirm the record count is zero in each named system, and check the inclusion proof places the verification record in the public log under a signed tree head. Finally, ask for the current status statement — a verification record can be revoked after issue, and silence about revocation is not the same as a clean answer.

Check the log inclusion proof

If the verification record carries a transparency-log inclusion proof, recompute the Merkle path from the verification record's leaf hash to the signed log head, and verify the head's signature. This proves the verification record was entered in the public log at the claimed position. Anyone can fetch the current log head and ask for a consistency proof; if an issuer rewrote history, the proof fails and the two signed heads are the evidence.

Check the current status

A signature commits to a moment. Revocation is discovered later. Ask the issuer's status endpoint for a fresh signed status statement, and read it strictly: a fresh ACTIVE means the verification record stands; a fresh REVOKED means withdrawn; no statement, or an expired one, means unknown, never valid.

Read the scope

Finally, read what the verification record says it covers: which systems, which queries. A verification record is evidence about those and nothing else. A verification record for two systems is not evidence about a third.

Verifying a BurnLedger verification record

In the browser: open burnledger.io/verify and drop in the verification record JSON. Every check runs locally in the tab; the verification record never leaves your machine. There is a worked example if you want to see it before you have a real file.

Offline: install either SDK (npm i burnledger or pip install burnledger), save the published keys from /.well-known/burnledger-keys as keys.json, and run npx burnledger check --cert certificate.json --keys keys.json (or burnledger check … with the Python package). No account, no network. The full procedure, including how to audit the public log yourself and what happens if BurnLedger ceases to exist, is in How record verification works.

What a successful check looks like

This is the SDK's own test verification record and key file run through the CLI. The transcript is verbatim:

$ npx burnledger check --cert certificate.json --keys keys.json
Certificate dc_111111: VALID (offline — revocation status not checked)
  Subject: sha256:0b8cbe...
  Canonical version: 4.0
  Systems: 2 (postgresql [existence], s3 [full])
  Records before: 49
  Records after: 0
  Committed: 2025-06-15T12:00:00Z
  Verified: 2025-06-15T12:05:00Z
  Transparency log: entry #1, inclusion proof VALID
$ echo $?
0

Line by line, that maps onto the checks above. VALID means both Ed25519 signatures verified against a key in keys.json, not against the key inside the verification record. Systems and the two Records lines are the scope: two named stores, 49 matching records before, none after. Transparency log means the inclusion proof recomputed to the signed tree head. The parenthetical on the first line is the one thing the offline CLI cannot do — revocation is a fresh status statement, so add --online and it prints a Revocation status line as well. Any failure prints one line instead, for example Certificate dc_111111: INVALID (certificate signature is invalid) when a single byte of the file has changed, and exits 1.

Common questions

How can I verify data was deleted if I do not have access to the system?

You cannot verify it directly. You can require evidence produced by someone who did have access and did not perform the deletion, in a form you can check yourself: before-and-after observations under a signature you can verify against published keys. Write that requirement into the contract before the data is handed over.

Is an empty database query proof of deletion?

Only when paired with the same query returning matching records beforehand. On its own, an empty result is consistent with the data never having existed, with the wrong query, or with the wrong system. Verification is the before-and-after pair, not the after alone.

Do I need a BurnLedger account to verify a record?

No. Verification uses BurnLedger's published public keys, the Ed25519 signature algorithm, and an RFC 6962 inclusion proof — all standard. The browser verifier and the CLI work without an account, and the CLI works without a network connection.

What if the verification record verifies but the data is still there?

Then the verification record is evidence about a different scope than you assumed: a system that was not connected, or a query that did not match the copy you found. Compare the system list and query hashes in the verification record against where you found the data. This is why an honest verification record names its systems and states its limits.