Privacy by Design and Default Questions

Definitions in plain terms

• Data minimization: collect, keep and expose only the personal data you need for a stated purpose. It limits how much exists to leak, misuse or be asked for later (GDPR Art. 5(1)(c): adequate, relevant and limited to what is necessary).
• Purpose limitation: decide why you collect data before collecting it, and do not reuse it in an incompatible way later, meaning a use the person would not have expected given why you collected it (Art. 5(1)(b)). The "why" is the boundary.

They work as a pair: the purpose tells you what is necessary, and necessity tells you what to drop.

How they change a design

For a feature, ask three questions before building: what is the purpose in one sentence, which fields does that purpose actually need, and when can each be deleted?

Five concrete engineering steps:

1. Write the purpose next to each field in the schema or data catalogue (the shared inventory of what data the company holds and what each field is for).
2. Delete or never collect fields with no stated use.
3. Reduce precision (age band not birth date, city not address).
4. Set a retention period in code (a scheduled delete), not in a policy only.
5. Gate new uses: a pipeline reading the data for a new purpose needs a review.

Worked example: SaaS (software as a service) analytics

A signup form collects name, email, phone, birth date and company. The feature is a welcome email and plan recommendation.

• Needed: first name (for the greeting), email, and company size (ask for a size band such as 1-10 or 11-50 instead of the company name, since the plan recommendation only needs size). Dropped: phone, birth date and the free-text company name.
• Product events stored with a random user key, not email, kept 13 months then aggregated.
• Page analytics: store the page and timestamp, not the full URL with query strings, which can carry names.

If marketing later wants to use signup data for ad targeting, that is a different purpose: it needs its own lawful basis (a legal reason to process, such as consent) or notice, not a quiet reuse. By contrast, using the same email to send the receipt for the plan the person bought is compatible, because the person would expect it. Counsel judges the grey cases by asking how closely the new use relates to the old one, what the person was told, what they would reasonably expect, and how sensitive the data is.

Pitfalls

Collecting "in case we need it" fails minimization. Keeping a purpose so broad ("improve our services") that anything fits fails purpose limitation. Legal details of what counts as compatible reuse belong to counsel.

Direct answer

I would not approve the feature as described. I would run the review as: understand the data flow, assess the specific harms, offer designs that keep the commercial goal with less data (local personalization, coarse categories, separate consent), engage legal early on the health-data question, and give users a clear choice with plain explanation. Health-device telemetry linked to purchases for targeted offers is high risk because it is sensitive, inferential and easy to misuse.

Step 1: Map the flow

What telemetry (heart rate, sleep, steps, glucose?), at what granularity, where it is joined to purchases (client or server), which models use it, who sees the output, which third parties receive it, and how long it is kept. A diagram of this is the first deliverable.

Step 2: Assess the risks

A formal impact assessment is likely required: a DPIA (data protection impact assessment) is a written risk analysis that must be done before high-risk processing, and Art. 35(3)(b) names large-scale processing of special-category data. I would flag that to legal in step 4. The risk register (the list of risks with a likelihood, an impact and a score) is a deliverable of that review. An illustrative extract, scored likelihood x impact on 1 to 5 scales:

The last column is the residual risk: what remains after the controls, which is the figure the risk owner signs.

Step 3: Design alternatives that keep the business goal

1. On-device matching. Keep telemetry on the device. The app picks offers from a coarse local state ("active week") and the server never receives the health data.
2. Coarse, non-health signals. Target on activity level buckets rather than readings, with no condition-linked categories. For example (illustrative cut-offs): under 20 active minutes a day is "low", 20 to 59 is "moderate", 60 or more is "active", and only the bucket name is ever used.
3. Separate, explicit opt-in. An independent, unbundled choice, off by default, with an easy off switch. Offers from it never use sensitive categories.
4. Contextual offers instead of profile-based. Show offers based on what the user is doing now (viewing running shoes), not a health profile.
5. Exclusions. Hard-code excluded categories (medical, pregnancy, mental health) and cap retention of the joined data.

I would recommend options 1 and 3 together. Option 1 removes the sensitive data from the server, which takes out most of the register above at once (breach target, partner sharing, purpose creep). Option 3 makes whatever use remains a deliberate choice by the user. Options 2, 4 and 5 are hardening that applies to either build. Expected cost: less precise targeting and lower conversion than server-side joins, a trade-off I would put in front of the product owner with the risk list.

