Privacy by Design and Default Questions
Designing privacy into products, architectures and the software development lifecycle instead of bolting it on afterward. Covers the privacy-by-design principles and privacy-protective defaults, data minimization and purpose limitation at design time, personal-data flow mapping and PII inventory for a feature, consent and preference design including consent storage, enforcement across web and mobile and region-specific consent flows, retention and deletion design including legal holds, deletion across backups and immutable logs, provable deletion, and data-subject access, export and erasure flows, PII-safe logging, telemetry and session replay, on-device processing to limit data exposure, privacy-versus-personalization trade-offs, privacy in ML training data, feature stores and erasure from trained models, and privacy review gates, checklists, CI/CD checks, release readiness and requirements traceability inside engineering workflows. Includes designing privacy-first features, reference architectures, remediating privacy design flaws and rollout programs across product teams, and working with product, legal and security partners. Cryptographic and statistical privacy techniques, formal impact assessments, data-protection law, cross-border transfer rules, vendor risk, and encryption or access-control mechanics are covered elsewhere.
You find that an internal analytics dashboard has been exposing raw user IDs to the marketing team. Lay out your remediation plan: what you do this week, over the next quarter, and long term, and how you stop the same thing happening again.
Sample Answer
Direct answer
First stop the exposure and find out what happened, then fix the cause, then add guard rails so it cannot reappear. Whether this is a notifiable breach (one that must be reported to the regulator, and sometimes to the people affected) is a decision for the privacy lead and counsel, informed by facts I gather quickly.
This week
- Preserve evidence first, in minutes, before changing anything: save the view definition, access grants, and query and audit logs.
- Cut access. Remove the ID column from the marketing view or restrict the dashboard to the data owners, and confirm by testing as a marketing user.
- Assess who saw what. From logs: which marketing users opened it, for how long, whether data was exported, and whether IDs were joined to anything that identifies people. A raw user ID alone is pseudonymous (it points to a person only through a separate lookup table), but if marketing can link it to emails or purchases it identifies people, and even without that, pseudonymous data is still personal data under GDPR whenever anyone can re-link it. A sample audit-log query for this step:
SELECT viewer_id, count(*), max(rows_returned) FROM audit WHERE object = 'dashboard_x' AND ts > :exposure_start GROUP BY viewer_id(the column is not calleduserbecause USER is a reserved word in PostgreSQL and standard SQL, where an unquoteduserreturns the current database role instead of the per-person column). For scale, if the logs show 6 marketing users opened it and none exported or joined it, that points to low risk; 40 users, an export and a join to the email list points to high risk. - Escalate and judge notification. Tell the privacy lead, security and my manager the same day. Internal exposure to staff without need is a possible incident; if the risk to individuals is unlikely, no regulator notice may be needed, but record the decision and reasoning. If it is a reportable breach, the GDPR clock is 72 hours from becoming aware (Art. 33).
Next quarter
- Replace the dashboard source with an aggregated view with no ID, or a hashed key where joining is genuinely needed. A hashed key is the ID run through a one-way scramble, so the original is not visible; a secret key (used in a keyed hash, often called HMAC) is a value mixed in before scrambling, and keeping it away from marketing stops them rebuilding the original IDs by hashing guesses and matching. A plain salt, which is stored next to the hash and is not secret, would not stop that for guessable IDs. It is still pseudonymous, which is why it is a fallback after the no-ID view.
- Move access to role groups and review who has it (an access recertification: owners periodically confirm each person still needs their access, and remove those who do not).
- Delete extracts and caches made from the exposed data.
- Add a schema rule (a check on the database design): new columns holding identifiers must be classified, and are hidden by default.
Long term and prevention
- A data catalogue (an inventory of data fields and their sensitivity labels) with sensitivity tags that BI (business intelligence) tools respect.
- An automated check in CI that fails when a BI view includes a column tagged as identifier.
- A review gate for new dashboards, with a periodic access recertification.
- A short blameless review (a write-up that records what happened and why without assigning personal fault) recording the cause.
Trade-offs
Marketing may lose analyses they relied on. Offer an aggregate or segment-level equivalent so the need is still met.
As a PM, propose an organizational playbook that defines when to escalate privacy questions to specialist teams (privacy/legal/security): include decision criteria, expected response SLAs, and how to handle urgent vs. non-urgent escalations.
Sample Answer
Direct answer. A one-page playbook with three tiers: a PM may decide alone for the routine, must consult a specialist for defined triggers, and must escalate urgently when there may be harm now. The criteria are about the data and the user impact, so a PM does not need to judge the law. SLA means service-level agreement, here an agreed response time.
Decision criteria: escalate when any is true
- New category of personal data (health, biometrics, precise location, children's data, financial).
- New purpose for data already held, or sharing it with a new third party or country.
- Automated decisions with significant effects on people, or profiling at scale.
- Change to consent, retention, deletion or defaults.
- A regulator, user complaint or customer contract clause raises a privacy question.
- Suspected exposure of personal data (always urgent).
Tiers, owners and response times (illustrative, tune to team size)
| Tier | Example | Route to | Acknowledge | Answer |
|---|---|---|---|---|
| 1 Urgent | Suspected data exposure, regulator or legal demand | Security incident channel, privacy lead and counsel at once | 1 hour | Triage decision within 4 hours, then updates every day, weekends included, until contained |
| 2 Standard | New data field or vendor, new purpose, consent change (a near launch date can ask for an expedited review, but does not make it Tier 1) | Privacy intake form to privacy engineering, counsel if a legal question | 1 business day | 5 business days |
| 3 Routine | Question covered by existing guidance | Self-serve FAQ and weekly office hours | n/a | Same week |
Urgent versus non-urgent handling. Urgent means harm may be happening now or a legal clock may be running (for example, GDPR requires notifying the supervisory authority within 72 hours of becoming aware of a personal data breach, where feasible), so the PM pages the incident route first and writes it up afterwards. Tier 1 times are calendar hours on a 24x7 on-call rota, because the 72-hour clock counts every hour from awareness, nights and weekends included; Tier 2 times are business days. Non-urgent items go through the intake form, which asks: what data, what purpose, who gets it, launch date. The PM stays owner of the product decision; specialists own the answer in their domain.
Checks that it works. Track time to acknowledge, items escalated that turned out routine (tune criteria), and items not escalated that later caused rework (tighten criteria).
Pitfall. Escalating everything buries specialists, and then SLAs slip; keep Tier 3 self-serve.
Your teams ship features that handle personal data, and privacy review happens only just before launch. Where would you add privacy checkpoints across the lifecycle, and what does each one require and automate?
Sample Answer
Direct answer
Move privacy from a single late review to a short checkpoint at each stage, each with a defined input, a decision, an owner and as much automation as is safe. The aim is that the final pre-launch step confirms what was decided earlier and finds nothing new. Humans decide judgement calls (is this purpose acceptable?); automation checks facts (is the field classified, is the retention set, is the scan clean?).
Checkpoints across the lifecycle
| Stage | Requires | Automated | Human decision (owner) |
|---|---|---|---|
| 1. Idea or intake | A short form with five questions: what personal data, whose, why, where it flows, who else receives it | Form triggers criteria: sensitive categories, children, location, profiling, new third party, large scale | Triage by privacy reviewer: light, standard or deep review (product owner submits) |
| 2. Design | Data-flow diagram (a drawing of where personal data enters, moves and is stored), data classification (labelling each field as public, personal or sensitive), retention, lawful purpose (the legal reason for using the data), threat model (a structured list of how things could go wrong, with privacy harms such as unwanted tracking added) | Template completeness check; classification tags required on new schema fields | Architect and privacy reviewer approve design or ask changes |
| 3. Build | Story-level checklist (minimization, consent check, deletion hook, safe logging, a deletion test) in each story's definition of done (the team's agreed checklist that must be true before work counts as finished) | Lint and CI rules: no raw logging of identifiers, schema fields must carry a data class | Engineers self-attest (confirm in writing that they did the check); code reviewer checks |
| 4. Pre-launch verification | Evidence: test that defaults are as designed, deletion works, consent is honoured, data inventory updated | Scans for PII in logs and test data; dependency and SDK checks for unexpected data flows | Approver signs the evidence (engineering manager, privacy reviewer for deep reviews) |
| 5. Release and operate | Monitoring for new fields and new data flows; retention jobs running | Alerts on schema changes without classification; deletion job failures | Owner responds; periodic review on a set cadence |
When a formal impact assessment is needed
Use trigger criteria at stage 1, such as new sensitive data, precise location, children's data, large-scale profiling, automated decisions with significant effect or a new vendor receiving personal data. Automated risk scoring can add a simple points total from those answers and send high scores to the formal assessment. Illustrative scheme: sensitive category 3, children 3, profiling or automated decisions 3, precise location 2, new vendor receiving personal data 2, large scale (for example over 100,000 people) 2; a total of 5 or more, or any single 3-point item, means a formal assessment. A feature with precise location plus a new vendor scores 2 + 2 = 4 and gets a standard review; add large scale and it scores 6 and goes to the formal assessment. The formal data protection impact assessment (DPIA, a written risk assessment of a processing activity, listing the risks to people and how each is reduced) is its own process; here the checkpoint only decides that one is required.
Acceptable evidence at launch
A passing automated test (not a statement), a screenshot of default settings, a link to the retention job and its last successful run, and an updated record of what data the feature handles. "We reviewed it" without an artifact is not evidence.
Story checklist, owners and records
A sample story-level checklist: (1) every new field has a purpose and a data class; (2) retention is set and the delete job exists; (3) the consent check is called before use; (4) logs contain no raw identifiers; (5) a deletion test passes.
Name owners: product owner for the intake form, privacy reviewer for judgement calls, engineering manager for evidence. Record required documents per stage, and keep approvals in the same tracker as the work so they are auditable.
Embedding in agile
Run a short privacy threat-modelling session when a feature is designed (and again on major design changes), not every sprint. Put a few checklist lines in the story template, and review the checklist outcomes at sprint review.
Example: an ML dataset
A team wants to train a model on support chats. At intake the reviewer is triggered by free-text personal data. At design, the dataset gets an approved purpose, a redaction step and a retention limit. Dataset approval is human, because deciding that a purpose is acceptable is a judgement call. The automated parts are scanning for emails and phone numbers, recording the dataset version, and blocking training jobs that read an unapproved dataset. At launch the evidence is the scan report and the approval record.
Pitfall
Gates that block every team equally create queues and workarounds. Scale the review to the risk so low-risk changes pass in minutes and only the high-risk ones wait for people.
Your org has a privacy checklist and review gate, yet teams still ship privacy bugs because compliance is something done at the end. How would you embed privacy into how an ML or product team works day to day so it stops being a separate checklist?
Sample Answer
Direct answer. The checklist fails because it is a late, separate, binary step owned by someone else, so teams optimize for passing it. I would move privacy into the existing workflow: design docs, tickets, code review, pipelines and retrospectives, and let the review gate become a small escalation path for genuinely new risk rather than the main control.
What is wrong with the current setup (the critique)
- Review at the end finds problems after the architecture and data model are fixed, so fixes are expensive and get waived.
- A checklist asks "did you do privacy?" instead of "which personal data does this feature touch and why?".
- Nobody on the team owns the answer, so privacy bugs are the review team's problem.
What I would change, in order
- Start from the bugs. Classify the last few quarters of shipped privacy bugs (for example PII in logs, features trained on data without a purpose check, missing deletion path). Build the first changes around the top classes, so the effort answers a real pain.
- Put the questions in the design doc template. A short section: what personal data, what purpose, retention, who can access, what happens on user deletion or consent withdrawal. A design is not review-ready with it blank. For ML, add: training data sources, whether labels or outputs are personal data.
- Add to the definition of done. Stories touching personal data carry acceptance criteria (for example "event schema tagged with data classification", "deletion path tested"), reviewed like any other criterion.
- Automate the repeatable. Pipeline checks for PII in logs and untagged schema changes catch the common mistakes at pull request time, so humans spend time on judgement.
- Name a privacy champion per team (an engineer with a few hours a week, not a new role), trained by the privacy team, who is the first reviewer and escalates only new patterns.
- Close the loop. Every privacy bug gets a blameless retrospective and a new automated check or template question.
Reasoning on ownership. The engineering manager owns the outcome, the privacy team owns the standard and the tooling, and the gate owns only escalations such as a new sensitive data category.
Measures. Privacy bugs found before merge versus after release, time from first design doc to privacy sign-off, and share of designs that arrive with the section filled in.
What would change my call. If most bugs come from one shared platform, fix it there instead of training every team.
You inherit a team where engineers routinely log user identifiers to debug. How would you change that, covering immediate fixes, habits, and long-term guardrails?
Sample Answer
Direct answer. Treat it as a habit and tooling problem, not a discipline problem. Engineers log IDs because the logs are their fastest debugger, so the change must give them a better way to debug before it takes the old way away. I would sequence it: stop the leak this week, replace the practice over the next weeks, then enforce with guardrails so it stays fixed.
Why it matters. A user ID that can be linked to an account is personal data, usually pseudonymous (it stands in for a name but can still be linked back to a person) rather than anonymous (not linkable at all), and logs are typically retained widely and readable by many people. The risk is broad access, long retention and copies in third-party log tools. A log index is the searchable collection a log tool keeps, and each index has its own retention and access list.
Immediate fixes (first week)
- Measure first: scan a day of logs per service for IDs, emails and tokens and rank services by volume, so the first fixes go where the most data is. A week-1 result might look like this (illustrative):
checkout1,840 hits per day, mostly emails;search310;notifications95; every other service under 20. The first fixes then go tocheckout. - Shorten retention on the worst log indexes and restrict who can search them.
- Stop the new logging: a lightweight change in the shared logging library that masks fields named
email,user_id,phone, plus tokens. - Do not shame anyone. Announce the why, the date and the replacement.
Habits (weeks 2 to 6)
- Give people a better way to debug. Log a request ID or trace ID (a random value per request) instead of the user. Support passes along the user's request ID; engineers follow it across services.
- Where the same user must be followed across requests, log a keyed hash of the ID (HMAC, a hash made with a secret key). A plain hash of an email can be reversed by guessing, so the key matters and sits with a small group. A privileged lookup tool resolves it for a ticket: support enters the user named on the ticket, the tool recomputes that user's keyed hash and shows whether it matches the
user_refin the logs, and it records who asked and the ticket number. - Add a pull request checklist item, "does this log line contain user data?", and run a short session using real log examples.
- Before and after example:
BEFORE: payment failed for user 48213 (jane.doe@example.com) card ending 4242
AFTER : payment failed request_id=7f3a9c2e user_ref=hmac:9d1e4b amount_bucket=50-100 reason=card_declined
Long-term guardrails
- Typed logging: the logger accepts declared fields only, for example
log.info("payment_failed", request_id=rid, amount_bucket="50-100"). A call that addsuser_email=...is rejected at build time (by the type checker in a typed language, or by a schema check in CI where the language cannot enforce it) because that field was never declared, so a free-formuserfield cannot be added casually. - CI (continuous integration) lint that flags log calls with banned field names, and a pipeline scrubber (a filter between the application and log storage) that drops or masks PII (personally identifiable information) patterns such as email addresses before storage.
- Retention tiers: debug logs for days, audit logs separate and locked down.
- A weekly count of scanner hits by team, reviewed with managers. Success is that count trending to near zero, with exceptions tracked.
- An owner for the logging standard, and an exception process that ends in an expiry date.
What would change my call. If a regulator inquiry or an incident is already open, the first week becomes purging and evidence preservation, with counsel involved. If debugging time visibly worsens, fix the tooling before tightening the rules, or engineers will route around it.
Unlock Full Question Bank
Get access to all 6 Privacy by Design and Default interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.