Skip to main content
Cookie Gate
Category: Consent Principles

Data Protection by Design

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

Data protection by design means thinking about privacy and data protection from the very start when building any system, service, product or process, rather than adding safeguards afterwards. In practice, it involves embedding privacy features and privacy-enhancing technologies directly into a project at an early stage. A related concept, data protection by default, means configuring settings so that the most privacy-protective options apply automatically.

Formal definition

Data protection by design is an approach requiring controllers to consider and integrate data protection and privacy measures into the design of systems, services, products or processes from the earliest stage of development and throughout their lifecycle. Under EU and UK GDPR frameworks, it operates alongside data protection by default, which requires that appropriate technical and organizational measures be implemented so that, by default, only personal data necessary for each specific purpose is processed. According to guidance from authorities such as the ICO and the Irish Data Protection Commission, this can involve embedding privacy-enhancing technologies and intentional design choices, and applies across contexts including law enforcement processing where such measures must be implemented by default. The precise measures required are fact-specific and depend on factors such as the nature, scope, context and purposes of processing; this definition does not enumerate those measures, and the concept does not by itself guarantee compliance with any particular obligation.

Why it matters

Data protection by design shifts the point at which privacy is considered from the end of a project to its very beginning. For cookie consent and tracking technologies specifically, this means that decisions about what data a website or app collects, how consent is captured, and which settings apply by default should be built into the design of a system rather than retrofitted after launch. Under EU and UK GDPR frameworks, this is not merely good practice but a recognised approach that controllers are expected to adopt, and guidance from authorities such as the ICO and the Irish Data Protection Commission reflects its importance across a range of processing contexts.

The practical significance is that a system designed without privacy in mind often forces uncomfortable choices later: consent banners bolted on after the fact, tracking that defaults to on, or configurations that collect more personal data than a specific purpose requires. Data protection by default addresses the last of these by requiring that, by default, only the personal data necessary for each specific purpose is processed. For teams building consent management interfaces or tag configurations, embedding privacy-enhancing technologies and intentional design choices early can reduce the risk of non-compliant defaults and make it easier to honour the standards for valid consent that apply in most EU jurisdictions.

It is important to be clear about the limits of the concept. Data protection by design does not, by itself, guarantee compliance with any particular obligation, and the specific measures required are fact-specific, depending on factors such as the nature, scope, context and purposes of processing. It is an approach and a governance expectation rather than a checklist, and legal judgement remains necessary to determine what is adequate in a given situation.

Who it's relevant to

Privacy officers and data protection professionals
Those responsible for accountability and governance need to ensure that data protection by design and by default is reflected in how systems are built and configured. This includes verifying that default settings limit processing to what is necessary for each specific purpose and documenting the design decisions made, while recognising that the appropriate measures are fact-specific rather than universal.
Web developers and product teams
Developers building consent interfaces, tag management setups and data collection features are often best placed to embed privacy-enhancing technologies and intentional design choices at an early stage. Considering privacy at the design stage, rather than retrofitting safeguards later, aligns technical implementation with the by-design and by-default approach.
Legal counsel and compliance teams
Legal and compliance staff advise on how data protection by design intersects with EU and UK GDPR obligations and, where relevant, other regimes. Because the concept does not by itself guarantee compliance and the required measures depend on context, legal judgement remains essential when assessing whether a given design meets applicable standards.
Teams handling law enforcement processing
For organisations processing personal data for law enforcement purposes, guidance from authorities such as the ICO indicates that data protection by design and by default measures must be implemented by default. Teams in this context should treat privacy-protective defaults as an expected baseline rather than an optional enhancement.

Inside DPbD

Proactive integration of privacy
Data protection by design requires embedding privacy considerations into systems, processes, and technologies from the outset rather than adding them after deployment. In the cookie context, this means considering consent mechanisms and tracking behaviour during the design of a website or application, not retrofitting them once tracking is already live.
Article 25 GDPR foundation
The concept is codified in Article 25 of the GDPR, which requires controllers to implement appropriate technical and organisational measures. It applies to the processing of personal data that may follow the placing of or access to cookies. Note that the placing of and access to information on a device is separately governed by the ePrivacy Directive and its national implementations, so design obligations arise under both regimes.
Data protection by default
A closely related requirement under Article 25 that, by default, only personal data necessary for a specific purpose should be processed. Applied to cookies, this generally implies that non-essential cookies (such as analytics and advertising cookies) should not be set before the user provides valid consent, and that no consent should be pre-selected.
Technical measures
Includes configuring consent management platforms (CMPs), suppressing non-essential tags and scripts until consent is obtained, honouring signals such as Global Privacy Control where applicable, and applying data minimisation to what is collected. These measures support compliance but do not by themselves guarantee it.
Organisational measures
Includes internal policies, staff responsibilities, documentation of design decisions, and consent logging or record-keeping practices that demonstrate how privacy was built into the processing. The specific record-keeping obligations depend on the applicable legal regime.
Scope and applicability
The design obligation under GDPR applies where personal data is processed. Cookie consent requirements themselves vary between the EU, the UK, and individual US states such as under the CCPA and CPRA in California, which often rely on opt-out rather than opt-in. Design choices should therefore reflect the jurisdictions in which a service operates.

