Document security / How long it lives, and what happens after
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.
The exposure
Retention is usually expressed as a policy and implemented as nothing. Documents are stored, a period is written in a document somewhere, and no process removes anything, so the actual retention is forever. That is a problem in both directions: holding personal data longer than necessary is an exposure that grows, and a policy the system does not implement is a statement that is not true, which matters when somebody asks.
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.
- Set the period per document class rather than globally, since a marketing brochure and a payslip have nothing in common here.
- Find the floor before setting anything. Some documents have a minimum retention imposed from outside, and that is a constraint rather than a preference.
- Set a maximum too where the document contains personal data, because indefinite retention is a decision even when it is made by omission.
- Record the expiry where your system can see it. The render response carries document_expires when a document is stored, and a system that does not persist it cannot enforce or explain anything.
- Make deletion verifiable: something should count documents past their expiry that still exist, and alert when the number is not zero.
- Keep the metadata after the document is gone. Knowing that an invoice existed, and was delivered, is useful long after the file needs to be available.
In practice
A fragment, with the thing that goes wrong kept in a comment where it is the more instructive half.
// Per class, with a floor and a ceiling.
const RETENTION = {
invoice: { minDays: 2555, maxDays: null }, // a floor imposed from outside
payslip: { minDays: 2190, maxDays: 2555 }, // and a ceiling, because
// it is personal data
brochure: { minDays: 0, maxDays: 90 },
};
// Persist the expiry, or nothing can enforce or explain it.
const res = await pdf.post("/v1/pdf", { html, store: true });
await db.documents.create({
documentId: res.document_id,
expiresAt: res.document_expires,
kind,
});
// Verifiable, not aspirational. A policy nothing enforces is a
// statement that is not true.
schedule.daily(async () => {
const overdue = await db.documents.count({
expiresAt: { lt: new Date() },
deletedAt: null,
});
if (overdue > 0) {
alert.warn("%d documents are past expiry and still present", overdue);
}
});
// Keep the record after the file goes: that an invoice existed and was
// delivered stays useful long after the bytes need to be available.
await db.documents.update(id, {
deletedAt: new Date(),
storageKey: null, // the file
// kind, subjectId, deliveredAt, recipient all retained
});What people do instead
Writing the retention period in a policy document and never implementing the deletion. The stated retention and the actual retention then differ by an unbounded amount, and the difference is discovered by whoever asks for evidence that the policy is followed.
How this is found out
By an audit, or by a storage bill that grows without a corresponding increase in activity, which is the earliest available signal that nothing is being removed.
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.
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.
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.
Classifying generated documents so handling rules can apply
Attaching a sensitivity level to each kind of document, which is what makes every other rule in this cluster applicable rather than aspirational.
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.
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.