Skip to main content
DataRidge
Category: Privacy Principles

Data Protection by Design and by Default

Also known as: DPbDD, Privacy by Design, Data Protection through Technology Design
Simply put

Data protection by design and by default means building privacy considerations into systems, products, and processes from the outset rather than adding them later. By design, an organisation embeds data protection measures throughout the lifecycle of a project; by default, it limits the use of personal information to only what is necessary for each specific purpose. It is a way of making sure protective choices are the standard, not something individuals have to opt into.

Formal definition

Under the EU GDPR and the UK GDPR (originating in Article 25 GDPR), data protection by design and by default is an obligation on the controller to implement appropriate technical and organisational measures both at the time of determining the means of processing and during the processing itself. The 'by design' element requires that data protection principles be integrated into processing activities through measures such as those addressing data minimisation. The 'by default' element requires that only personal data necessary for each specific purpose be processed, and, per Article 25, that by default personal data are not made accessible without the individual's intervention to an indefinite number of persons. The obligation rests with the controller; it is generally treated as a demonstrable accountability requirement rather than a stated intention, and its concrete application depends on the state of the art, cost of implementation, and the nature, scope, context, and purposes of processing. Analogous requirements apply to processing for law enforcement purposes under the applicable law enforcement processing regime, where such measures must likewise be implemented by default. Note that DPbDD is distinct from, though it may draw on, information security controls; it is a governance and design obligation and does not by itself establish a lawful basis, satisfy transfer requirements, or determine retention periods. This entry does not address enforcement penalties, cross-border transfer mechanics, or the differing treatment of these concepts under regimes such as the CCPA and CPRA, HIPAA, ISO/IEC 27701, or the NIST Privacy Framework.

Why it matters

Data protection by design and by default reframes privacy from a feature bolted on late in development into a structural obligation that shapes how systems and processes are conceived. Under the EU GDPR and the UK GDPR, this is not aspirational guidance but a controller obligation originating in Article 25, and it is generally treated as a demonstrable accountability requirement. That distinction matters to practitioners: a stated commitment to privacy is insufficient, because the controller must be able to evidence the technical and organisational measures actually implemented, both when the means of processing are determined and during processing itself.

Who it's relevant to

Data controllers
The Article 25 obligation rests specifically with the controller, which determines the means of processing. Controllers must implement and be able to demonstrate appropriate technical and organisational measures both at the point of designing processing and throughout it. This is a demonstrable accountability requirement, not a matter of stated intention, so controllers should retain evidence of the design choices and default settings adopted.
Privacy engineers and product teams
Because 'by design' means embedding data protection measures such as data minimisation into systems from the outset, engineering and product teams translate the obligation into concrete configuration, default settings, and lifecycle decisions. DPbDD is distinct from information security controls, though it may draw on them; teams should treat it as a governance and design obligation rather than assume that security measures alone satisfy it.
Data protection officers and governance leads
DPbDD sits within accountability and governance, so DPOs and governance leads are typically involved in ensuring the obligation is evidenced and applied proportionately to the nature, scope, context, and purposes of processing. They should note that DPbDD does not by itself establish a lawful basis, satisfy transfer requirements, or determine retention periods, and so must be addressed alongside those separate obligations.
Teams handling law enforcement processing
Where personal data are processed for law enforcement purposes, analogous requirements apply under the applicable law enforcement processing regime, and such measures must likewise be implemented by default. Teams operating in this context should confirm the specific requirements of that regime rather than assuming the general GDPR treatment applies unchanged.

Inside DPbDD

Data protection by design
The obligation, originating in the EU GDPR and mirrored in the UK GDPR, to integrate data protection measures into processing activities from the outset rather than adding them afterward. It requires that technical and organisational measures be considered at the point of determining the means of processing and throughout the processing lifecycle.
Data protection by default
The requirement that, by default, only personal data necessary for each specific purpose of processing is processed. This generally applies to the amount of data collected, the extent of processing, the retention period, and accessibility, favouring the most privacy-protective settings unless a subject actively changes them.
Technical and organisational measures
The combined set of controls used to give effect to these principles. Technical measures may include pseudonymisation and data minimisation, while organisational measures include policies, roles, and procedures. Pseudonymisation is cited as an example but, being reversible, does not render data non-personal.
Data minimisation
Limiting collection and processing to what is adequate, relevant, and necessary for the stated purpose. Data protection by default operationalises this principle by making minimal processing the standard configuration rather than an optional adjustment.
Controller accountability
Under the EU and UK GDPR these obligations fall primarily on the data controller, which determines the purposes and means of processing. The controller must be able to demonstrate that design and default measures were implemented; accountability requires demonstrable evidence, not merely stated intent.
Contextual factors
The appropriateness of measures is assessed against factors typically including the state of the art, cost of implementation, and the nature, scope, context, and purposes of processing, alongside the risks to the rights and freedoms of individuals.

