Data Protection by Design and by Default: A Practical Guide to GDPR Article 25

GDPR Article 25 places a single, non-negotiable obligation on every data controller: privacy must be embedded into the architecture of your systems before any personal data is processed. Not after launch. Not after a complaint. Before.

The concept is split into two parts. Data protection by design means implementing technical and organisational measures - such as pseudonymisation, encryption, and access controls - that enforce data protection principles throughout the processing lifecycle. Data protection by default means that the strictest privacy settings apply automatically, without requiring the user to take any action. Only the personal data necessary for each specific purpose should be processed, and it should not be made accessible to an indefinite number of people without the individual's intervention.

These are not aspirational guidelines. They carry fines of up to 10 million euros or 2% of global annual turnover under Article 83(4) GDPR, and regulators have shown increasing willingness to enforce them.

What Article 25 Actually Says

Article 25(1) requires controllers to implement appropriate technical and organisational measures designed to implement data protection principles - like data minimisation and purpose limitation - in an effective manner. The GDPR specifies that controllers must consider the state of the art, the cost of implementation, the nature, scope, context, and purposes of processing, and the risks to individuals' rights and freedoms. This assessment applies both at the time of determining the means for processing and at the time of the processing itself.

Article 25(2) addresses defaults specifically. Controllers must ensure that, by default, only personal data which is necessary for each specific purpose is processed. That obligation covers the amount of personal data collected, the extent of processing, the period of storage, and accessibility. Personal data must not be made accessible to an indefinite number of people without the individual's intervention.

Article 25(3) adds that an approved certification mechanism under Article 42 can serve as evidence of compliance - though no such certification for Article 25 specifically has achieved wide adoption yet.

Recital 78 expands on this. It encourages producers of products, services, and applications to factor in the right to data protection when developing and designing their offerings. This is notable because Article 25 itself only binds controllers, not product manufacturers. But the EDPB's Guidelines 4/2019 on Article 25 (adopted in final form in October 2020) make clear that controllers who choose products that do not support data protection by design may need to take additional steps to achieve compliance.

How Regulators Interpret and Enforce Article 25

A 2024 report by the Future of Privacy Forum analysed more than 92 DPA enforcement cases, court rulings, and guidelines from 16 EEA member states, the UK, and the EDPB. The findings reveal significant divergence in how national authorities approach Article 25.

Some DPAs treat Article 25 as a preventive obligation - they will find a violation even before an actual data breach or rights infringement occurs, simply because the controller failed to implement adequate safeguards at the design stage. Other authorities are more reluctant to issue fines for Article 25 alone, preferring to cite it alongside substantive breaches of other GDPR provisions like Article 5 (data protection principles) or Article 32 (security of processing).

The enforcement numbers are real. The Irish Data Protection Commission fined Meta 251 million euros in December 2024 for a 2018 Facebook breach that affected 29 million users globally. The DPC specifically cited failures under Article 25 - the company had not implemented privacy by design and default measures that could have prevented the breach. Poland's data protection authority (UODO) fined McDonald's Polska over 4 million euros in 2025 for multiple violations that included Article 25(1). The Sambla Group received a 950,000 euro fine in 2025 specifically for Article 25 failures - the authority found that data protection measures were missing from the system's outset and that deficiencies went unresolved for years.

Cumulative GDPR fines reached approximately 5.65 billion euros by March 2025 according to the CMS GDPR Enforcement Tracker Report, with 2,245 publicly recorded fines across Europe. Article 25 violations increasingly appear as part of multi-article enforcement actions, particularly when DPAs investigate data breaches and find that the underlying cause was a failure to build in protections from the start.

The Seven Principles You Must Design For

The EDPB's Guidelines 4/2019 map Article 25 directly to the data protection principles in Article 5 GDPR. Your systems must implement all of them - not selectively, and not on paper only. Effectiveness is the test. Each measure must produce the intended protective result in practice, not just exist as a policy document.

