GDPR erasure: what Kastel erases, and what it does not.

The review - reading the queue and deciding - in the console (hosted plans, or self-hosted Enterprise): the “GDPR erasures” screen, under Settings. Reserved for owners and administrators, reading included; that is not a matter of plan, it is a matter of role.

The full lever - erasing everything Kastel holds about a person, a mailbox or a connector - stays on the command line, on the instance: kastel erase. If we host your Kastel, write to us: it is an operator action, run on the controller's written instruction.

“X has left, cut their access” and “X is exercising their right to erasure” often arrive on the same day and do not have the same answer.

Cutting access erases nothing. A departure never deletes what the person wrote: that knowledge belongs to the company. If the request really is an Article 17 erasure, cut the access first, then follow this page.

Your connectors keep a copy of what they read. When the original disappears at its source - a file deleted from a shared drive, a message removed - your Kastel does not delete the copy on its own initiative. It keeps it, flags it, and asks you.

Those flags collect in one queue: “Deletions awaiting your decision”. Each line says which connector the copy came from and when the disappearance was noticed. The copy stays readable until something is decided.

Why this screen is reserved for owners and administrators, reading included: a raw connector copy belongs to nobody's scope. Filtering it by scope would have emptied the queue for everyone, owner included, while looking reassuringly scoped. The correct wall is therefore the role, and we say so.

Two answers, and only one is irreversible.

• Erase permanently: the copy and everything derived from it go. The operation is sealed into your audit log. Nothing is restored.
• Keep: the flag is cleared, the content stays. “Keep” does not undo an erasure already made - there is no way back.

A confirmation names the number of documents concerned before acting, and says it in those terms. The governed facts in your Kastel that cited the erased source are not deleted: they are flagged, and come back into the “To approve” queue for a human to decide their fate. That is deliberate: erasing a source must not silently remove a company decision that rested on it.

The same screen lists the mailboxes your Kastel holds copies for. That list helps you handle a request; it does not erase - that is the lever in the next section.

Erasing everything your Kastel holds about a person is a separate operation, broader than the queue above, and deliberately outside the console. In one pass it covers: their raw copies, their question history, their feedback on answers, their consultation record and the work traces attributed to them.

On a Kastel you host, that is kastel erase --person followed by the person's identifier. The variants cover a whole mailbox (--mailbox), a whole connector (--connector) or one document (--raw). The requester's name goes into the audit line - never the content.

On a Kastel we host, you have no system access to your instance: the request comes through us, and we run it on written instruction. The result is the same, and it is sealed the same way into your audit chain.

This is the paragraph to copy into your processing records. Erasure covers your Kastel deployment: the raw copies, the derived index, and it triggers human review of the facts derived from them. It does not reach:

• The sealed audit chain. It is never pruned - a proof you can rewrite is no longer a proof. What it holds about consultations is aggregated per day, never the text of pages.
• Your Kastel's versioned history. Your Kastel keeps the history of what your company knew, and when. Removing content from that history is an operator action, destructive and coordinated: it is requested explicitly, it never fires on its own.
• Your backups outside Kastel (infrastructure snapshots, database dumps): those fall under your own retention policy.
• The source system itself. As long as the document exists in the original tool, a sync would bring it back. Exclude the person at ingestion first, erase second.

An erasure always leaves a sealed trace in your audit chain, whatever your plan. What Kastel Enterprise adds is a signed attestation: a cryptographically signed document, issued from the erasure line in the compliance trail, naming the deployment and the sealed record's sequence number.

It verifies offline, with your organisation's public key, without going through Kastel. That is the difference between “we erased it” and “here is the proof, which you can check without taking our word for it”.