Document security / How long it lives, and what happens after
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.
The exposure
Residency requirements apply to documents the same way they apply to any other data, and documents make the question harder because they move through more places: the system that assembled the data, the service that rendered it, wherever it was stored, the mail provider that delivered it, and any backup of each. A commitment made about where customer data lives is a commitment about all of those, and it is common for the rendering step to be the one nobody checked.
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.
- Enumerate every hop a document takes and establish the answer for each, rather than reasoning from where your own servers are.
- Get the answer from the provider in writing rather than inferring it, and record it where the next person will find it.
- Include the backups. A commitment about where data lives is not satisfied by primary storage alone.
- Include delivery. A mail provider is part of the path and frequently the least examined part of it.
- Where a requirement is strict, consider whether the document needs to be stored at all, since a document that is generated, delivered and not retained has fewer hops to account for.
- Do not state a residency position on behalf of a provider you have not asked. This page cannot tell you where any particular service processes or stores data, and neither can an assumption.
In practice
A fragment, with the thing that goes wrong kept in a comment where it is the more instructive half.
/* Every hop, answered from the provider rather than assumed. This is
a worksheet, not an answer: nothing here can tell you where any
particular service processes or stores data.
hop answer source
------------------------ -------------- ------------------------
application servers ? your own deployment
database ? your own deployment
rendering service ? ask the provider, in
writing
document storage ? ask the provider
backups of each ? often missed; a residency
commitment covers these
mail delivery ? part of the path, and the
least examined part
analytics or logging ? if any document data
reaches it, it is a hop */
// Recorded where the next person will find it, not in a thread.
export const DATA_PATH = [
{ hop: "application", region: "eu-west", source: "our deployment" },
{ hop: "database", region: "eu-west", source: "our deployment" },
{ hop: "rendering", region: "TBC", source: "vendor response pending" },
{ hop: "document storage", region: "TBC", source: "vendor response pending" },
{ hop: "mail delivery", region: "TBC", source: "vendor response pending" },
];
/* Where a requirement is strict, the cheapest simplification is not
storing the document: generated, delivered, not retained is fewer
hops to account for and fewer commitments to make. */What people do instead
Answering the residency question from where your own infrastructure runs. The rendering and delivery hops are usually somebody else's infrastructure, and they are the ones a questionnaire will ask about specifically.
How this is found out
By a customer security questionnaire or a procurement review, which asks about every hop and does not accept an answer about your own servers as an answer about the pipeline.
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.
Which third parties can see your documents, and under what terms
The list of external systems that handle document content, which is longer than most teams expect and is asked about specifically in reviews.
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.
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.
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.
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.