Data handling
The design question comes before the security question: a field that was never collected cannot leak, be retained too long, or turn up in a log.
The most reliable way to keep a piece of personal information safe is to not be holding it. A field that was never collected cannot leak, cannot be retained past its purpose, cannot surface in a log four years later, and does not have to be described in a policy — which is why the design question comes before the security question, not after it.
Every field on every form is justified by what is done with it. The test is specific: name the operation that consumes this value. Fields that survive on the grounds that the data might be useful later do not survive, because "might be useful" describes a liability held in advance of a purpose.
The fields most often added are the ones a person would rather ask about on the call anyway. Removing them costs a business nothing and improves completion rates, which makes this the rare compliance decision that is also straightforwardly commercially better.
Free-text fields are treated as though they contain the most sensitive thing a person could type into them, because eventually one will. Somebody will paste a card number into a message box, or describe a medical condition in a notes field, and a system that logs message bodies has then written that into a log aggregator with a different retention policy and a wider audience.
So sensitive values and free text are redacted from logs at the point of writing rather than filtered later. A log line is copied to somewhere else within seconds, and a redaction applied downstream leaves the original in whatever received it first.
Retention is a decision with a number attached, and deletion actually happens. A retention policy that describes an intention while records accumulate indefinitely is worse than none, because it has been written down and can be produced later as evidence of what was supposed to occur.
Data is collected once and read from where it lives, not copied between systems for convenience. Every copy is another place to secure, another place to remember during a deletion request, and another place that can disagree with the original.
What a system holds is written down as an inventory, not inferred from the schema when somebody asks. Which records exist, what personal fields each carries, where they came from, and what depends on them — four columns that take an afternoon to produce and are the prerequisite for answering any question about deletion, retention, or breach scope without a fresh investigation each time.
Personal data in non-production environments is the gap found most often. A staging system restored from a production dump is a production system with weaker access control, less monitoring, broader access, and nobody thinking of it as sensitive, which is a fair description of where incidents actually originate. Test data is generated or anonymized, not copied.
The same applies to exports. A spreadsheet pulled for a report last quarter is a copy of personal data sitting in somebody's downloads folder and in whatever it was emailed through, entirely outside every control the system itself has, and it will not appear in any review that only examines the database.
Access to personal data is scoped by role from the start, not opened broadly and narrowed later. Narrowing is the harder direction politically as well as technically: withdrawing access somebody has had for a year requires explaining why they can no longer be trusted with it, which is a conversation nobody wants and most people avoid.
Third parties that touch personal data are enumerated, named, and limited to what each needs. A business that cannot list who processes its customers' data cannot answer the question when a customer asks, and increasingly they are obliged to ask.
Data leaving the country it was collected in is a decision, not a side effect of choosing a hosting region. It is frequently unavoidable and rarely deliberate, and the difference matters when somebody asks where the data is.
Deletion means deletion, including from backups within their retention window, and where that is not immediately possible the delay is stated rather than glossed. A deletion that leaves the record in seven backups for ninety days is a defensible arrangement and an indefensible thing to be vague about.
The privacy policy is generated from the same configuration that defines what is collected, so it cannot describe a system that does not exist. Most policies are aspirational documents drafted separately from the software; deriving the description from the definition removes the gap where drift lives.
Analytics is chosen on what it collects instead of on what it reports. A tool that fingerprints visitors and reconstructs sessions collects personal data whatever its marketing says, and the honest position is that aggregate counts answer most of the questions a business actually has.
Requests from the people the data is about are designed for rather than improvised when the first one arrives. Somebody asking what is held about them, or asking for it to be deleted, is answerable in minutes where an inventory exists and takes a week of engineering time where it does not — and the deadline for responding does not move to accommodate that.
Nothing here is a certification and it is not offered as one. It is a set of design choices that can be inspected in the code, which is a weaker claim than an attestation and a considerably more checkable one.
The through-line is that most data protection failures are not breaches. They are ordinary systems holding more than they needed for longer than they should, until an unremarkable incident becomes a serious one because of what happened to be in scope.
What this does not cover.
- Buying, enriching, or reselling third-party personal data.
- Collecting fields without a named operation that consumes them.
- Analytics that fingerprints visitors or records sessions.
Security & Compliance
Claims and their disclosures
A claim and its required condition are one object, so a claim whose disclosure is missing cannot be rendered at all.
Security posture
A description of practices, not a certification, published so it can be inspected and argued with.
Secrets and configuration
A credential committed alongside the code has been distributed to everyone who has ever taken a copy, and deleting the file does not retrieve it.
Input and trust boundaries
Anything arriving from a browser was composed by whoever is sitting there, not by the form that was designed.
Sources and verification
A requirement drafted from general knowledge reads exactly like one drafted from the statute, so the source and the date are stored as fields.
Subprocessors
Every third party a system talks to holds part of what customers hand over; the list is short by design and written down.