Privacy by Design and Privacy by Default — How to Implement Article 25 GDPR in Practice

Privacy by design (data protection by design) and privacy by default (data protection by default) are two principles that the GDPR elevates to the status of legal obligations. Article 25 GDPR requires the controller to take data protection into account at every stage of designing systems, products, and processes — not as an afterthought, but as an integral element from the very beginning.

In practice, this is one of the most frequently ignored GDPR principles — and simultaneously one that UODO and European supervisory authorities are increasingly examining during audits. Analysis of enforcement decisions shows that fines for violating Article 25 are rising, and authorities check not only whether an organisation “has procedures” but whether it genuinely considered data protection before launching a new system or process.

This article explains what privacy by design and privacy by default mean, how to implement them in practice, and what mistakes organisations most commonly make.

Privacy by Design — What Is Data Protection by Design?

Article 25(1) GDPR provides that the controller — taking into account the state of the art, the cost of implementation, the nature, scope, context, and purposes of processing, as well as the risks of varying likelihood and severity — shall, both at the time of determining the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures designed to implement data protection principles effectively and to integrate the necessary safeguards into the processing.

In practical terms: before you launch a new system, product, service, or process that will process personal data, you must plan from the very start how that data will be protected. Data protection is not something to be “added later” — it must be part of the design from day one.

Key elements of Article 25(1):

“Taking into account the state of the art” — the controller must use current technical solutions, not outdated ones. “We’ve always done it this way” is not an acceptable excuse.

“The cost of implementation” — the GDPR does not require unlimited spending. The controller must consider proportionality — but a tight budget does not justify the complete absence of safeguards.

“At the time of determining the means for processing” — i.e., at the design stage, before processing begins.

“At the time of the processing itself” — privacy by design is not a one-off exercise. The controller must continuously verify whether the measures in place remain adequate.

Privacy by Default — What Is Data Protection by Default?

Article 25(2) GDPR provides that the controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. This obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage, and their accessibility.

In practical terms: the default settings of a system, service, or product should ensure maximum privacy protection. The user should not have to actively “turn on” privacy — privacy should be the default.

Practical examples of privacy by default:

Registration form — marketing consent checkboxes unchecked by default. The user decides whether they want a newsletter — they should not have to actively unsubscribe.

Social media profile — set to private by default (visible only to contacts), not public. The user decides whether to make it public.

Mobile app — does not collect location data by default. Requests location access only when the user wants to use a function that requires it.

CRM system — access to customer data limited by default to the account manager, not open to all employees.

Newsletter — after consent withdrawal, data is automatically removed from the mailing list without requiring further user action.

User account — a default retention period after account deletion (e.g., 30 days), not indefinite storage.

The 7 Principles of Privacy by Design (Ann Cavoukian)

The concept of privacy by design was formulated in the 1990s by Ann Cavoukian, Ontario’s Information and Privacy Commissioner. While the GDPR does not directly adopt her 7 principles, they provide the best conceptual framework for implementing Article 25:

1. Proactive not reactive — preventive not remedial. Identify and eliminate privacy risks before they materialise. Do not wait for a breach to fix the system.

2. Privacy as the default setting. Default settings should ensure maximum protection. The user should not have to take action to protect their privacy — the system does it for them.

3. Privacy embedded into design. Privacy protection is an integral part of the system architecture, not an add-on. It is a functional requirement, not a post-deployment patch.

4. Full functionality — positive-sum, not zero-sum. Privacy by design does not mean sacrificing functionality. The goal is to achieve both full functionality and full privacy protection — not choosing one at the expense of the other.

5. End-to-end security — full lifecycle protection. Data is protected from collection to deletion. This includes secure collection, storage, processing, and destruction.

6. Visibility and transparency. Data protection policies and practices are open and transparent. Data subjects can verify that protection works as declared.

7. Respect for user privacy — user-centric approach. The system puts user privacy first — providing strong default settings, appropriate notifications, and user-friendly privacy management mechanisms.

How to Implement Privacy by Design in Practice — Stage by Stage

Stage 1: Conceptual Phase

Before the first line of code is written or the first process is launched, ask:

What personal data will be processed? Is all of it necessary (minimisation)?

Who will have access to the data? Can access be restricted (least privilege)?

How long will data be stored? Can automatic deletion be implemented?

Will data be shared outside the organisation? Outside the EEA?

What risks does the processing pose to individuals? Is a DPIA needed?

Can the system be designed to process less data or anonymised data?

Stage 2: Design

At the design stage, implement specific measures:

Data minimisation — collect only data that is objectively necessary. If a registration form needs a name and email, do not add fields for date of birth, phone number, or address “just in case.”

Pseudonymisation — where possible, apply pseudonymisation — separate identifying data from substantive data. Instead of storing “John Smith, disease X, medication Y” in one table, separate identification data from medical data, linking them with a key.

Encryption — design encryption from the start (at rest and in transit), not as a post-deployment fix.

Access control — design a role-based access control system (RBAC) from the outset. Who needs to see what data? Principle: no one should have access to data they do not need for their work.

Retention — design automatic data deletion mechanisms for when the retention period expires. Do not rely on manual deletion — it fails.

Anonymisation — if data is needed for analytics or statistics, check whether it can be anonymised. Anonymised data is not subject to the GDPR.

Data subject rights mechanisms — design the system to enable easy fulfilment of access, erasure, rectification, and portability requests. If the system cannot delete a specific user’s data, it violates the GDPR from the moment of deployment.

Stage 3: Implementation

