Erasure
A journal that cannot be edited and a right to be forgotten are in tension. Cardinal erases the person, not the history.
cardinal redact user alonfils # asks first
cardinal redact user alonfils -yes
The row is not deleted. Journal entries reference entities by ID, and a dangling reference would break audit queries, making the system less accountable in the name of privacy. Instead the personal fields are tombstoned:
| Field | After |
|---|---|
name |
a stable, non-identifying placeholder |
display_name |
null |
attrs (email, employee number, anything extended) |
{} |
reason on every grant they were party to |
null |
| home directory | rewritten to the placeholder |
What survives is the shape of history: that an entity existed, belonged to groups during particular periods, and was later erased. None of it is attributable to a person once the link is severed, which is the ordinary meaning of pseudonymisation under GDPR Article 17.
The account is disabled in the same transaction, and the chain stays valid: erasure is itself an event in it.
Irreversible by design
A reversible erasure is not an erasure. There is no undo, and the placeholder carries no information about who the entity was.
CLI-only, deliberately
It is irreversible, it is rare, and it should require somebody to have gone to the machine and typed it. There is no console equivalent and there should not be one.
What it does not reach
- Backups. A restored older backup contains the personal data again. That is true of every system with backups and it is yours to handle in a retention policy.
- Anything already sent outward. Claims an application copied into its own database, or security events already delivered, are beyond Cardinal's reach.
- "No trace whatsoever." If your obligation is read as removing even the fact that an account existed, this does not satisfy it.