Skip to main content
The state of ai impact assessment
Category: Privacy Principles

Privacy by Design and by Default

Also known as: PbD, Data Protection by Design and by Default, Privacy by Design, Data Protection by Design, Data Protection by Default
Simply put

Privacy by Design and by Default is the idea that organisations should build data protection into their products, services, and systems from the start, rather than adding it afterward. "By default" means that, without any action from the user, only the personal information genuinely needed for a specific purpose should be collected and processed, with the strongest privacy settings applied automatically. In the EU and UK, this is not just a good-practice concept but a legal requirement under data protection law.

Formal definition

Under the EU GDPR and the UK GDPR, data protection by design and by default is a binding accountability obligation requiring controllers to implement appropriate technical and organisational measures that embed data protection principles (such as data minimisation) into processing activities, and to do so both at the time of determining the means of processing and during the processing itself. "By design" refers to integrating data protection through technology and process design from the outset; "by default" requires that, absent user intervention, processing is limited to what is necessary for each specific purpose, applying the highest available privacy protection to the amount of data collected, the extent of processing, retention periods, and accessibility. This entry describes the legal obligation as framed in EU/UK data protection law and should be distinguished from the broader, voluntary seven-principle "Privacy by Design" framework originating in privacy engineering practice, which is conceptually related but not itself law. The precise statutory wording, article references, and enforcement expectations should be verified against the current authoritative text of the applicable regulation and the relevant supervisory authority's guidance, as interpretation and enforcement practice continue to evolve and application to specific circumstances requires professional judgement.

Why it matters

Data protection by design and by default shifts the moment at which privacy considerations enter a project. Rather than treating data protection as a compliance layer bolted on before launch, the obligation requires organisations to account for it when they determine how processing will occur and throughout the life of that processing. In the EU and UK, this is a binding accountability obligation on controllers under the GDPR and UK GDPR, not merely a matter of good practice, which means design decisions that ignore data minimisation or default to broad data collection can themselves constitute a breach even where no incident occurs.

The "by default" element carries particular weight because it addresses the reality that most users never change the settings they are given. The European Commission's guidance frames the expectation that, by default, personal data is processed with the highest privacy protection, and the ICO frames the requirement that use of personal information be limited to what is necessary to achieve each specific purpose. A product that collects more data than a purpose requires, retains it longer than needed, or exposes it more widely than necessary can fall short of the standard regardless of whether users are technically able to tighten those settings themselves.

Because interpretation and enforcement practice continue to evolve, and because the statutory obligation is distinct from the broader voluntary privacy engineering framework of the same name, organisations should treat the design and default requirements as fact-specific. What counts as "appropriate" measures depends on the nature of the processing, the risk to individuals, and the state of available technology, and application to particular circumstances requires professional judgement against the current authoritative text and supervisory authority guidance.

Who it's relevant to

Controllers under the EU and UK GDPR
Organisations that determine the purposes and means of processing personal data bear this obligation directly. It applies both when they design or select processing systems and while processing continues, and it forms part of their broader accountability duties. Note that the obligation as described here reflects EU and UK data protection law; requirements differ in other jurisdictions and should be checked against local rules.
Product managers, engineers, and system designers
Because the standard requires data protection to be built in from the outset through technology and process design, those making architecture, feature, and default-setting decisions are central to compliance. Choices about how much data a system collects, how long it retains data, and who can access it directly affect whether the by-default expectation is met.
Data protection officers and privacy teams
Those responsible for privacy governance need to translate the design and default requirements into repeatable processes and to document how measures were chosen and applied. They should distinguish the binding legal obligation from the broader voluntary privacy engineering framework of the same name, and verify interpretation against current supervisory authority guidance.
Compliance and legal counsel
Advisers assessing an organisation's exposure should treat the requirement as an accountability obligation that can be relevant independent of any data breach. Because what counts as appropriate measures is fact-specific and enforcement practice continues to evolve, application to particular circumstances requires professional judgement against the authoritative regulatory text.

Inside PbD

Data protection by design
The principle that data protection measures should be embedded into the design of processing activities, systems, and business practices from the outset rather than added later. Under the GDPR, this is a binding obligation on controllers, and the measures expected are generally scaled to the nature, scope, context, and purposes of processing as well as the risks to individuals.
Data protection by default
The principle that, by default, only personal data necessary for each specific purpose of processing should be processed. This generally applies to the amount of data collected, the extent of processing, the retention period, and accessibility, meaning the most privacy-protective settings should apply without requiring action from the individual.
Data minimisation
A component closely tied to processing by default, under which the categories and volume of personal data are limited to what is adequate, relevant, and necessary for the stated purpose. It is not the same as anonymisation and does not by itself remove data from the scope of applicable law.
Technical and organisational measures
The combination of technical controls (such as pseudonymisation or access restrictions) and organisational controls (such as policies and internal procedures) used to give effect to the principles. The specific measures are not prescribed exhaustively in the text and are expected to reflect the state of the art, cost of implementation, and the risks involved.
Risk-based and lifecycle application
The expectation that the principles are applied both at the time of determining the means of processing and during the processing itself, with the intensity of measures generally calibrated to the level of risk to the rights and freedoms of individuals.

