Skip to main content
Category: Consent Principles

Data Protection by Default

Also known as: Privacy by Default
Simply put

Data protection by default means that when a product or service is set up, the settings should automatically protect people's personal data without the user having to change anything. For example, features such as automatic opt-ins should not be switched on by default, and only the personal data actually needed should be processed. The goal is to give users the highest privacy protection as the starting point.

Formal definition

Data protection by default is an obligation under the EU General Data Protection Regulation requiring organisations to implement appropriate technical and organisational measures ensuring that, by default, only personal data necessary for each specific purpose of processing is processed. Regulatory guidance emphasises applying default settings that favour privacy, such as not enabling automatic opt-ins on customer account pages and putting safeguards in place to prevent personal data being made available to an indefinite number of people without the individual's intervention. It is a companion obligation to data protection by design and is widely regarded as one of the core accountability principles of the GDPR. The precise measures required are fact-specific and depend on the nature, scope, context, and purposes of the processing; this definition addresses the principle generally under EU (and UK GDPR) frameworks and does not resolve how it applies to any particular processing activity or non-EU regime.

Why it matters

Data protection by default shapes the baseline experience that every user encounters before they make any active choice. Because most people never change default settings, the configuration an organisation ships with often determines how much personal data is actually collected and shared. Under the GDPR, this is not merely good practice but a legal obligation: by default, only the personal data necessary for each specific purpose should be processed, and safeguards must be in place to prevent personal data being made available to an indefinite number of people without the individual's intervention. In the cookie consent context, this principle directly informs why practices such as automatic opt-ins, for example pre-enabled analytics or advertising cookies, or pre-ticked boxes on account pages, are widely regarded as problematic in EU and UK GDPR frameworks.

For teams designing consent interfaces, the principle raises the stakes on how banners, preference centres, and account settings are constructed. A cookie banner that treats non-essential cookies as enabled until a user opts out sits in tension with data protection by default, because the privacy-protective option is not the starting point. Regulatory guidance across EU authorities emphasises that default settings should favour privacy, meaning the burden should not fall on users to hunt for and disable data-hungry features.

It is important to recognise that data protection by default is a companion obligation to data protection by design and is regarded as one of the core accountability principles of the GDPR, but the precise measures required are fact-specific. This definition addresses the principle generally under EU and UK GDPR frameworks and does not resolve how it applies to any particular processing activity or to non-EU regimes, which may take different approaches, such as opt-out models under some US state privacy laws.

Who it's relevant to

Privacy officers and data protection professionals
Data protection by default is one of the core accountability obligations under the GDPR, so DPOs and privacy teams must be able to demonstrate that default settings across products and services favour privacy and process only the data necessary for each purpose. This includes reviewing whether cookie banners and account settings avoid automatic opt-ins and prevent personal data being exposed to an indefinite number of people without the individual's intervention.
Web developers and product designers
Because defaults are configured in the product itself, developers and designers translate the principle into concrete settings, ensuring, for example, that non-essential cookies are not pre-enabled and that pre-ticked boxes are not used on customer account pages. The appropriate configuration is fact-specific, so developers generally work alongside legal and privacy teams rather than applying a fixed template.
Legal counsel and compliance teams
Counsel advises on how data protection by default interacts with data protection by design and with cookie consent requirements under EU and UK GDPR frameworks. They help determine what data is genuinely necessary for each purpose and flag that requirements differ across jurisdictions, including opt-out-based approaches under some US state privacy laws, so that default settings are assessed against the applicable regime rather than assumed to be universally compliant.
Marketing and analytics teams
Marketing and analytics functions often rely on data collection that, under EU and UK GDPR frameworks, cannot simply be switched on by default. This principle constrains practices such as pre-enabled advertising or analytics cookies, meaning these teams need to build campaigns and measurement on a privacy-protective baseline and obtain valid consent where required rather than defaulting users into data processing.

Inside Data Protection by Default

Privacy-protective default settings
The principle that, by default, only personal data necessary for each specific purpose of processing is processed. Applied to cookies, this generally means that non-essential cookies (such as analytics, advertising, and functional cookies) should not be set before the user provides a clear affirmative action, in most EU jurisdictions.
Legal basis in the GDPR
Data protection by default is an obligation under the GDPR aimed at controllers, requiring them to implement appropriate technical and organizational measures so that default processing minimizes data use. It operates alongside, but is distinct from, the ePrivacy rules that govern the initial placing of or access to cookies and similar technologies on a user's device.
Scope of processing controlled by default
The obligation extends to the amount of personal data collected, the extent of processing, the period of storage, and accessibility. In a consent management context this can influence default cookie durations, the categories of trackers pre-loaded, and whether data is shared with third parties absent user choice.
Relationship to the consent interface
Data protection by default informs how consent banners and consent management platforms (CMPs) are configured. For example, pre-ticked boxes and toggles set to 'on' for non-essential cookies are widely considered inconsistent with both valid consent and the default-minimization expectation in the EU.
Distinction from data protection by design
By design concerns embedding data protection considerations throughout the development of processing systems, while by default concerns the specific configuration that applies absent any user intervention. The two are related obligations but address different stages and questions.

Common questions

Answers to the questions practitioners most commonly ask about Data Protection by Default.

