Privacy by Design and Default Questions

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)

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.

Direct answer. I would run it as a 12-month program in four phases (a reduced version can stop after phase 2 at about month 5): baseline and quick wins, a pilot on two or three teams, platform-wide rollout in advisory mode, then enforcement with metrics. Checks start as warnings, only become blocking once measured as accurate, and the program is sold to engineers as less rework and to executives as fewer incidents and faster reviews. CI/CD means continuous integration and continuous delivery, the automated build, test and deploy pipeline. PII means personally identifiable information. Advisory mode means a check shows a warning and never blocks a merge; a policy gate is an automated check that can stop a deployment; a suppression is a recorded decision to ignore one finding.

Roadmap

The phase lengths sum to 2 + 3 + 4 + 3 = 12 months.

Resources (illustrative, scale to org size). One program lead (technical program manager), two platform or DevOps engineers, one privacy engineer to write and own rules, a part-time counsel or privacy lead for policy questions, and a named champion per pilot team. Compliance owns the written standard and the exception record; engineering owns the checks.

Pilot plan. Pick teams with different stacks, one that ships often. Run advisory-only for several weeks, label every finding as a true positive (the finding is real) or a false positive (it is wrong), and set a go-forward bar before the pilot, for example precision of at least 90 percent (at least 9 in 10 findings are real) over at least 50 labeled findings (illustrative). A rule with 60 findings of which 51 are confirmed has precision 51/60 = 85 percent, so it stays advisory and is tuned; after tuning, 48 confirmed out of 50 is 96 percent and it clears the bar. Pilot exit means the bar is met or the rule is cut.

KPIs

• Coverage: share of repos and pipelines running the checks.
• Precision: share of findings engineers confirm as real, per rule.
• Mean time to fix a finding, and number of suppressions and their expiry.
• Privacy bugs found in production or review versus found in CI (leading indicator).
• Pipeline time added, to prove it does not slow delivery.

Buy-in. Executives: frame as reduced incident and rework risk, with the pilot data as proof. Engineers: findings in the pull request, clear fix guidance, a fast exception path, and a rule that is wrong gets fixed within days. Guard against a tool that engineers learn to bypass.

Risks. Blocking too early causes workarounds; a program with no platform owner stalls after the pilot.

Direct answer. A central consent service that is the single source of truth for what each person agreed to, per purpose, per brand, with an immutable history. SDKs and apps ask it ("may I use this for purpose X?") and receive signed answers (replies carrying a cryptographic signature, so the app can check they came from the service and were not altered); downstream systems are notified of changes by webhooks. Consent is data with a schema version, not a boolean. Build in this order: the consent record and decision API first, then webhooks, then versioning and multi-brand scoping, then the legacy migration.

Core model.

• Subject: a pseudonymous ID plus linked identifiers across brands and subdomains (the cross-brand link only if the user has an account or agreed to it).
• Purpose: a catalogue entry (analytics, personalization, marketing email) with a stable ID, description text and version.
• Legal basis per purpose: consent, contract, legitimate interests (the organisation's own justified need, weighed against the person's rights) and so on. Lawful basis is the legal ground for processing; consent is only one. The service stores the basis so a consent withdrawal does not wrongly stop processing that rests on contract, and so counsel's mapping is visible. Which basis is valid is a legal decision.
• Consent record (an append-only event: each change is a new entry and old entries are never edited): subject, purpose, version of notice text, decision (grant or revoke), timestamp, brand, channel, collection method, and evidence (what UI was shown). Provenance is this evidence trail. Current state is derived from the latest event; nothing is overwritten. An illustrative grant and a later revoke:

{"event_id":"evt_8f31","subject":"sub_2b7c","purpose":"marketing_email","purpose_version":3,"notice_version":"2026-03-b","decision":"grant","brand":"A","channel":"web_banner","ts":"2026-05-02T09:14:07Z","evidence":"ui_snapshot_551"}
{"event_id":"evt_9a07","subject":"sub_2b7c","purpose":"marketing_email","purpose_version":3,"notice_version":"2026-03-b","decision":"revoke","brand":"A","channel":"settings_page","ts":"2026-08-19T16:40:12Z","evidence":"ui_snapshot_602"}