During implementation, verify that the designed measures have actually been implemented:

Is encryption enabled? Is access control working correctly? Are default settings “private” (privacy by default)? Does the data deletion mechanism work? Is the privacy notice in place?

Stage 4: Testing

Before launch, conduct security and privacy tests:

Penetration test — is the system resistant to attacks?

Access test — do users see only data they are authorised to access?

Retention test — is data actually deleted when the period expires?

Data subject rights test — does the system enable GDPR requests (access, erasure, export)?

Default settings test — does a new account have “private” default settings?

Stage 5: Maintenance and Review

Privacy by design does not end at deployment. The controller must regularly verify whether the measures remain adequate — particularly when processing purposes change, new features are added, technologies and threats evolve, or new regulations emerge (AI Act, NIS2).

Privacy by Design in Specific Scenarios

Mobile App

Request minimal permissions — do not ask for access to contacts, camera, or microphone unless a function requires it. Store data locally on the device if it does not need to be in the cloud. Encrypt data stored on the device. Do not track location by default — request consent only for functions that require it. Implement an account deletion mechanism — with actual data deletion from the server.

Website / Online Shop

Forms — collect minimum data. Mark mandatory and optional fields. Cookies — load only essential cookies by default (prior blocking). Account — offer guest checkout. Newsletter — checkbox unchecked by default. Passwords — enforce strong passwords, hash them in the database. Retention — automatic deletion of abandoned carts and inactive accounts.

HR System

Employee data access — limited to those who need it (HR, line manager — not the entire department). Recruitment data — automatic deletion of candidate data after recruitment ends (unless consent for future recruitment). Monitoring — off by default, enabled only after meeting all legal requirements. Electronic personnel files — encryption, access control, operation logging.

CRM System

Customer data — access limited to the account manager and their supervisor, not the entire company. Segmentation and profiling — off by default, enabled after obtaining a legal basis. Retention period — automatic deletion of inactive customer data after a defined period. Data export — ability to export customer data in a machine-readable format (portability right).

Privacy by Design and DPIA

Privacy by design and DPIA are two complementary tools:

DPIA identifies risks associated with planned processing and proposes mitigation measures.

Privacy by design ensures that those measures are built into the design from the start, not added as patches after deployment.

In practice, the DPIA should be conducted at the design stage (not after deployment) — and its results should directly influence the system architecture. If the DPIA identifies high profiling risk, the system should be designed with mechanisms to limit profiling (opt-out, algorithm transparency) — not with a note that “the risk is high, but we’re not doing anything about it.”

Privacy by Design and the AI Act

The AI Act (Article 9) requires high-risk AI systems to be designed and developed with data governance in mind — including training data quality, data minimisation, and appropriate safeguards. This is privacy by design in the context of artificial intelligence.

The combination of Article 25 GDPR with AI Act requirements means that organisations deploying AI systems must design them from the outset with both personal data protection (GDPR) and AI risk management (AI Act) in mind.

Most Common Mistakes — Article 25 Violations

“We’ll add GDPR later” — the most widespread mistake. The system is designed, built, and deployed, and only at the end does someone ask “what about GDPR?” By then, architectural changes are expensive or impossible.

Collecting data “just in case” — forms with dozens of fields, most of which are unnecessary. Violates both privacy by design and the data minimisation principle.

“Everything public” by default — user profiles public by default, marketing checkboxes pre-ticked, data access open to all employees by default.

No data deletion mechanism — the system does not support deleting a specific user’s data (e.g., data is scattered across multiple tables with no cascading deletion mechanism).

No retention — the system has no automatic data deletion mechanism after the retention period expires. Data accumulates indefinitely.

No encryption at the design stage — adding encryption after deployment is significantly more difficult and expensive than designing it from the start.

Ignoring least privilege — all employees have access to all data. No role or permission system.

No DPO involvement in design — the DPO is not consulted at the design stage of new systems and processes. They learn about them only after deployment.

Fines for Violating Article 25 GDPR

Article 25 is subject to fines under Article 83(4) — up to EUR 10 million or 2% of annual global turnover. UODO and European supervisory authorities are increasingly imposing fines for the absence of privacy by design — particularly when a data breach was a consequence of missing safeguards that should have been built in from the start.

UODO fined Morele.net PLN 3.8 million for violations of Articles 25 and 32 GDPR — insufficient technical safeguards that should have been designed from the outset.

Checklist — Privacy by Design and Privacy by Default

1. Involve the DPO and data protection team in designing new systems and processes — from the very start.
2. Conduct a DPIA at the design stage — not after deployment.
3. Apply data minimisation — collect only what is necessary.
4. Design default settings as “private” — do not require users to actively enable privacy.
5. Implement encryption from the start — at rest and in transit.
6. Design role-based access control (RBAC) — least privilege principle.
7. Plan automatic retention — a mechanism for deleting data after the retention period.
8. Design data subject rights mechanisms — access, erasure, export, rectification.
9. Consider pseudonymisation and anonymisation — where possible.
10. Test privacy before deployment — access, retention, and default settings tests.
11. Document design decisions — what measures were applied, why, what alternatives were considered.
12. Review regularly — are the measures still adequate to the risks?

Need Support With Privacy by Design?

Implementing privacy by design requires a data protection expert’s involvement at the earliest stage of the project — before architectural decisions are made that will be difficult to change. At the Law Office of Dr Joanna Maniszewska-Ejsmont, we advise companies on designing systems, applications, and processes compliant with Article 25 GDPR — from requirements analysis, through DPIA, to implementation verification.