Common questions

Answers to the questions practitioners most commonly ask about DPbD.

Does using a consent management platform (CMP) mean I have satisfied data protection by design?
No. A CMP is a tool that can support data protection by design, but deploying one does not by itself satisfy the principle. Data protection by design, as reflected in the GDPR, is an organizational and technical obligation that requires embedding data protection considerations into the design of processing activities and systems, supported by appropriate measures and documented decision-making. A CMP may help operationalize consent collection, logging, and preference management, but its mere presence does not replace the legal judgment, configuration choices, and ongoing governance needed. Tools support compliance; they do not guarantee it.
Is data protection by design just a technical task for developers?
Not solely. While technical measures are an important part, data protection by design under the GDPR encompasses both technical and organizational measures. It typically involves legal, compliance, product, and engineering roles working together, and applies from the earliest planning stages of a processing activity through its lifecycle. Treating it as only a developer concern risks overlooking organizational elements such as governance, documentation, policies, and decisions about purpose and necessity. The scope of what counts as an appropriate measure can depend on facts specific to the processing, so this is not a purely technical checklist.
At what stage should data protection by design be considered when planning a cookie or tracking implementation?
It should generally be considered from the earliest design stage, before processing begins, and revisited throughout the lifecycle of the processing. In the context of cookies and similar technologies, this typically means addressing questions of necessity, categorization, and consent architecture during planning rather than retrofitting them after deployment. The specific measures that are appropriate depend on the nature, scope, context, and purposes of the processing, so the analysis is fact-dependent rather than one-size-fits-all.
How does data protection by design relate to how default cookie settings are configured?
Data protection by design is closely connected to default settings, which the GDPR addresses through the related concept of data protection by default. In practice this generally means that non-essential cookies and similar technologies should not be set before a user provides valid consent where such consent is required, and that defaults should favor the more privacy-protective option. In most EU jurisdictions, pre-ticked boxes and pre-enabled non-essential trackers are widely regarded as inconsistent with valid consent. The precise expectations can vary by jurisdiction and evolving regulatory guidance.
What kinds of documentation help demonstrate data protection by design for a consent setup?
Documentation typically helps demonstrate that data protection considerations were built into the design and that appropriate measures were chosen. This may include records of decisions about which cookies and technologies are used and why, the basis for categorizing cookies as strictly necessary versus requiring consent, consent logging and record-keeping, and, where relevant, data protection impact assessments. What is appropriate depends on the specific processing, and the existence of documentation supports but does not by itself establish compliance. Whether a particular set of records is sufficient is a matter that depends on facts outside the scope of this definition.
Does data protection by design apply to technologies other than cookies, such as pixels, SDKs, or fingerprinting?
Yes. Data protection by design applies to processing activities generally, not only to cookies. Where similar technologies such as tracking pixels, local storage, mobile SDKs, or fingerprinting are used to store or access information on a device or to process personal data, the same design considerations generally apply. Note that the rules governing the placing of and access to information on a device derive from the ePrivacy regime, while the processing of any resulting personal data is governed by the GDPR; data protection by design is a GDPR principle and should be considered alongside those ePrivacy obligations rather than in place of them.

Common misconceptions

Data protection by design only requires action once a product is finished or once a complaint is received.
The concept is inherently proactive. Article 25 GDPR contemplates privacy being considered at the design stage and throughout the processing lifecycle, not solely as a reactive fix. Waiting until deployment or a complaint generally undermines the purpose of the requirement.
Deploying a consent management platform or a certified tool satisfies data protection by design automatically.
Tools such as CMPs and frameworks like the IAB TCF can support compliance, but they do not replace legal judgment or guarantee compliance. Design by default still requires that non-essential cookies not fire before valid consent and that configuration reflects the applicable legal scope.
Because the GDPR governs personal data, satisfying data protection by design also satisfies the rules on placing cookies.
The placing of and access to information on a user's device is governed by the ePrivacy Directive and its national implementations, while the GDPR governs any personal data processing that follows. Design measures should address both; meeting one does not automatically satisfy the other.

Best practices

Consider consent mechanisms and tracking behaviour during the design phase of a site or application, rather than retrofitting them after non-essential cookies are already live.
Configure systems so that non-essential cookies (such as analytics and advertising cookies) and similar technologies like pixels, local storage, and SDKs do not fire before valid consent is obtained in jurisdictions requiring prior opt-in.
Avoid pre-ticked boxes, implied consent from continued browsing, and cookie walls in EU-facing designs, since these are widely considered non-compliant under GDPR consent standards.
Apply data minimisation by default, collecting and processing only the personal data necessary for each specified purpose.
Map the jurisdictions in which the service operates and reflect their differing requirements in the design, recognising that EU, UK, and US state regimes such as the CCPA and CPRA differ, including opt-out versus opt-in models and signals like Global Privacy Control.
Document design decisions and maintain consent logging or record-keeping to demonstrate how privacy was built into the processing, while treating tools as support for, not a substitute for, legal judgment.