Step 4: Engage legal

Ask counsel specific questions: which laws apply to this data in our markets, whether explicit consent is the only workable basis, whether the processing needs a DPIA and regulator consultation (Art. 36(1) requires asking the supervisory authority, the data protection regulator, before processing when the DPIA shows high risk that the controller's measures do not reduce), how to treat ad partners, and whether any claims or marketing rules apply. A processor handles data only on our instructions and for our purposes; an independent controller decides its own purposes for the data, which carries its own legal duties and makes the sharing far harder to justify. Counsel decides which an ad partner is. I supply the data-flow diagram and risk register, and counsel decides on the legal basis.

Step 5: Communicate with users

Plain-language, just-in-time notice ("We use your activity level on this device to suggest offers. Your heart-rate data never leaves your phone."), a separate toggle, a visible way to see and delete what is stored, and a notice before any change of purpose. Test the wording with users: ask each tester to say back what is collected and where it goes. Set the pass bar in advance (for example 8 of 10 testers correctly say that heart-rate data stays on the phone). If only 6 of 10 do, the notice has failed and the wording is rewritten and retested.

Decision and escalation

Ship only with legal sign-off and the design changes. If the business insists on server-side joining of raw health data for ads, I would escalate to the risk owner (the executive responsible) with the alternatives and the residual risk (the risk left after controls) in writing, since that decision is theirs, not the review team's. The 10 in the first register row assumes on-device matching, so server-side joining of raw health data does not carry that score: without that control the row stays at its inherent 20 (4 x 5) unless other controls lower it, and the owner signs that higher figure.

Direct answer

Expose a small set of real choices, grouped by what they affect, with privacy-protective starting values. Describe each in one plain sentence about what the app does and what you give up. Then make the screen true by wiring every toggle to an enforced check in the system and testing it.

Controls to expose

• Analytics and diagnostics (on or off): off unless the user opts in where possible.
• Personalization (use my activity to tailor suggestions).
• Location (never, while using, precise or approximate), linking to the system permission.
• Marketing messages and ad personalization, separate from account emails.
• Contacts, photos and microphone access, each separate.
• Data actions: download my data, delete my account, clear history.
• Sharing and visibility of the profile.

Fewer, meaningful toggles beat thirty vague ones. Keep legal terms out of the labels.

Plain-language explanations

Say what happens either way. Example: "Personalized suggestions: we use what you watch to suggest more. If off, you still get suggestions, but they are the same for everyone." Do not use guilt wording (labels that shame the person for saying no, such as "No thanks, I don't care about my privacy") or hide the off option behind extra taps; these are called dark patterns.

Making the screen match the system

1. Store each choice as one preference record (one row per user and setting, such as user 52, analytics = off, changed 3 May), and have services read it through a single check, not copies. In code that is one shared function, is_allowed(user, "analytics"), that every service calls, instead of each service keeping its own copy of the flag.
2. Enforce server-side as well as in the app, since a client toggle alone can be ignored by a backend job.
3. Test: an automated test turns each toggle off, then asserts that the matching events, requests or jobs stop (for example, no analytics calls fire).
4. Review: privacy sign-off whenever a new data use is added, so a new use gets a toggle or a notice.
5. Propagate changes to downstream systems (the other services and data pipelines that use this data) within a stated time, for example 24 hours, by publishing a change event they consume. An app that was offline keeps the old value locally, so it syncs the stored preference at next launch before sending anything, and the server rejects events from users whose record says off.

Worked example

A user switches "Analytics" off. The next app launch makes no requests to the analytics endpoint (a test confirms this), the server stops processing queued events for that user, and the screen shows when the change took effect.

Direct answer. Start the feature in its most private state: off for everyone, then on only for an explicit early-access cohort, with data collection and sharing at the narrowest setting. Gate on the server, not the client. Require a rollback that stops new exposure immediately and also cleans up whatever the bad rollout already wrote.

Starting state (privacy by default). A feature flag is a runtime switch that turns code on for chosen users without a deploy. The flag default is off. The feature's own settings default to the protective choice: new data fields not collected, sharing set to private, analytics events carrying no identifiers, optional data processing off until the user opts in. Early access must not quietly change the privacy terms: an early-access user gets the same notices and consent as everyone else, plus a note that the feature is pre-release.

Gating.

• Evaluate server-side. The server decides the flag per request; a client-side flag only hides UI and the API still answers.
• Authorize separately from the flag. The flag says "this feature exists for this user". Normal access checks still say "this user may see this record". A flag must never widen who can read data.
• Cohort by allow-list, then percentage. Staff, then named early-access accounts, then 1%, 10%, 50%, 100%, each step held until the previous one is clean. Bucket by stable user ID: hash the ID into a number from 0 to 99 and include buckets below the current percentage, so the same user always lands in the same group and does not flip in and out.
• Fail closed (choose the safe state when unsure). If the flag service is down or returns an error, the feature is off, never on.
• Treat the flag config as a controlled change: two-person review, audit log of who changed what, and an owner named on the flag.

Rollback patterns I would require before launch.

1. A kill switch (one control that turns the feature off everywhere) that turns the feature off for all users within minutes, tested in staging and in production on the internal cohort before widening.
2. Backward-safe data: the feature writes to its own tables or fields with a retention date, so switching it off leaves no half-exposed state in shared tables. Schema changes follow expand-then-contract: first add the new column or table beside the old one and ship code that works with both, and only later remove the old one, so a rollback never meets a schema the old code cannot read.
3. Cleanup runbook: a script that finds and removes or re-restricts data created during the bad window (for example records made public by a default bug), with a count of affected users.
4. Cached copies: CDN (content delivery network) and cache entries for the feature's responses are purged on rollback, and tokens or share links it created (credentials that grant access) are revoked.
5. Automatic stop: alarms on privacy-specific signals (spike in 403 responses (the server's "forbidden" reply), share-link creation rate, unexpected fields in logs) that trip the flag off without waiting for a human.
6. Stale flags: a removal date, so the permanent code path is the reviewed one.

If time is short, secure the kill switch (1), the cleanup runbook (3) and the automatic stop (5) first, because they limit how much is exposed, undo what was exposed, and cut the time to notice; the other three reduce residual risk.

Worked example. A "share my profile" feature has a bug that defaults the share link to public. At the 1% step, the share-link alarm trips; the on-call flips the kill switch (feature off), revokes links created in the window (say 120 links), purges the CDN, and a script reverts the setting to private. Because only 1% had it, the exposed set is small and countable, which also makes the breach assessment (the decision, made with the privacy team and counsel, on whether this exposure counts as a reportable personal data breach) tractable.

Trade-offs. Slower ramp and extra tables cost engineering time; flag sprawl creates its own risk. What would change my call: if the feature only processes data the user already sees, I would shorten the ramp; if it touches sensitive categories, I would add a privacy review gate before each step.

Direct answer

Map by user action, not by system: for each thing a user can tap (find friends, share), list what personal data moves, where it is created and stored, and who outside the company receives it. Friend-finder is the sensitive one because it touches people who never signed up.

Flows to map

Follow one contact through it: the user uploads "Sam, +1 415 555 0123". The matching service hashes the number and compares it with the hashed numbers of registered users. If nothing matches, that row is deleted straight away. If it matches, the user is shown a suggestion for Sam, and only the match result is kept. Sam never saw a notice and never agreed to any of this, which is why the row is sensitive.

Each row carries two annotations engineering keeps in the data-flow document: a PII tag (direct identifier, contact data of a non-user, location) and a retention period.

Defaults I would set

Friend-finder and each sharing channel off until the user switches them on, with the contact upload explained before the system permission prompt appears.

What to hand over

• Engineering: the diagram with PII tags and retention annotations, plus tickets for deletion of non-matching contacts and logging redaction.
• Legal: the list of third parties and what each receives, the notice wording changes, the question of lawful basis (the legal ground that permits processing, such as consent or legitimate interests) for the contact data of non-users, contracts with vendors, and whether a DPIA (data protection impact assessment, a written risk analysis required before high-risk processing) is triggered.
• Security: the abuse paths. Hashing phone numbers does not hide them, because the number space is small enough to guess: a 10-digit number has at most 10^10 (10 billion) possibilities, so anyone holding a list of hashes can hash every possible number and look each one up. Modern hardware hashes hundreds of millions of values per second or more (ESTIMATE), so the whole space falls in well under a few minutes (10^10 divided by 3 x 10^8 per second is about 33 seconds; even at a slow 10^7 per second it is about 17 minutes; ESTIMATE). So require rate limits on matching and keep the matching service access-restricted.

Pitfall

Mapping only the first-party database misses the SDKs and partner callbacks, which is where much of the data leaves.