Privacy by design as a set of concrete defaults
Privacy by design is not a workshop, a checklist or a review gate, and running it as any of those produces documents rather than different systems. Article 25 asks for two things: protection built into the processing, and settings that by default collect and expose only what is necessary. Both are decided by defaults in schemas, logging, forms and platform configuration, most of which are set once by someone who was not thinking about privacy at the time.
What does Article 25 actually ask for?
Two distinct things that are often conflated. By design means technical and organisational measures implemented in the processing itself, with pseudonymisation named as an example. By default means that without any user action, only the personal data necessary for each specific purpose is processed, which extends to the amount collected, the extent of processing, the retention period and accessibility.
The default requirement is the sharper of the two because it is testable. A form with a pre-ticked marketing box fails it. A dashboard where every internal user can see full customer records fails it. A tracing configuration that captures request bodies for all endpoints fails it. None of those need a legal argument to identify.
The regulation also expects the state of the art and the cost of implementation to be taken into account, which is a genuine allowance rather than a loophole. It means a small team is not expected to build what a large platform builds, and it does not excuse defaults that are permissive because nobody looked at them.
Which defaults matter most?
The ones that decide how far data spreads before anybody makes a decision about it. Each row below is a specific setting, the failure it prevents, and where to enforce it so it holds for services built after the person who set it has left.
| Default | What it prevents | Where to enforce it |
|---|---|---|
| No identifiers in URL paths or query strings | Personal data in access logs, referrers and CDN logs | API design review plus a route linting rule |
| Logging field allowlist, redaction at emit | Log platform becoming the largest personal data store | Shared logging library, not the collector alone |
| Request and response body capture off | Payloads with personal data in traces and error reports | APM and error tracker configuration in the base image |
| Session replay masks all inputs by default | Capturing card numbers, passwords and health details | Tag configuration, verified with a recorded session |
| Default deny egress from workload namespaces | Undeclared vendors receiving personal data | Network policy in the platform baseline |
| No standing production data access | Wide read access that becomes a breach multiplier | Short-lived credentials through a broker with recording |
| Non-production data masked or synthetic | Real customer records in environments with weak controls | Masking step inside the restore pipeline itself |
Why is logging the biggest offender?
Because it accumulates personal data without anyone choosing to store it, and it usually has the longest retention and the widest read access in the estate. Request logs carry identifiers, tracing spans carry attributes, error reports carry payloads and stack frames with local variables, and audit logs carry names and addresses by design. None of these were classified when they were set up.
Redaction at the collector is the common approach and it is the weaker one, because it fails silently. A new field name that the redaction rule does not match flows straight through, and nobody notices for months. Redacting at the point of emission, through a logging library that only serialises allowlisted fields, fails in the safe direction: a field nobody declared simply does not appear.
Container platforms add a specific trap worth checking. Service mesh and ingress access logs record full request paths including query strings, so an identifier in a URL lands in the mesh telemetry as well as the application log, in a store with its own retention and its own access list. If you fix only the application logging you have fixed one of three copies.
What container platform defaults help most?
Three, and they are all one-time configuration in the platform baseline. Default deny egress per namespace with an explicit allowlist, which means personal data cannot reach a new external destination without a reviewable change and gives you an accurate vendor list as a side effect. Read-only root filesystems and no core dumps in production images, so process memory contents do not end up in a shared artefact bucket. And short-lived, brokered access to production, so the answer to who could read customer data yesterday is a query rather than an estimate.
Image hygiene is the fourth. Datasets and fixtures copied into an image survive in earlier layers even when a later instruction removes them, so any build that touches real data leaves it in the registry. A multi-stage build keeps that material out of the final image, and a registry retention policy stops old layers accumulating indefinitely.
None of these is a privacy feature in the vendor sense, which is why they get set by platform engineers on other grounds and then quietly carry most of the privacy posture. Reviewing the platform baseline against this list is a better use of an afternoon than another design review.
How do you keep new services from regressing?
Put the defaults in the thing teams start from. A service template that arrives with the approved logging library, an egress policy, redaction configured, the export by subject and delete by subject endpoints stubbed, and a retention annotation on every table means the compliant path is the fast one. A review gate does the opposite: it makes the compliant path slower, and teams route around it under deadline.
Then check a small number of things automatically at deployment. Whether the service registered its subject endpoints, whether an egress policy exists, whether any table lacks a retention rule, whether tracing is configured to capture bodies. Four checks that fail loudly beat a twenty question review that nobody reads.
Give the checks an owner and an escape hatch with an expiry. Anything that cannot be bypassed will be disabled eventually, and an exception that lasts a fortnight and then reappears in a review is the pattern that survives real delivery pressure.
What can you test this week?
Search your log platform for an email address you control. Take a test account, use the product normally for ten minutes, then search the full retention window for that address, the account identifier and the device identifier. Count the indices, note the retention on each and check who has read access. This takes an hour and reliably reveals the largest unmanaged personal data store in the organisation.
Second, load your own marketing site with a clean browser profile, refuse all cookie choices, and watch the network panel. Anything firing to a third party is a control that does not work, and it is a common and easily evidenced complaint.
Third, ask how a new engineer gets read access to production customer data, and time it. If the answer is a role that was granted on their first day and has no expiry, that single default is doing more damage to your position than any missing document, and it is fixable in a sprint.
Common questions
- What does privacy by default mean in practice?
- That without any action from the user, only the personal data necessary for a specific purpose is processed, which Article 25(2) extends to the amount collected, the extent of processing, the storage period and who can access it. Concretely it rules out pre-ticked marketing boxes, internal dashboards showing full customer records to everyone, tracing that captures request bodies on all endpoints, and non-production environments holding unmasked production data.
- Why should identifiers stay out of URLs?
- Because a URL is copied into far more places than the application. Paths and query strings appear in web server and ingress access logs, service mesh telemetry, CDN logs, proxy logs, browser history, referrer headers sent to third parties, and error reports. Putting an email address or account identifier in a URL creates several personal data stores at once, each with its own retention period and its own access list.
- Should you redact logs at the collector or in the application?
- In the application, at the point of emission. Collector-side redaction relies on patterns matching what happens to be logged, so a newly added field the rule does not match passes straight through and nobody notices. A logging library that serialises only allowlisted fields fails in the safe direction, because a field nobody declared simply never appears. Collector rules are a useful second layer, not the primary control.
- Which container platform settings affect privacy most?
- Default deny egress per namespace with an explicit allowlist, which prevents undeclared vendors receiving data and produces an accurate destination list as a by-product. Read-only root filesystems with core dumps disabled in production, so process memory does not reach a shared artefact bucket. Brokered short-lived production access instead of standing roles. And multi-stage builds plus registry retention, since data copied into an image survives in earlier layers.
- How do you stop new services regressing on privacy defaults?
- Put the defaults in the service template rather than in a review gate, so the compliant path is the fastest one: approved logging library, egress policy, redaction configured, subject export and delete endpoints stubbed, retention annotations on tables. Then enforce a small number of automated deployment checks that fail loudly, with a time-limited exception route, because any bypass-proof gate eventually gets disabled under delivery pressure.
