Which obligation a certificate discharges
Erasure duties under the DPDP Act, the GDPR and the CCPA share a shape: delete the personal data, then be able to show you deleted it. This page maps each obligation to the certificate field that evidences it, so a reviewer can check the mapping rather than take our word for it.
Read this before the tables
This is not legal advice, and a certificate is not a compliance verdict. It evidences one specific act: that the files you pointed the tool at were overwritten and deleted, by a named method, at a named time, on a named machine — and that the record of it has not been altered since.
It cannot show that you found every copy. Identifying all locations holding a data principal's personal data is your controller obligation and no tool can attest to it. A file-erasure certificate is NIST 800-88 Clear, never Purge. When the obligation is a drive leaving the building rather than records being deleted, the instrument is FileX Drive Purge and the certificate says Purge on its face.
India — Digital Personal Data Protection Act, 2023
The DPDP Act pairs an erasure duty with a general accountability duty, and the 2025 Rules add a scheduled, recurring erasure trigger for larger platforms. That combination is why evidence — not just deletion — is the operative problem.
| Provision | What it requires | Evidenced by |
|---|---|---|
| §8(3) | Erase personal data once the purpose is served and retention is no longer required. | issuedAt + items[] — what went, and when, against your retention schedule. |
| §8(7) | Erase on withdrawal of consent or when the purpose ends, including verified processor-side deletion. | A per-run certificate. A processor can hand the controller a counter-signed record rather than an email saying "done". |
| §12 | Right to correction and erasure — the data principal's request, and its execution. | certificateId, referenced from your DSAR record, with a public countersignature.url. |
| Rule 8 / Third Schedule | Three-year inactivity erasure for e-commerce, social media (≥ 2 crore users) and online gaming (≥ 50 lakh users), after a 48-hour pre-erasure notice. | One certificate per scheduled batch, archived with its timestamp — the recurring, dated evidence trail this rule implies. |
| §8(4) | Reasonable security safeguards. | method — the named overwrite standard and pass count actually applied. |
EU / UK — GDPR
| Provision | What it requires | Evidenced by |
|---|---|---|
| Art. 17 | Right to erasure — erase without undue delay on a valid request. | items[], method, issuedAt: what was erased, how, and when relative to the request date. |
| Art. 5(2) | Accountability — the controller must be able to demonstrate compliance, not merely assert it. | countersignature. This is the one field that makes the record independent: FileX attests it reached us unaltered, so the evidence is not purely self-declared. |
| Art. 30 | Records of processing activities, including erasure. | The console archive and its CSV export — a dated, per-job register. |
| Art. 28(3)(g) | A processor must delete or return personal data at the end of the engagement, at the controller's choice. | A certificate the processor issues and the controller verifies independently, without needing access to the processor's systems. |
| Art. 32 | Security of processing appropriate to the risk. | method.standard and method.passes, alongside the disclaimer stating the assurance level honestly. |
California — CCPA / CPRA
| Provision | What it requires | Evidenced by |
|---|---|---|
| §1798.105 | Right to delete personal information on a consumer's request. | A per-request certificate, referenced from the response you send the consumer. |
| §1798.105(c)(1) | Direct service providers and contractors to delete, and have them do so. | A counter-signed certificate from the service provider — verifiable by you without trusting their word. |
The certificate fields, in full
Every field below is inside the integrity hash unless noted, which is what makes tampering detectable. The full format is in the documentation.
| Field | What it establishes |
|---|---|
certificateId | A stable reference you can cite from a DSAR log or an Art. 30 register. |
issuedAt | When the record was made — the timestamp an "undue delay" question turns on. |
items[] | Per item: name (or a SHA-256 of the path in hashed mode), size, and outcome. |
target | The folder and total bytes covered by the run. |
method | Standard, label, pass count and assurance class actually applied. |
platform | The machine and agent that performed it. |
privacy.filenames | Whether this record reveals filenames or only path hashes — stamped by the server, not claimed by the client. |
disclaimer | The assurance limits, carried inside the evidence itself rather than in marketing. |
integritySha256 | The hash of everything above. Excluded from its own preimage. |
signature | The operator's own signature: "I performed this erasure." Excluded from the preimage. |
countersignature | FileX's attestation that the record reached us unaltered, with a permanent public verification URL. Excluded from the preimage. |
Why a self-signed record is not enough
The free tools produce a genuine, tamper-evident certificate — but you signed it yourself. It proves the record has not changed since you made it; it does not prove to a third party that the erasure happened, because nothing independent attests to it. Our own verifier reports that state as self-signed rather than certified, deliberately.
Under an accountability provision such as GDPR Art. 5(2), that distinction is the whole point: the question is not whether you have a record, but whether anyone other than you stands behind it. That is what a credit buys, and it is the only thing a credit buys.