Common questions

Answers to the questions practitioners most commonly ask about PbD.

Is Privacy by Design just a best-practice framework, or is it legally required?
It is not merely a voluntary framework in every jurisdiction. In the EU, data protection by design and by default is a binding legal obligation under the GDPR, applying to controllers within its material and territorial scope. Outside that context—for example where the GDPR does not apply—the underlying concept may function as a voluntary best practice or a contractual expectation rather than a legal mandate. The distinction depends on which jurisdiction and legal instrument governs the processing, so verify the applicable law and its current text before treating the principle as either binding or optional in a given case.
Doesn't 'Privacy by Design' mean the same thing as strong security or encryption?
No. Privacy and security are related but distinct. Privacy by Design concerns embedding data protection principles—such as data minimisation, purpose limitation, and appropriate handling of personal data—into systems and processes from the outset. Security measures like encryption may support those aims but are only one component. A system can be highly secure yet still collect or retain more personal data than necessary, which would not satisfy the privacy-by-design and by-default expectations. Treating the two as interchangeable risks overlooking the broader data protection principles the concept is meant to operationalise.
At what stage of a project should Privacy by Design be applied?
The principle generally contemplates that data protection considerations are addressed from the earliest design stages and throughout the lifecycle of a system, product, or processing activity, rather than retrofitted afterward. In practice this typically means considering privacy at the point of specifying requirements, selecting technologies, and defining default configurations. Because application is fact-specific and depends on the nature and risk of the processing, the appropriate timing and depth of measures should be assessed case by case and, where required, documented.
How does 'by default' differ from 'by design' in practical terms?
'By design' refers to building data protection measures into the design of processing systems and practices. 'By default' generally addresses the out-of-the-box configuration: that, absent an individual's active choice, only personal data necessary for a specific purpose is processed. In practical terms, 'by default' tends to influence settings such as what data is collected, how long it is retained, and who can access it, so that the most privacy-protective option applies unless a user or authorised process changes it. The precise expectations depend on the applicable legal text, which should be verified.
Can a Data Protection Impact Assessment help demonstrate Privacy by Design?
In many cases a documented assessment of privacy risks—such as a DPIA where one is required or appropriate—can support an organisation's ability to show that data protection considerations were embedded into a project. However, an assessment is a distinct exercise from the design measures themselves and does not by itself satisfy the obligation. Whether a formal assessment is required depends on the risk level of the processing and the applicable law. Organisations should confirm the current requirements and thresholds against the relevant official text.
How can an organisation evidence that it has applied Privacy by Design and by Default?
Because these expectations often form part of broader accountability obligations, organisations generally maintain documentation showing how data protection considerations were built into systems and default settings—for example records of design decisions, configuration choices, data minimisation measures, and risk assessments. The specific evidence that is adequate is fact-specific and may depend on the size of the organisation, the sensitivity of the data, and the applicable jurisdiction. This entry is informational and does not substitute for professional judgement applied to particular circumstances; verify requirements against the current authoritative source.

Common misconceptions

Privacy by Design is a voluntary best practice or standard that organisations may adopt at their discretion.
Within the scope of the GDPR, data protection by design and by default is a binding legal obligation on controllers, not merely a voluntary framework. The underlying concept predates and is broader than the GDPR, but its status as an enforceable requirement depends on the applicable jurisdiction; readers should verify how it is treated under the law that governs them.
Achieving Privacy by Design means the same thing in every jurisdiction.
The obligation as codified applies to processing within the scope of the EU GDPR and, through its extraterritorial reach, to certain controllers established outside the EU. Other jurisdictions, such as the United States or the United Kingdom, may reflect similar concepts differently or through different instruments, so the specific requirements are not universal.
Once systems are built with privacy features, the by design and by default requirement is satisfied permanently.
The principles are generally understood to apply across the processing lifecycle, not only at the design stage. What counts as adequate can also shift as the state of the art, risks, and authoritative interpretations evolve, so measures may need periodic review rather than being treated as a one-time exercise.

Best practices

Address data protection considerations at the earliest design stage of new systems, products, or processing activities, and document the choices made and their rationale.
Apply data minimisation by default so that only personal data necessary for each specific purpose is collected, processed, retained, and made accessible, and configure the most protective settings as the standard.
Calibrate technical and organisational measures to the risks to individuals, taking into account factors such as the nature and sensitivity of the data and the state of the art, rather than applying a uniform approach.
Review and update measures periodically to reflect changes in processing, risk, technology, and evolving regulatory interpretation, treating compliance as ongoing rather than a fixed milestone.
Verify the specific obligations against the current authoritative text applicable to your jurisdiction, since requirements and their enforcement differ across the EU, the United States, the United Kingdom, and elsewhere.
Engage relevant roles such as data protection specialists and, where applicable, coordinate with the controller or processor responsibilities, and seek professional judgement for how the principles apply to particular circumstances.
Promotional banner for the Pentest Readiness checklist download