The EDPB stresses that these design elements must be in place at the earliest possible stage - ideally when you are still determining the means of processing, before any data collection begins. Retrofitting privacy into an existing system is harder, more expensive, and legally weaker than building it in from the start.

What "By Default" Means for Your Website

Data protection by default has a direct and immediate impact on how websites handle cookies, tracking, and user accounts. The default state of any system must be the most privacy-protective configuration. Users should have to actively opt in to additional processing, not opt out of it.

For cookie consent, this means no non-essential cookies may fire before the visitor makes an active choice. Pre-ticked boxes violate Article 25(2). Cookie walls that force an "accept all or leave" choice violate the requirement for freely given consent under Article 7 GDPR. The EDPB's Guidelines 3/2022 on deceptive design patterns in social media explicitly link dark patterns in consent interfaces to Article 25 failures.

A practical default-first approach to cookies looks like this:

• All non-essential scripts are blocked on page load. No _ga, no _fbp, no _gcl_au fires until consent is recorded.
• The consent banner offers granular choices: strictly necessary, functional, analytics, and marketing as separate toggleable categories.
• "Reject all" is presented with equal visual prominence to "Accept all" - same size, same colour weight, same number of clicks to reach.
• Consent preferences persist via a first-party cookie, and the visitor can change their mind at any time through an accessible preference centre.
• Consent records are stored server-side with timestamps, the version of the notice shown, and the specific choices made - these logs must survive for at least the duration of any applicable limitation period.

Social media embeds, chat widgets, and video players from third parties often set cookies the moment they load. A privacy-by-default implementation blocks these until the user actively chooses to engage with them - a two-click approach where the first click is informed consent.

Cookie Scanning and Auditing as a Design Obligation

You cannot design for privacy if you do not know what data your website collects. A surprising number of sites set cookies their owners are unaware of - injected by third-party scripts, tag management containers, or embedded content. A study by the Future of Privacy Forum noted that most DPAs remain reluctant to specify exactly which protective measures controllers should adopt, but they are consistent on one point: ignorance of your own processing activities is not a defence.

Regular cookie audits are a practical expression of Article 25. Scanning your website identifies every cookie and tracker in use, maps them to their purposes and legal bases, and reveals any that fire before consent. Kukie.io's cookie scanner detects both first-party and third-party cookies automatically, categorises them by purpose, and flags those that load without prior consent.

Auditing frequency matters. A quarterly scan is a reasonable baseline, but you should also re-scan after any significant change to your site: adding a new analytics tool, integrating a marketing platform, updating your CMS, or deploying a new third-party widget. Each of these changes can introduce cookies you did not plan for.

Privacy by Design for Website Development

If you build or commission websites, Article 25 changes how projects should be scoped and delivered. Privacy requirements belong in the functional specification, not in a post-launch compliance review.

At the requirements stage, define your data processing purposes explicitly. Which personal data will you collect, why, and under what legal basis? Document this in your records of processing activities (Article 30). If a proposed feature requires personal data that is not strictly necessary for the service the user requested, challenge whether it belongs in the minimum viable product at all. Data minimisation is not a theoretical exercise - it is an architectural constraint that should shape your database schema, your forms, and your API endpoints.

During development, implement consent management before any tracking scripts. Your tag management setup should default to blocked state for all non-essential tags. If you use Google Tag Manager, configure it with default_consent: 'denied' for ad_storage, analytics_storage, ad_user_data, and ad_personalization via Google Consent Mode v2. Google made Consent Mode v2 mandatory for organisations serving European Economic Area traffic in March 2024.

Access controls deserve attention too. Not every team member needs access to raw analytics data or customer records. Role-based access, enforced at the application level, implements the principle that personal data should not be accessible to an indefinite number of people. This is Article 25(2) in action.

Before launch, conduct a data protection impact assessment (DPIA) under Article 35 if your processing is likely to result in high risk. Even when a formal DPIA is not required, a lightweight privacy review that walks through each data flow - collection, storage, processing, sharing, and deletion - catches design gaps that are cheap to fix before go-live and expensive to fix after.

