Privacy by Design and Default Questions

Direct answer. Personal data enters at the gateway and authentication service, is copied at every hop (application servers, database, queue, data lake, analytics), and becomes riskier as copies multiply and context is lost. I would centralize the controls that must be identical everywhere (classification, consent and preference lookup, deletion orchestration, log redaction, retention policy, audit) and leave per-service the controls that depend on that service's purpose (the reason it holds the data, such as delivering orders: what it collects, what it exposes, which fields it stores).

Data flow and placement

One value through the stack. Follow jane.doe@example.com from sign-up. (1) Gateway: it arrives in the request body, so the access log must not keep bodies. (2) Authentication service: stored as the login identifier. (3) Application server: held in a profile record and at risk of leaking into error logs, so the redaction library masks it. (4) Database: users.email, tagged personal with a retention rule. (5) Queue: the user.signed_up event carries user_id, not the email, and the welcome-email service looks up the address itself. (6) Data lake: only tagged fields are ingested, and the email is dropped or replaced with a pseudonymous ID. (7) Analytics: dashboards see only that ID. A deletion request then has to reach steps 2, 4 and 6, and the queue consumers' own copies.

Centralize versus per service

• Central (platform team owns): data catalog (the inventory of what each store holds and how it is classified) and classification tags, consent and preference service, deletion and access request orchestrator that fans out (sends the request to every store in turn and records that each finished), log redaction library or sidecar (a helper process running next to each service that filters its logs and traffic), retention policy engine, audit logging. Reason: one definition of truth, and a bug fixed once is fixed everywhere.
• Per service: deciding which fields it needs and why, honouring the central consent answer, exposing minimal APIs, declaring its data in its schema. Reason: only the service owner knows the purpose.

Extracts. When an analyst needs row-level detail, the extract is logged, time-limited and stamped with the requester's ID, so a leaked file can be traced and the copy expires.

Trade-off. Central controls create a dependency and a bottleneck; keep them as libraries and APIs with clear service levels so teams adopt them.

Short answer. Log the request and start the clock, confirm who is asking in proportion to the risk, collect from every system that holds the person's data by a stable identifier, review and redact, deliver securely, and record it. GDPR Art. 15 gives the person confirmation of processing, a copy of the data, and details such as purposes and recipients. The response is due without undue delay and within one month of receipt, extendable by two further months for complex or numerous requests if you tell the person (Art. 12(3)).

Walkthrough

1. Intake. The email lands in a privacy mailbox, becomes a ticket, and the date of receipt is day 0. Staff may route requests from any channel to it.
2. Identity check. If the email comes from the address on the account, ask them to confirm through the logged-in account or a one-time link to that address. Request an ID document only when there is reasonable doubt (Art. 12(6)), because collecting more data to verify is itself a privacy cost. Never send data to an unverified requester: that would be a breach.
3. Scope. Confirm the request is for access (versus deletion or something else) and which person: one account or several identifiers (email, phone, device id).
4. Collect. Use the data inventory to query each system by user id: production database, support tool, email provider, files, logs where the id appears. Include analytics outputs derived from the person: event history, segments and scores tied to them, not whole-population dashboards.
5. Review. Remove other people's data (Art. 15(4): the right must not harm others' rights), such as other users' names in a shared thread. Counsel handles legal privilege and trade-secret questions.
6. Package. Provide a commonly used electronic form: JSON or CSV for the data, plus a plain-language cover note covering purposes, recipients and retention. For example: profile.json (12 fields), orders.csv (34 rows), events.csv.
7. Deliver. Send an expiring download link to the verified address, secured behind login or sent with a separate code. Do not attach unencrypted exports to email.
8. Close. Record steps, dates, and what was withheld and why.

Timeline example. Request received 3 March: acknowledge within 3 days, deliver by 3 April (one month). If extension is needed, tell the person within that month and give the reason; the outer limit is three months total.