Asking for the decisions of sub_2b7c on brand A now returns marketing_email: revoked (from evt_9a07), while the history endpoint still shows both events.

APIs.

GET  /v1/subjects/{id}/decisions?brand=A      -> current decision per purpose + decision version + signature
POST /v1/subjects/{id}/decisions               -> grant/revoke list [{purpose, decision, notice_version}] (idempotency key required)
GET  /v1/purposes?brand=A                      -> purposes and notice text for the SDK to render
GET  /v1/subjects/{id}/history                 -> events for access requests and audits

An idempotency key is a unique ID the client sends so that retrying the same request after a timeout records it only once. SDKs cache decisions briefly and fail closed (default to the safe state): if the service is unreachable, non-essential processing is off. Clients should hold only a short-lived signed token, never write state directly.

Webhooks. Events such as consent.changed delivered at least once (so duplicates can happen), signed, with an event ID so consumers deduplicate; consumers must be idempotent (handling the same event twice has the same effect as handling it once) and the service retries with backoff and a dead-letter queue (a holding area for events that kept failing, where a person can inspect them). Revocation is time-sensitive, so each downstream system has a target time to stop processing, and the service reports consumers that have not acknowledged. In the example above, the revoke on brand A at 16:40 emits consent.changed; the email platform acknowledges at 16:41 and drops the user from sends; the ad-audience sync has not acknowledged, so the service flags it to its owner; brand B is untouched because the notice the user saw named only brand A.

Versioning schema. Purposes and notice texts are versioned. A change in meaning (not wording) creates a new purpose version and requires fresh consent; old events keep pointing to the version the user saw. API versions are in the URL with long deprecation windows.

Multi-brand scoping. Each purpose is scoped to a brand or a brand group. A user's consent to brand A does not carry to brand B unless the notice named both. Subdomains share a first-party cookie or token only within the same legal controller (the organisation that decides why and how the data is used).

Legacy migration. Phase 1: read-only shadow, import existing flags with provenance "legacy, unverified" and treat weak ones as needing re-consent. Phase 2: apps call the service in parallel with their own check, alerting on mismatch. Phase 3: switch decisions to the service, then delete local stores. Do the highest-risk apps (marketing, ad tech) first.

Trade-offs. A central service is a dependency and an availability risk (hence fail-closed caching) and a high-value target (strong authentication, minimal stored PII). A federated model is easier to roll out but cannot give one consistent revocation.

Direct answer. Give every privacy requirement a stable ID, then make each later artifact (user story, design doc section, code or pipeline control, test, release evidence) cite that ID. Traceability means an auditor can pick any requirement and walk forward to the control and the proof it works, or pick any control and walk backward to the requirement it serves. For an ML product this chain must also cover data and models, not only code.

Artifacts, in order

1. Requirement with an ID, an owner and a testable sentence. Example PR-07: "Records of users who withdrew consent must not enter any training set built after the withdrawal."
2. User story and acceptance criteria in the ticket tracker, tagged PR-07.
3. Design doc section (including the data-flow diagram and the privacy design review record) that says where the control lives, for example "training-set builder joins against the consent table and drops withdrawn users".
4. Control in the system: the join in the dataset build job, with a pull request that references PR-07.
5. Tests tagged PR-07: a unit test with a withdrawn synthetic user, and a pipeline test asserting that user's ID is absent from the built training set.
6. Build and release evidence: the CI run for that commit, the dataset and model version identifiers, the release approval, and the signed-off review. Store them under the release ID.

Traceability matrix (excerpt)