Common questions

Answers to the questions practitioners most commonly ask about DPbDD.

Is data protection by design and by default just a matter of encrypting data or applying strong security controls?
No. This is a frequent conflation of governance-and-privacy obligations with information security controls. Data protection by design encompasses the whole processing lifecycle, including lawful basis, purpose limitation, data minimisation, transparency, and the rights of data subjects, not only confidentiality, integrity, and availability. Security measures such as encryption are one possible technical measure among many, and applying them does not by itself satisfy the principle. Importantly, encrypting or tokenising personal data does not make it non-personal, so security controls cannot substitute for the broader design and default obligations.
Does implementing data protection by design and by default guarantee compliance with the applicable regime?
No single control, mechanism, or design decision guarantees compliance. Data protection by design and by default is an ongoing obligation that must be assessed in context, and its adequacy depends on the nature, scope, purpose, and risks of the specific processing, as well as the jurisdiction. Under accountability-based frameworks, the party responsible generally must be able to demonstrate through evidence that appropriate measures were considered and implemented; stated intent alone is not sufficient. It should also be read alongside, not in place of, other obligations.
Which party bears responsibility for implementing data protection by design and by default?
Under the regime where this obligation is most explicitly articulated, it generally falls on the controller, who determines the purposes and means of processing and is therefore positioned to build protective measures into those means from the outset. Processors typically support the controller by offering functionality and configurations that enable compliant processing, but the controller retains primary accountability. Treatment and precise allocation of responsibility can differ across regimes, so the applicable instrument should be consulted. This entry does not address the detailed contractual arrangements between controllers and processors.
At what point in a project should data protection by design and by default be applied?
The principle is generally intended to apply from the earliest stages, including at the time the means of processing are determined, and to continue throughout the processing itself rather than being added retrospectively. In practice this typically means considering privacy and data protection during requirements gathering, system architecture, and configuration decisions, and revisiting those decisions as the processing evolves. This entry does not prescribe a specific project methodology or set retention timelines, which depend on separate obligations and organisational context.
How does data protection by default translate into concrete configuration choices?
By default generally means that, without additional intervention by the data subject, processing is limited to what is necessary for each specific purpose. This can inform choices such as the volume of personal data collected, the extent of processing, retention periods, and accessibility, so that the most protective settings apply as a starting point. The specific configurations that are appropriate depend on the processing context and risk. This entry does not set fixed default values or cover retention rules in detail, which must be determined against the applicable requirements.
What evidence should an organisation maintain to demonstrate data protection by design and by default?
Because accountability under governance and privacy frameworks generally requires demonstrable evidence rather than stated intent, organisations typically retain documentation of the design decisions taken, the measures considered and adopted, and the reasoning behind them. Depending on the processing and its risks, this may connect to broader assessments of impact, though such assessments are not always mandatory in every case. This entry does not detail specific documentation formats, records of processing obligations, or the circumstances that trigger a formal impact assessment, which are addressed separately.

Common misconceptions

Data protection by design is a purely technical or engineering requirement satisfied by adding encryption or security controls.
It is a governance and accountability obligation encompassing both technical and organisational measures, and it belongs to the data protection domain rather than being reducible to information security. Encryption or tokenisation may support it but do not by themselves make data non-personal or satisfy the principle.
Adopting these principles guarantees compliance with the GDPR.
No single measure or design approach guarantees compliance. The adequacy of measures depends on context, jurisdiction, and implementation, and must be assessed against factors such as the nature and risks of the processing. These principles are one component of a broader accountability framework.
Data protection by design and by default is a universal standard applying identically across all privacy regimes.
As framed here the concept originates in the EU GDPR and is mirrored in the UK GDPR. Other regimes, such as the CCPA and CPRA, HIPAA, ISO/IEC 27701, or the NIST Privacy Framework, may address related ideas differently, and treatment should not be assumed to be interchangeable.

Best practices

Embed data protection considerations at the design stage of any new system, product, or processing activity rather than retrofitting controls after deployment.
Configure systems so that the most privacy-protective settings apply by default, limiting the volume of data collected, the extent of processing, the retention period, and accessibility to what is necessary for each purpose.
Combine technical measures such as pseudonymisation and data minimisation with organisational measures such as policies and defined roles, and remember that pseudonymised data generally remains personal data.
Maintain demonstrable evidence that design and default measures were considered and implemented, since controller accountability requires documentation rather than stated intent alone.
Assess the appropriateness of measures against the state of the art, implementation cost, and the nature, scope, context, purposes, and risks of the processing, revisiting this assessment as circumstances change.
Where processing spans multiple jurisdictions, verify how each applicable regime treats these principles rather than assuming the EU or UK GDPR framing applies universally.