Data erasure & GDPR

DioscHub gives administrators two capabilities that map directly to data-protection duties: search for a person’s data (a subject-access request) and erase it. Both are available on every tier — erasure is not a paid feature.

This page states the exact scope of erasure: what it removes, how it behaves under failure, and what it retains by design. That last part matters. A compliance review is better served by a precise boundary than by a blanket “everything is deleted” claim — so the carve-outs below are stated, not hidden.

What an administrator can do

Find a person’s data. A subject-access search is scoped to a single Assistant: it returns content from within that assistant’s boundary, not across every assistant in the deployment.
Erase at three grains. An operator can erase a single session, a single file, or an entire user.

What a user erasure removes

Erasing a user scrubs the identifiers and content that could re-identify them, across the stores that hold them:

The conversations — the message history for the user’s sessions, and the session records themselves: name, user id, external id, the visited pages, the message preview, and the forwarded auth artifacts held for the session.
The derived data — the user id on usage and analytics records, and the person’s linkage in aggregated signals.
The operational records — error-log messages tied to the session, the user’s identifiers inside approval records, and the user’s rate-limit records.
The files and their index — the user’s uploaded files (both private chat files and any they own), their stored bytes, and the search-index chunks and permissions derived from them.
The identity — the user’s own external identifier is replaced with an irreversible, one-way tombstone (see below), not left in place.

How erasure behaves

Each attempt is transactional. The database work for an erasure runs as a single transaction and is retried as a unit, so a failure rolls back rather than leaving a half-scrubbed record behind.
It makes forward progress. Work already committed to one store is never undone because a different store failed — reverting a committed scrub would put personal data back. Removal from the search index and the file store runs as best-effort with retries, followed by a verification pass that confirms no re-identifiable data survived and raises an error loudly if any did. Treat this as forward progress plus verification — not a single atomic operation spanning every store at once.
The tombstone is one-way. So you can still answer “was this person erased?” without keeping their data, the user’s external identifier is replaced by a keyed one-way hash. It cannot be reversed to the original id, and it depends on a per-deployment erasure secret you configure (DioscHub refuses to start in production without it — see production hardening).

What is retained by design

Erasure deliberately keeps a few things, and a review should know exactly what:

De-identified aggregates. Cross-user patterns that no longer point at any individual are kept; only the link between the person and the aggregate is removed. What remains describes a population, not a person.
The tombstone record. The user’s identity row persists under its irreversible tombstone — that is the erasure marker, holding none of the original data.
Non-subject operational events. Records keyed only to an IP or a network window, not to a person, are cleared on their own schedule rather than by a subject erasure.
The administrative audit trail. The record of who erased what is retained, and it holds no chat user’s data — see Audit trail.

Boundaries to be honest about

Erasure acts on the live datastore. Your backups sit outside this operation; their contents are governed by your own backup and retention policy, not by an erasure you run against the running system.
Erasure is performed on request. An administrator runs it against a subject; it is the mechanism you invoke to meet an erasure obligation, applied when you invoke it.

Next: Administrator roles & permissions.