Legacy Systems and the Retrofitting Problem

Article 25 does not only apply to new projects. The EDPB's Guidelines 4/2019 state explicitly that legacy systems designed before the GDPR entered into force are required to undergo reviews and maintenance to ensure they implement data protection principles effectively. Pre-existing systems do not get a permanent exemption.

This is where many organisations struggle. A CRM deployed in 2015 might store data indefinitely with no automated deletion. An e-commerce platform might share customer details with analytics providers without granular consent. A marketing automation system might retain email addresses long after the last engagement.

The pragmatic approach is to prioritise by risk. Map your legacy systems against the seven principles in the table above. Where gaps exist, assess the severity of potential harm to individuals and the likelihood of regulatory scrutiny. High-risk gaps - like missing encryption for sensitive data or no consent mechanism for marketing cookies - should be remediated first. Lower-risk gaps can be addressed through a phased improvement plan, documented in your accountability records to show regulators that you are taking Article 25 seriously even where full compliance is not yet achieved.

The UK Position After the Data (Use and Access) Act 2025

The UK's Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025, and key provisions took effect on 5 February 2026. It amends the UK GDPR, the Data Protection Act 2018, and PECR - but it does not eliminate the data protection by design obligation. Article 25 of the UK GDPR remains in force.

The Act does introduce changes relevant to cookies and tracking. It creates narrow consent exemptions for certain low-risk cookies under a new Schedule A1 to PECR: strictly necessary cookies (already exempt), first-party analytics cookies used solely for aggregate statistical purposes, and cookies that adapt a site's appearance or functionality to user preferences. For these exempt categories, consent is not required, but you must still provide clear information about their use and offer a simple way for users to object.

Advertising, targeting, and behavioural tracking cookies still require prior opt-in consent under PECR and the UK GDPR. The Act also raised maximum PECR fines from 500,000 pounds to 17.5 million pounds or 4% of global turnover - aligning them with UK GDPR penalty levels. The ICO's 2025 Online Tracking Strategy confirms that cookie compliance is an enforcement priority.

The ICO updated its data protection by design and default guidance on 5 February 2026 to reflect DUAA changes, including a new subsection on the "children's higher protection matters" duty. If you provide online services likely to be accessed by children, you must now consider their specific needs when choosing your technical and organisational measures - a requirement that maps directly onto the Age Appropriate Design Code.

Choosing Tools and Processors That Support Article 25

Article 28(1) GDPR requires controllers to use only processors that provide sufficient guarantees to implement appropriate technical and organisational measures. This dovetails with Article 25: if your cookie consent platform, analytics tool, or hosting provider does not support privacy by design, the compliance burden falls back on you.

When evaluating a consent management platform, check whether it blocks scripts by default before consent, supports granular category-level choices, logs consent records with sufficient detail for audit purposes, and integrates with your existing tag management setup. Kukie.io handles script blocking, geo-targeted banner display, and consent logging as part of its core functionality - designed to align with the default-first requirements of Article 25(2).

For analytics, consider whether you can achieve your objectives with privacy-preserving configurations. Google Analytics 4, when properly configured with Consent Mode v2, will model conversions without setting cookies for users who decline consent. Server-side tracking can reduce the number of third-party cookies set on visitor devices. Aggregated, anonymised analytics data falls outside GDPR scope entirely - if you can work with totals and trends rather than individual-level tracking, you may not need consent for that processing at all.

Ask your vendors direct questions: Does this product support data minimisation by default? Can it enforce retention limits automatically? Does it provide role-based access controls? Can it export or delete individual user data to support subject access and erasure requests? If the answer to any of these is no, that is a gap you will need to fill through your own technical measures - or choose a different vendor.

A Practical Checklist for Article 25 Compliance

Privacy by design is not a one-time checkbox exercise. It is an ongoing obligation that applies throughout the lifecycle of every processing operation. The following checklist covers the most critical areas for website owners: