What is a deletion certificate?
A deletion certificate is a signed document stating that specific records about a person were present in named systems at one point in time and absent at a later one. It lets someone other than the company that did the deleting — an auditor, a regulator, a customer's DPO — check the claim without taking the company's word for it.
This page is about personal-data deletion under privacy law. It is not about a ship's registry deletion certificate, and not about deleting a TLS or PKI certificate from Windows, Oracle, or a browser.
A note on the name. “Deletion certificate” is what most people search for, and this page uses it throughout for that reason. BurnLedger calls the document it issues a Verification Record: no authority attests it, and calling it a certificate would imply one did. Everything below describes the same artefact under either name — what you check is the signature and the public log.
Why does anyone need one?
Privacy law gives people the right to have their data erased: GDPR Article 17, the CCPA's right to delete, and, for data brokers, California's Delete Act. The same laws make the company accountable for showing it complied: GDPR Article 5(2) says the controller "shall be responsible for, and be able to demonstrate compliance with" the data-protection principles.
Deleting is the easy half. Demonstrating it later is the hard half, because the evidence most teams hold — a closed ticket, a log line, a screenshot — is written by the party being asked to prove itself. GDPR Article 17: how to prove erasure goes through what a regulator can and cannot check. A deletion certificate replaces "believe us" with a record that stands on its own.
What does a deletion certificate contain?
A useful certificate answers five questions, and answers them in a way a third party can check:
- Who is it about? The data subject — ideally as a salted hash of their identifier, so the certificate itself does not leak the email address it is about.
- Which systems? Each datastore that was checked, identified stably, with a commitment (a hash) to the query that defines "records about this person".
- What was found before? A count or hash of matching records, with a timestamp, taken before the deletion.
- What was found after? The same query re-run after the deletion, with its own timestamp. For a certificate to be issued, this must be empty in every system.
- Who signed it, and can that signature be checked? A digital signature over all of the above, made with a key whose public half is published.
BurnLedger's certificate format is documented field by field in Certificate anatomy. In short: one JSON document, per-system before-and-after snapshots, two Ed25519 signatures, and a proof that the certificate was entered into a public log.
A worked example
This is a real format-version 4.0 verification record from BurnLedger's SDK test fixtures, abridged. The byte arrays are shortened to their first few values; the comments are annotations for this page and do not appear in a certificate file.
{
"certificate_format_version": "4.0",
"certificate_id": "11111111-1111-4111-8111-111111111111",
"attestation_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
"issued_at": "2025-06-15T12:05:01Z",
"status": "ACTIVE", // status at signing; check it fresh later
"issuer": {
"name": "BurnLedger",
"legal_entity": "ProChatFlow LLC",
"public_key": [5, 6, 136, 63, …], // 32 bytes, Ed25519 — WHO SIGNED
"key_id": "dp_k_d59705f4…" // match against /.well-known/burnledger-keys
},
"subject": {
"identifier_hash": [11, 140, 190, 29, …], // 32 bytes, salted SHA-256 — WHO IT IS ABOUT
"identifier_type_hint": "email" // the email itself is not in the file
},
"attestation": {
"proof_mode": "count",
"attested_at": "2025-06-15T12:00:00Z", // when presence was observed
"attestation_signature": [153, 150, …] // 64 bytes, signed before the deletion
},
"systems": [ // WHICH SYSTEMS — one entry each
{
"system_id": "5111e111-1111-4111-8111-111111111111",
"system_name": "users <db> & cache", // display only
"connector_type": "postgresql",
"hash_scope": "existence",
"query_hash": [118, 56, 100, …], // 32 bytes: commits to the query that defines "this person"
"attested_count": 42, // WHAT WAS FOUND BEFORE
"attested_at": "2025-06-15T12:00:00Z",
"verified_count": 0, // WHAT WAS FOUND AFTER — must be 0 to issue
"verified_at": "2025-06-15T12:05:00Z"
},
{
"system_id": "5222e222-2222-4222-8222-222222222222",
"system_name": "logs-s3",
"connector_type": "s3",
"hash_scope": "full",
"query_hash": [7, 60, 169, …],
"attested_count": 7,
"attested_at": "2025-06-15T12:00:00Z",
"verified_count": 0,
"verified_at": "2025-06-15T12:05:00Z"
}
],
"scope": { // binds the file to the limitations text it was issued under
"version": "1.0",
"text_sha256": [216, 30, 163, …]
},
"certificate_signature": [233, 21, 39, …], // 64 bytes over everything above — CAN THE SIGNATURE BE CHECKED
"transparency_status": "INCLUDED",
"transparency": { // proof it sat in the public log when the head was signed
"log_url": "https://log.burnledger.io",
"entry_index": 1,
"tree_size": 4,
"appended_at": "2025-06-15T12:05:01Z",
"inclusion_proof": [[170, 101, …], [193, 52, …]],
"signed_tree_head": {
"tree_size": 4,
"root_hash": [155, 176, 221, …],
"timestamp": "2025-06-15T12:05:01Z",
"signature": [165, 67, 196, …] // 64 bytes, Ed25519
}
}
}Read top to bottom, the file answers the five questions in order: a hashed subject, two named systems with a query hash each, 42 and 7 matching records at 12:00:00Z, zero in both at 12:05:00Z, and a signature plus a log inclusion proof over all of it. Nothing in it says what the person's email was or what the records contained.
Who issues a deletion certificate?
Three kinds of party issue documents that go by this name, and they are not interchangeable.
The company itself. A letter or PDF saying "we have deleted your data". This is self-attestation. It may be honest, but nothing in it lets a reader distinguish honest from not.
A privacy-workflow platform. Tools that orchestrate deletion requests across a company's systems can export a completion record. These are valuable for running the process, but the record reflects that a task was marked done, not that a query against the datastore came back empty.
An independent verifier. A service with read-only access to the systems that observes presence, waits for the company to delete with its own tools, observes absence, and signs what it saw. This is what BurnLedger does. Because it never performs the deletion and never stores the data — records are hashed in connector memory and discarded — its statement is about observations, not about its own work.
What does a deletion certificate prove — and not prove?
It proves that, for the queries it names, matching records were present in the identified systems at the attested time and absent at the verified time, and that the signer vouches for those two observations. If the certificate is also entered in a public, append-only log, it additionally proves that it sat in that log at the index it names when the log head was signed, so the issuer cannot later deny it, backdate it, or quietly alter it. It does not prove that every copy of a person's data everywhere is gone. It says nothing about systems that were never connected, records the query did not match, backups, or exports living outside the queried stores. A certificate is only as complete as the set of systems behind it, and honest documentation says so. BurnLedger's does, under What a certificate proves, and what it doesn't.
Is a deletion certificate the same as a certificate of data destruction?
No. A certificate of data destruction is an IT-asset-disposition document: a vendor shredded or wiped physical drives and lists their serial numbers. A deletion certificate is about a person's records inside live databases and object stores that keep running. The two solve different problems and are audited against different standards. The differences are laid out in Deletion certificate vs. certificate of data destruction.
How do you verify one?
A well-designed certificate can be verified by anyone, offline, with standard cryptography: check the signature against the issuer's published public key, and check the log inclusion proof against a signed log head. You should not need an account with the issuer, and the issuer should not need to still exist. The step-by-step is in How to verify data deletion, and BurnLedger certificates can be checked in the browser at burnledger.io/verify.
Common questions
Is a deletion certificate legally required?
No law names the artifact. GDPR Article 5(2) requires a controller to be able to demonstrate compliance with the principles erasure serves; the CCPA regulations require a 24-month record of each request and the response (11 CCR §7101); the Delete Act puts data brokers under independent audit from 2028. A deletion certificate is one way to meet those duties with evidence a third party can check rather than a record they must take on trust.
Can I issue my own deletion certificate?
You can sign a statement with your own key, and it is better than a screenshot. But a reviewer still has to trust that you observed what you say you observed. Independence — an issuer that did not perform the deletion and could not have made the records disappear — is what turns a signed statement into evidence.
Does a deletion certificate contain the personal data it is about?
It should not. BurnLedger's verification record carries a salted SHA-256 hash of the subject identifier and per-system record counts or hashes; the raw identifier and the record contents are never stored and never appear in the file.
What happens if the issuer goes out of business?
Signatures and the inclusion proof still verify: keep a copy of the issuer's public keys next to your archived certificates and any engineer can re-check them later. What you lose is a fresh revocation status; a careful verifier then reports revocation as unknown rather than treating the certificate as valid.