Privacy by design means considering personal-data purpose, necessity, choice, access, retention, security, and user expectations while a feature is still being shaped. Collect the least information needed for a defined outcome, keep uses compatible with that purpose, provide meaningful controls, and verify the complete data lifecycle. Qualified privacy or legal specialists should determine specific obligations.
Who this is for: Product managers, designers, developers, and privacy partners shaping features that collect or use information about people.
- Define the user benefit and permitted purpose before selecting fields, events, vendors, or retention periods.
- Minimize collection, derivation, access, sharing, display, and storage across the entire product flow.
- Give people understandable choices and operational routes to access, correct, export, or delete data where applicable.
Begin with purpose and expectations
Write the concrete outcome the feature serves and identify whose information is involved. Distinguish data required to provide the requested function from data that might be useful for analytics, personalization, advertising, safety, or future research. A broad statement such as improving the product is too vague to guide collection or user understanding.
Describe what a reasonable person would expect at the moment of interaction. Note children, employees, patients, location, communications, biometrics, or other contexts that may require specialist review. Product teams should not invent legal conclusions. They should surface facts, alternatives, and unresolved questions early enough for accountable privacy and legal owners to act.
Map and minimize the data lifecycle
Create a field-level map from collection through validation, derivation, storage, internal access, vendor transfer, display, export, retention, backup, and deletion. Include identifiers and metadata that can become identifying when combined. Label source, purpose, owner, sensitivity, system of record, recipients, and the event that ends the need.
Challenge each field and copy. Ask whether coarser precision, local processing, aggregation, pseudonymous identifiers, shorter retention, or an existing value can achieve the outcome. Minimize logs and test fixtures too. Removing an interface field while retaining the same data in analytics, support exports, or backups does not reduce the actual privacy surface.
Design choices and access boundaries
Present important information where a person makes the decision, using language tied to the real data use. Keep optional uses distinguishable from a service requirement and avoid confusing defaults or pressure. Provide settings that reflect backend behavior. If a choice cannot take effect immediately, explain the state and expected processing without making unsupported promises.
Authorize personal-data access by job and task, not broad curiosity. Limit administrative search, exports, vendor access, and production debugging. Mask fields where full values are unnecessary and record consequential access without copying sensitive content into logs. Separate product permissions from database administration and review emergency access after every use.
Verify rights, failure, and change
Test the full user journey for correction, access, export, consent change, and deletion where the product offers or must support them. Confirm identity safely, prevent cross-account disclosure, and inspect downstream stores, derived data, queues, vendors, and backups. Define how delayed backup expiration works instead of claiming immediate erasure everywhere when that is untrue.
Review new uses, integrations, fields, models, and analytics against the original purpose before release. Prepare incident escalation for unexpected disclosure or collection. Revisit notices, choices, access, vendor flows, retention, deletion evidence, and current OWASP guidance quarterly. Record decisions and involve qualified specialists whenever product facts or applicable requirements change.
Design privacy for a focus reminder
A productivity product wants to remind users when their usual focused-work period begins without building a detailed activity profile.
- Define the user-requested outcome and separate it from optional team analytics or marketing uses.
- Compare storing raw activity events with computing a coarse preferred time window and retaining only that result.
- Keep the setting off until the user chooses it, explain the calculation near the control, and provide reset and disable actions.
- Restrict the derived preference to the reminder service, omit content details, and set a deletion event when the feature is disabled.
- Test account separation, setting changes, exports, deletion, logs, and backup expiration using synthetic profiles before release.
Product privacy design brief
Complete this brief before implementation and revisit it whenever the feature gains a new data use.
- Purpose: user outcome, data subjects, expected use, optional uses, decision owner, and specialist questions.
- Data map: field, source, derivation, store, recipient, sensitivity, location, retention, and deletion event.
- Minimization: removed fields, reduced precision, local processing, aggregation, access scope, and logging limits.
- User experience: timely explanation, choice, correction, export, deletion, failure state, and support route.
- Verification: synthetic tests, vendor confirmation, backup behavior, incident escalation, reviewer, and quarterly date.
Common mistakes
- Collecting extra information for possible future use before defining a concrete compatible purpose and owner.
- Treating a privacy notice as the control while backend access, analytics copies, and retention remain unchanged.
- Promising instant deletion without checking queues, derived records, vendor systems, logs, and protected backups.
Try one
A team wants to add precise location to a social feature so nearby posts can be ranked. How should privacy by design change the proposal?
A strong answer defines the user benefit, tests whether coarse or on-device location can meet it, and separates required ranking from unrelated analytics. It specifies clear choice, restricted access, short retention, safe display, vendor limits, account-separated tests, deletion behavior, and incident escalation. It also flags contextual and jurisdictional questions for qualified privacy review rather than asserting one universal legal answer.
Sources
- OWASP User Privacy Protection Cheat SheetOWASP engineering considerations for reducing privacy exposure.
- CISA Secure by DesignCISA guidance for making customer security a core product requirement.