Pitfalls. Impersonation attacks (an attacker asking for someone else's data), missed identifiers, forgetting derived data, and treating the request as a favour instead of a deadline.

Direct answer

Build one consent service as the system of record. Clients capture choices per purpose, the service stores them as an append-only history, other services check against it, and every change is published as an event so downstream services update without polling. Consent here means the user's recorded choice for a specific purpose.

Capture

• The app shows a notice with a version number and one toggle per purpose (analytics, personalised ads, and so on), none pre-set to yes.
• Each choice is sent with user identity (or an anonymous device ID before login, merged at login), purpose, decision, notice version and timestamp.
• Offline: the SDK (software development kit) queues the change and syncs later, with the device's local time stored next to the server's recorded time.

Store

An append-only event log (one row per grant or revocation, only ever added to, never edited) plus a "current state" view derived from it. This keeps history for proof and a fast read for checks.

Check

• Services call a check API (user, purpose, minimum notice version) or read a cached snapshot.
• Fail closed (when unsure, deny): if the service is down and the cached answer is too old, treat consent-dependent processing as not allowed. Essential processing that does not rely on consent keeps working.

Telling other services the user changed their mind

Worked case for ordering: a user switches personalised ads on at 10:00 (sequence 7) and off at 10:05 (sequence 8). The ad service receives sequence 8 first and records "off"; sequence 7 then arrives late. Because 7 is lower than the 8 already applied, it is ignored and ads stay off. Without the rule, the late grant would silently turn ads back on.

Revocation must be as easy as granting (GDPR Article 7(3)). Stopping future processing is immediate; what happens to data already collected is a per-purpose decision (delete, keep aggregated, keep under another lawful basis) that legal confirms. For example, on revoking ads: stop targeting immediately; delete the user's ad-click history; keep the invoice records that tax law requires.

Conflict rule

If two devices change the same purpose offline, the later effective time wins, and a tie goes to the more restrictive choice. Example: a phone, offline, records analytics off at 09:00; a tablet records analytics on at 09:30; both sync at 11:00. The 09:30 choice is later, so analytics is on. If both had been stamped 09:30, the result would be off. Two details keep this consistent with the ordering rule above: the per-user sequence number is assigned by the consent service when it records the resolved outcome, not by arrival order, so a late-arriving offline event that loses the conflict is kept in history but does not become the current state; and the effective time is the device time clamped to the server's receipt time (a device clock set in the future is not trusted), with the server's recorded time stored beside it as noted under capture.

Pitfall

Checking consent only in the app is not enough: the backend must enforce it, because clients can be out of date.

Direct answer

Privacy by design means making privacy a property the system has from the first design meeting, not a review step added before launch. "Personal data" is any information that relates to an identifiable person (an email, a device ID, a location trail). The practical test: if the team deleted the privacy policy tomorrow, would the product still collect, keep and expose as little as it needs to? The most widely cited framework is Ann Cavoukian's seven foundational principles. Article 25 of the GDPR (the EU General Data Protection Regulation) turned the idea into a legal duty of "data protection by design and by default"; its second paragraph requires that, by default, only the personal data necessary for each specific purpose is processed, which is principle 2 below written as law. What matters day to day is what each principle changes in a ticket or a design doc.

The seven principles as real decisions

Worked example: a "find friends" feature

A team wants to upload address books to suggest friends. Principle 1 triggers a design question before code, for example this line in the design doc template: "What personal data does this add, and what is the least we can collect?" Principle 2 means the upload is off until the user taps an explicit prompt. Principle 3 means contacts are matched and then discarded rather than stored. Principle 4 keeps the feature: suggestions still appear. Principle 5 sets a deletion step for the matching data. Principles 6 and 7 add a plain explanation of what happens to contacts and a way to withdraw.

Pitfalls

• Treating the seven principles as a poster. If a principle cannot be tied to a ticket, a default or a test, it is a slogan.
• Equating privacy with security. Security protects data from outsiders; privacy also asks whether you should hold the data at all.
• Claiming "privacy by design" because of a compliance checklist run at the end, which is the opposite of principle 1.

Direct answer. Enforce privacy in the client and in automation, because at 500 million people no human review can keep up. The client checks consent before anything is queued, decides sampling locally, and can only send events declared in a schema. The server strips network identifiers at the edge, splits data by sensitivity, aggregates early, and refuses to show small groups.

Data tiers

1. Essential diagnostics (crash counts, version, performance): minimal, no identifiers, collected under a legal basis (the lawful reason for processing, such as consent or a legitimate need) that counsel signs off.
2. Optional usage (feature use): needs the user's choice, off if they decline.
3. Sensitive events (anything related to browsing, search or content): not collected by default. If a question demands it, measure on-device and send only a coarse result. For example, the browser classifies pages locally and uploads a weekly count per category such as {news: 41, shopping: 12}, never the URLs. A per-install count is still a small browsing profile, so add noise on the device before upload (local differential privacy: each client randomly flips or perturbs its answer, so any one report is deniable but the population totals can still be recovered), and send each report under a fresh random token rather than the install ID described below, because reports sharing one install ID could be chained together for as long as that ID lasts (30 days in the example).

Client design

• Consent: the choice is stored locally and checked before an event is queued, so "no" means nothing is created, not "created and dropped on the server".
• Sampling: the client decides once per metric per period using a local random draw. At 1% that is 5 million reporting clients (500,000,000 x 0.01). At an illustrative 20 events per day, that is 100 million events per day, around 20 GB per day at 200 bytes each. Of those 5,000,000 sampled clients, a feature used by 0.1% of users still shows up on 5,000 (5,000,000 x 0.001), enough to read, which is why 1% can be enough.
• Overhead: batch events, cap queue size and daily upload bytes, upload on idle and on unmetered networks (Wi-Fi rather than a capped mobile plan), and compress.
• Identity: a random install ID, created at install, replaced by a fresh random value on a schedule (say every 30 days, illustrative) with no link kept between old and new, and deleted on opt-out, never a cross-product account ID.

Schema as the enforcement point. Every event and field is declared in a registry with data category, purpose, retention, and owner. CI fails a change that adds an undeclared field, and the ingest service rejects unknown fields. This is how privacy scales across hundreds of engineers.

Server side

• Edge (the first servers that receive uploads, before anything reaches storage): drop IP addresses before logs (keeping only coarse country) and truncate the user agent (the browser's self-description string) to browser and major version.
• Separate stores per tier with different retention (raw 30 days, aggregates longer, illustrative) and access.
• Aggregate early, publish a cell (one row of a result table, such as one country plus browser version) only if it covers a minimum number of distinct clients (say 50, illustrative). A cell with 2 clients identifies them: if you know your colleague is one of the two, the cell's "visited a health site" count tells you about them.
• Automation: automatic expiry (TTL, time-to-live), access audit and an anomaly alert on large exports.

Trade-offs. Sampling reduces rare-event visibility, so use higher rates for crashes and low-volume features and say so in the schema. Rotating IDs break long-term retention analysis, which is the price of unlinkability.

What would change my call. Strict regional rules may require region-specific consent flows and storage location, which counsel decides. A measurement need that cannot be met with coarse data should go to a privacy review before collection, not after.