Document security / How long it lives, and what happens after
Erasing a person's data when the document is a financial record
A genuine conflict between a person's right to have their data removed and a business's obligation to retain records, which is resolved by policy rather than by a library.
The exposure
An erasure request arrives and the person's data is inside documents that other rules require you to keep. Both obligations are real. The conflict is not technical and cannot be resolved by choosing a better storage layer, and it is worth saying plainly that the answer depends on jurisdiction, on the kind of document and on advice you should get rather than infer. What a system can do is make whatever answer you are given implementable, which means being able to find every document about a person, and being able to act on them selectively rather than all or nothing.
The decisions
Reasons rather than a description of the code. Each one has a default that is fine for a page and wrong for a file somebody keeps.
- Be able to find every document about a person, which requires a subject identifier on every document record rather than only a customer identifier on some of them.
- Separate the erasure decision from the erasure mechanism. The mechanism should support delete, redact-and-regenerate and retain-with-restriction, because the decision may be any of the three.
- Record the decision and its basis against the request, since the question afterwards is why this was handled this way.
- Support restricting access without deleting, which is frequently the practical resolution when a record must be retained but need not be reachable.
- Handle derived copies: caches, backups, delivered attachments and analytics extracts are all places a document went, and an erasure that misses them is incomplete.
- Do not build the policy into the code. Encode the mechanisms and let the policy be configuration, because the policy will change and the mechanisms will not.
In practice
A fragment, with the thing that goes wrong kept in a comment where it is the more instructive half.
/* The conflict is real and it is not technical:
a person asks for their data to be erased
other obligations require the records to be retained
Both can be true at once. Which wins depends on jurisdiction, on the
kind of document and on advice you should take rather than infer.
Nothing here tells you the answer.
What a system can do is make whichever answer you are given
implementable. */
// 1. Find everything about the person. Needs a subject identifier on
// every document record, not a customer id on some of them.
const documents = await db.documents.find({ subjectId: person.id });
// 2. Three mechanisms, because the decision may be any of them.
async function applyErasureDecision(doc, decision, { by, basis }) {
switch (decision) {
case "delete":
await storage.delete(doc.storageKey);
await db.documents.update(doc.id, { deletedAt: new Date(), storageKey: null });
break;
case "redact-and-regenerate":
// The record survives; the personal data does not.
await regenerateWithout(doc, ["name", "address", "dateOfBirth"]);
break;
case "retain-restricted":
// Frequently the practical resolution: kept, not reachable.
await db.documents.update(doc.id, { accessRestricted: true, restrictedAt: new Date() });
break;
}
// The question afterwards is always why, and by whom.
await audit.record({ action: "erasure.applied", documentId: doc.id, decision, by, basis });
}
/* 3. The copies. An erasure that misses these is incomplete:
caches purge by key
backups know the rotation, and whether they are in scope
delivered
attachments gone; cannot be recalled. This is the argument
for links over attachments.
analytics
extracts separate system, separate deletion */What people do instead
Implementing erasure as a hard delete because that is what the word suggests. It destroys records that other obligations require, and the mistake is not recoverable, which makes it worse than pausing to ask.
How this is found out
When the first request arrives, which is when a system either has a subject index and three mechanisms or does not. Building it beforehand takes an afternoon; building it under a statutory deadline does not.
Frequently asked
Does this page tell me what the law requires?
No, and deliberately not. Retention periods, erasure obligations and residency rules vary by jurisdiction, by industry and by the kind of document, and they change. What these pages describe is the shape of the problem and the mechanisms a system needs in order to implement whatever answer your own advisers give you. Where a genuine tension exists, such as an immutable record against a right to erasure, it is named as a tension rather than resolved.
Why is so much of this about the contents rather than access control?
Because access control decides who can obtain a copy and has no opinion at all about what happens to the copy. Once a document is on somebody's laptop, forwarded to a colleague or printed, every control listed here has already stopped applying to it. What is inside the file is therefore the part that keeps mattering, which is the opposite of the balance you would strike for a page.
How much of this applies at a small volume?
Most of it, because these are decisions rather than infrastructure. Redacting by omitting rather than covering costs nothing. Deciding what goes on a template costs one review. Classification is one object in code. Legal hold and an audit trail are the two that take real work, and both are far cheaper to build before they are requested than under the deadline that comes with the request.
Related security topics
The decisions that depend on each other, then the rest of the same group.
Deciding how long to keep a document, and proving it was deleted
The period a document remains available and the mechanism that removes it afterwards, where the second half is the one that is usually missing.
Suspending deletion for documents under legal hold
The ability to stop deleting a defined set of documents indefinitely, which overrides every retention rule and has to be built before it is needed.
Recording who generated, accessed and shared each document
The record of what happened to a document and who did it, which is asked for after an incident and cannot be reconstructed then.
Responding when a document goes to the wrong recipient
The response to the most common document incident, where the technical options are limited and the decisions are mostly about scope and disclosure.
Where a generated document is processed and stored
The question of which jurisdictions a document passes through, which has to be answered from your providers rather than assumed.
Every document security topic
The full list, grouped by access, contents and what happens afterwards.
What this API actually does
The options and endpoints these decisions are built on, one page each.
Most of these are decisions rather than features, and the cheapest time to make them is before the first document is delivered rather than after one reaches the wrong person.