Privacy by Design Risk Assessment Guide 2026

A privacy by design risk assessment examines the privacy risks of a product, service or process while it is still being designed, when changes are cheap, instead of after launch, when they are expensive and public. It is how the principle of data protection by design and by default becomes something teams actually do, with steps, questions, owners and records. This guide explains what the law requires, when in the product life cycle to assess, which questions to ask at each stage, how default settings and data minimization are tested, and what evidence to keep.

What data protection by design and by default requires

Article 25 of the GDPR requires a controller to implement appropriate technical and organizational measures designed to put the data protection principles into effect, both when deciding the means of processing and during the processing itself, taking into account the state of the art, the cost, the nature, scope, context and purposes of processing and the risks to individuals. It also requires measures to ensure that, by default, only personal data necessary for each specific purpose is processed, in terms of the amount collected, the extent of processing, the period of storage and accessibility. The European Data Protection Board explains the provision in its Guidelines 4/2019 on Article 25.

ISO/IEC 31700-1:2023 sets high-level requirements for privacy by design for consumer goods and services. It is a useful reference for structure even where certification is not sought. Our guide to the privacy risk assessment methodology shows how ratings are produced that the design assessment then uses.

When to carry out a privacy by design risk assessment

Assess at several points, with increasing depth. A single assessment at the end of a project is too late to change the design.

Stage	Purpose of the assessment	Typical outputs
Idea or concept	Screen for privacy impact and decide whether a full assessment is needed	Screening result, initial risks, early advice
Design	Shape data flows, choose what to collect and where to store it	Data map, risk list, design requirements
Build and test	Check that requirements are implemented and defaults are correct	Test results, defects, evidence
Pre-launch	Confirm residual risk and approve	Sign-off, notices, DPIA if required
After launch	Monitor and review with real use	Review record, changes, incidents

Build the first screening into your project intake or product discovery process, so no project starts without answering a short set of privacy questions. Our guide to the privacy review process shows how to embed the gates.

Design questions that surface privacy risk

Ask specific questions at the design stage. Vague prompts such as consider privacy produce little.

1. Purpose. What exactly do we want to achieve, and is each data item needed for that purpose?
2. Data. Which personal data is collected, from whom, and is any of it sensitive, about children or inferred?
3. Minimization. Could we achieve the same result with less data, coarser data or anonymized data?
4. Storage and retention. Where is it stored, for how long, and how is it deleted?
5. Access. Who can see it, and can access be limited by role and logged?
6. Sharing. Which suppliers and partners receive it, and for what purposes?
7. Transparency. How will people learn what happens to their data, at the moment it matters?
8. Control. How can people access, correct, delete or object?
9. Automated decisions. Does the system make or support decisions about people?
10. Change. How could the data be reused later, and what would stop unwanted reuse?

Default settings matter

The by-default requirement means the most privacy-protective setting should apply without the user having to change anything. Test the defaults: what is collected when a user does nothing, which options are pre-ticked, what is visible to other users, whether location or contacts are shared automatically and how long data stays. Regulators have criticized default settings that favor data collection and sharing, and defaults are easy to inspect. Record the tested defaults as evidence.

Techniques that reduce risk at the design stage

Common design measures include collecting less, using pseudonymization or aggregation, processing on the user’s device instead of central servers, separating identifiers from content, encrypting data in transit and at rest, applying short retention with automatic deletion, limiting internal access and building tools for user access and deletion. Consider privacy-enhancing technologies where they fit, such as differential privacy for analytics or secure computation for shared analysis. Choose measures in proportion to the risk and record the reasons for each one, including those you decided against.

Rating and deciding in a privacy by design risk assessment

Use the organization’s rating scales to evaluate each identified risk before and after design measures, and compare the result with your appetite. Our guide to privacy risk appetite explains how limits map to approvals. Where processing is likely to result in high risk, a DPIA is required, and the design assessment should feed into it. See privacy risk assessment versus DPIA for how the two relate. Record risks in the privacy risk register with owners and dates.

Roles and responsibilities

The product owner is accountable for completing the assessment and implementing the measures. Engineers and designers contribute the technical detail. The privacy lead or data protection officer advises, challenges and, where appropriate, escalates. Security supplies input on controls. A senior manager approves the residual risk according to your criteria. Make the assessment part of the definition of done for features that touch personal data, so it cannot be skipped in a sprint.

Evidence and records for a privacy by design risk assessment

Keep the screening record, data map, list of risks and ratings, design decisions and reasons, test evidence for defaults and controls, advice from the data protection officer, approvals and the review plan. Article 25 is not one of the provisions that carries its own documentation requirement, but the accountability principle expects you to be able to demonstrate compliance, and these records are how you do it. A short, consistent record for each project is better than a long document for a few.

Where a project changes direction, repeat the screening. A feature that begins as simple account settings can grow into profiling or sharing, and the earlier answers stop being true.

A short worked example

A fitness app team plans a feature that shares workout routes with friends. The design-stage assessment finds that routes reveal home addresses and daily patterns. The team changes the design: routes are private by default, start and end points are automatically hidden within a radius of a few hundred meters, location precision is reduced for shared views, and users get a clear preview before sharing. Data is deleted after account closure. Testing confirms the defaults, the privacy lead records advice and the product owner signs off. The residual risk is medium, and the feature launches with a review after three months of real use.

Working with security teams

Privacy and security overlap but are not the same. A secure system can still collect too much data or use it in ways people do not expect, as our guide to privacy risk versus cybersecurity risk explains. Bring security engineers into design reviews to agree encryption, access control, logging and incident handling, and make sure privacy engineers are in the threat modeling sessions so that misuse by authorized users is considered alongside outside attack. Agree shared requirements early, so that measures serve both aims and are not argued over at launch.

Common mistakes in a privacy by design risk assessment

Teams assess only after the design is fixed, treat privacy as a legal review at the end, accept default settings that collect more than needed, forget suppliers and analytics tools, fail to test what was designed, leave no record and never review after launch. Another is asking legal to write a policy in place of changing the product. Design measures are what change outcomes for users.

Using a ready structure

If you want a structure for the assessment and register, the Privacy Risk Assessment Report and Workbook provides a structured report, scoring and a working register that project teams can complete at each stage. Whichever tool you use, run the privacy by design risk assessment early, repeat it as the design changes and keep the evidence.

Privacy by design risk assessment FAQ

What is a privacy by design risk assessment?

It is an assessment of privacy risks carried out while a product or process is being designed, so that measures can be built in before launch.

Is it a legal requirement?

Article 25 of the GDPR requires data protection by design and by default. A structured assessment is the usual way to show that the requirement has been met.

How is it different from a DPIA?

A DPIA is a specific legal assessment required for high-risk processing. A design assessment is broader, applies to all projects touching personal data and feeds into a DPIA where one is needed.

What does by default mean?

Only the personal data necessary for each specific purpose is processed by default, in the amount collected, the extent of processing, the storage period and who can access it.

Who should sign it off?

The product owner completes it, the privacy lead advises, and a senior manager approves residual risk according to the organization’s approval criteria.