Document security / How long it lives, and what happens after
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.
The exposure
Document content passes through more third parties than the obvious one. The rendering service sees the markup, which contains the data. The mail provider sees the attachment. A storage provider holds the file. An error tracker may capture a payload. An analytics or logging pipeline may receive fields extracted from it. Each is a party with access to personal data, each needs a basis for that access, and the ones that arrive incidentally, through a debug integration or a monitoring tool, are the ones nobody has listed.
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.
- List every external system that could see document content, including the ones that see it only on failure.
- Include error trackers and log aggregators explicitly, because a captured payload containing markup is a copy of the document's data in a third system.
- Check what your monitoring actually captures rather than what it is configured to capture, since request bodies are a common default.
- Establish the contractual basis for each, and record it where the next questionnaire can find it rather than rediscovering it.
- Reduce the list where you can. A hop that does not need document content should not receive it, and most monitoring does not need it.
- Re-check when a tool is added. A new observability integration is a new processor, and it is added by whoever is debugging rather than by whoever owns the register.
In practice
A fragment, with the thing that goes wrong kept in a comment where it is the more instructive half.
/* Longer than most teams expect, because several arrive incidentally.
rendering service sees the markup, which contains the data
document storage holds the file
mail provider sees the attachment and the recipient
error tracker may capture a request payload on failure
log aggregator whatever your logging sends
APM / tracing may capture request bodies by default
analytics any field extracted from a document
backup provider everything, again
The last five are the ones nobody has listed, because they were added
by whoever was debugging rather than by whoever owns the register. */
// Check what monitoring actually captures, not what you meant it to.
Sentry.init({
beforeSend(event) {
// A captured payload containing markup is a copy of the document's
// data in a third system.
if (event.request?.data) delete event.request.data;
return event;
},
// And do not let breadcrumbs carry it either.
maxBreadcrumbs: 20,
beforeBreadcrumb(b) {
return b.category === "http" && b.data?.body ? null : b;
},
});
/* Reduce the list where you can. Most monitoring does not need document
content and captures it only because that is the default. */What people do instead
Forgetting the error tracker. It is configured to capture request bodies by default, it captures them only on failure so it is invisible in normal operation, and the bodies contain the markup, which contains everything on the document.
How this is found out
By a security questionnaire that asks for a list of sub-processors, or by somebody noticing document content in an error tracker while debugging something unrelated.
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.
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.
Keeping credentials out of a document template
The ways a credential ends up inside markup that is sent to a renderer, and why anything in that markup should be assumed to reach the document.
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.
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.
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.
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.