Does data protection by default mean I can pre-tick consent boxes as long as users can change them later?
No. Data protection by default requires that, without any user intervention, only the personal data necessary for a specific purpose is processed. This principle points in the opposite direction from pre-ticked boxes. Under the GDPR, valid consent must be freely given, specific, informed, and unambiguous, requiring a clear affirmative action, and pre-ticked boxes are widely regarded as non-compliant in the EU. Applied to cookies, the default state should be that non-essential cookies (such as analytics or advertising cookies) are not set until the user actively opts in. The ability to change a setting later does not cure a default that processes more data than necessary from the outset.
Is data protection by default the same thing as data protection by design?
They are related but distinct obligations under the GDPR, and they are often confused. Data protection by design concerns building appropriate technical and organizational measures into processing activities throughout their lifecycle. Data protection by default concerns ensuring that, as a starting state, only personal data necessary for each specific purpose is processed, without requiring action from the user. In a cookie context, by design might involve architecting a consent management platform (CMP) to capture and log choices reliably, while by default means the CMP's initial state does not set non-essential cookies before consent. This distinction reflects the EU legal framework; other jurisdictions may frame these concepts differently or not use them at all.
How should the default state of a consent banner be configured to reflect this principle?
In most EU jurisdictions, the default state should be that non-essential cookies and similar technologies (including pixels, local storage, SDKs, and fingerprinting techniques, which fall within the same rules) are not active until the user provides valid consent. Toggles for optional categories such as analytics, advertising, and functional cookies should generally be off by default, and there should be no reliance on implied consent from continued browsing. Strictly necessary or essential cookies are generally exempt from consent and may be set by default. This describes the general EU expectation; requirements differ under frameworks such as US state privacy laws, which often rely on opt-out rather than opt-in, so the appropriate default configuration may vary by the jurisdictions you serve.
What settings beyond cookie toggles should default to the most privacy-protective option?
The principle extends to the amount of data collected, the extent of processing, the retention period, and accessibility of the data. In practice this can mean defaulting to the shortest workable retention period, limiting the scope of data shared with third parties absent consent, minimizing the categories of data collected for each purpose, and not making personal data accessible to an indefinite number of people without the individual's intervention. How each of these applies depends on the specific processing purpose and facts not covered by a general definition, so a per-purpose assessment is typically needed.
How can I demonstrate that our defaults comply with this obligation?
Documentation is central. Organizations typically record the default configuration of their consent tooling, the rationale for which cookies are treated as strictly necessary, and evidence of consent choices through consent logging. Consent management platforms can support this record-keeping, but tools support compliance rather than guaranteeing it, and they do not replace legal judgment. Because enforcement positions and data protection authority guidance evolve, maintaining an auditable record of your defaults and the reasoning behind them is generally advisable, though the precise expectations can differ between the EU, the UK, and other regimes.
Does this principle apply to third-party tags and SDKs that we do not directly control?
The obligation applies to the controller's processing regardless of whether cookies are set by first-party or third-party technologies, and it covers technologies beyond literal cookies, such as pixels, SDKs, local storage, and fingerprinting. In practice this typically means preventing third-party tags from firing until valid consent is obtained, for example through tag management or CMP integration. The allocation of responsibility between your organization and third parties depends on the specific relationship and facts, and contested questions can arise about who is the controller for a given processing activity; those determinations fall outside a general definition and warrant a case-specific assessment.

Common misconceptions

Data protection by default means you can load non-essential cookies as long as users can later turn them off.
In most EU jurisdictions the default state should minimize processing, which generally means non-essential cookies are not set until the user gives a clear affirmative action. Relying on an after-the-fact opt-out for cookies requiring prior consent is widely regarded as non-compliant under EU law, though opt-out approaches may apply under some US state frameworks.
Satisfying data protection by default under the GDPR also satisfies the cookie rules.
The GDPR default-minimization obligation and the ePrivacy rules on placing or accessing information on a device are separate. Meeting one does not automatically satisfy the other; the initial setting of cookies typically engages ePrivacy consent requirements independently of GDPR obligations.
Configuring a CMP with privacy-friendly defaults guarantees compliance with the by-default obligation.
A CMP can support compliant defaults, but it does not replace legal judgment. Whether a configuration meets the obligation depends on the specific cookies, purposes, jurisdictions, and how consent is captured and honored, which must be assessed on the facts.

Best practices

Configure consent interfaces and CMPs so that non-essential cookies are not set before a user provides a clear affirmative action, avoiding pre-ticked boxes or toggles defaulted to 'on' in EU-facing contexts.
Assess the ePrivacy consent requirements for placing cookies separately from the GDPR default-minimization obligation, rather than assuming compliance with one covers the other.
Limit default processing to what is necessary for each specific purpose, reviewing cookie categories, storage durations, and third-party sharing to confirm they reflect minimized defaults.
Document the geographic and legal scope of your default settings, recognizing that expectations differ between the EU, the UK, and individual US states, and adjust configurations accordingly.
Treat CMP configuration as a tool that supports compliance, and pair it with legal review of the specific cookies, purposes, and jurisdictions involved.
Periodically re-examine default settings against evolving data protection authority guidance, and flag any contested interpretations for legal assessment rather than assuming a fixed answer.