Tool integrations. Use the ticket tracker as the source of IDs, require the ID in branch names or pull request titles (a CI check, meaning an automated build-and-test step that runs on every change, rejects merges without one), tag tests with the ID (test markers or naming), and have CI publish a machine-readable report that joins IDs to test results. The model registry (a catalog of each trained model version) and data versioning tool (which records exactly which snapshot of a dataset was used) record which dataset version trained which model, so the ML-specific link (requirement to dataset to model to release) is queryable instead of reconstructed from memory.

Demonstrating it to auditors. Run a live walk: the auditor picks PR-07 (or a control at random), and you open the matrix, then the pull request, the passing test for that exact release, and the release record. Show the reverse direction too, from a control back to its requirement, and show the report that flags requirements with no test, which proves gaps are visible. The report might read:

Requirement coverage, release 2.8
PR-07  OK       test_withdrawn_excluded: pass
PR-09  OK       test_log_canary: pass
PR-11  NO TEST  no test tagged PR-11

An auditor typically samples items, so the matrix must be generated from the tools, not hand-edited, or the sample will expose drift.

Pitfalls. Hand-maintained spreadsheets rot within a sprint. Requirements written as policy prose ("protect user privacy") cannot be traced because nothing is testable. Evidence for the release you shipped matters, not a later re-run.

Direct answer. End-to-end encryption (E2EE) means only the participants' devices can read the messages (the readable text is plaintext; the scrambled form the server would store is ciphertext), so anything the server must do with the plaintext (index, search, scan, preview) stops working on the server. I would make E2EE the default for private conversations, rebuild the highest-value features on the device, and make anything that needs server access an explicit, labelled opt-in per conversation or tenant, never a silent default.

Technical trade-offs

• Server-side search: the server cannot index ciphertext. Alternatives are a local encrypted index on each device, searchable-encryption schemes (these let the server match a search token against encrypted data without decrypting it, but the server still sees which stored items match each query and how often, which are search patterns; they are rarely used for full-text message search in production), or searching metadata only (sender, time) if the server holds it.
• Multi-device and history: a new device has no history unless keys and messages are transferred from another device or an encrypted backup the user controls.
• Abuse and spam detection: server-side scanning is lost. Move to client-side reporting, rate limits on metadata and user reports.
• Link previews, translation, smart replies: either the device does them or they become opt-in with disclosure.
• Compliance exports and retention: enterprise customers may need eDiscovery (producing a company's messages on request for a lawsuit or investigation), which conflicts with E2EE, so offer a separate non-E2EE tenant mode (a tenant is one customer organisation's workspace), clearly labelled.

User experience trade-offs

• On-device search covers only what is stored locally, so older messages need a restore or sync step. Say so in the product. On a new phone, a search might first return only the 3 months transferred, with a banner such as "Searching 3 months on this device. Restore older messages" and a restore button.
• Setup friction: key backup and recovery prompts. A forgotten recovery key can mean permanently lost history.
• Slower first search on a new device, plus storage and battery cost for the local index.

Decision framework

1. State the promise: "no one but you and your recipients can read this". If a feature breaks it, the feature is not shipped in that mode.
2. Segment conversations: private 1:1 and small groups (E2EE always), large public channels or company workspaces (E2EE optional).
3. List each feature with: needs plaintext on the server? on-device substitute? cost? Ship by value over cost. For example:

4. Anything needing server plaintext requires an explicit per-conversation switch, a visible indicator in the chat, and cannot be turned on retroactively for old messages.
5. Review: security signs off the threat model (who might attack or misuse the system and what each can reach), product the user impact, legal the obligations (lawful requests, child safety and similar duties vary by jurisdiction, and counsel decides).

Mitigating loss of functionality. Ship on-device search first for recent history (for instance the last 12 months, illustrative), then a restore flow. Provide filters that use data devices already have: sender, date, attachment type. Be honest in the UI about what E2EE conversations cannot do.

What would flip the call. If the target customers are regulated enterprises that must archive messages, make the managed, non-E2EE mode the default for their tenants and keep E2EE for consumer use.