Privacy by design: the GDPR obligation you can't ignore
Privacy by design: the GDPR obligation you can't ignore
What is privacy by design and why does the GDPR require it?
Privacy by design means that you don't add privacy protection afterwards, but build it in from the very first design stage. Article 25 of the GDPR lays this down as a firm legal obligation for every data controller. Anyone who waits until a system is finished and then quickly adds a few privacy measures is acting in breach of the law.
What does this mean in concrete terms? The GDPR requires that when designing systems, processes and services you already take both technical and organisational measures to protect personal data. Consider choices about which data you collect in the first place, how long you retain it, who has access to it and how you secure it. You make those choices in the concept phase, not once the system is already live.
The benefits are tangible:
- A lower chance of data breaches, because security risks are identified early
- Lower costs, because adjusting things afterwards is always more expensive than designing them well up front
- Demonstrable compliance towards the Dutch Data Protection Authority
- Greater trust from users and clients in your services
- Protection of data subjects' rights as a structural part of your product
The seven fundamental principles of privacy by design
The framework for data protection by design is built around seven principles that Ann Cavoukian developed in the 1990s. The European supervisory authority, the EDPB, has adopted these principles as guidance in its guidelines on data protection by design and by default.
The seven principles, briefly explained:
- Proactive, not reactive. You anticipate privacy risks and prevent them, rather than reacting after something has gone wrong.
- Privacy as the default. Personal data is automatically protected, even if a user does nothing. No action is required from the data subject.
- Privacy embedded in the design. Privacy measures are not a layer on top of the system, but an integral part of the architecture.
- Full functionality, positive-sum. Privacy does not have to come at the expense of functionality. Cavoukian replaced "either/or" thinking with a "both/and" approach: strong security and strong privacy are both achievable.
- Security across the entire lifecycle. Data is collected, processed, stored and deleted securely. Security doesn't stop at the login page.
- Visibility and transparency. Users and supervisory authorities can verify that the system does what it promises. Independent verification is possible.
- Respect for the user. The system is designed with the data subject's interests in mind: clear information, simple choices, strong privacy standards.
The positive-sum principle deserves extra attention. Many organisations treat privacy as a brake on functionality. Cavoukian shows that this is a false dichotomy. A well-designed system offers both: strong security and a rich user experience.
What is the difference between privacy by design and privacy by default?
Privacy by default is not a synonym for privacy by design, but a component of it. The distinction is simple: privacy by design is about the entire design process, while privacy by default relates specifically to the default settings of your product or service.
Privacy by default requires that default settings are always as privacy-friendly as possible. Users don't have to change any settings to protect their privacy. Anyone who does nothing is automatically the best protected.
| Aspect | Privacy by design | Privacy by default |
|---|---|---|
| Scope | The entire design and development process | The default settings of the end product |
| When it applies | From the concept phase | With every user interaction |
| Example | Building encryption into the architecture | Setting a profile to private by default |
| Legal basis | Article 25 GDPR | Article 25(2) GDPR |
Concrete examples make the difference clear:
- A web shop may not pre-tick the box "Yes, I want to receive offers." The user must make a conscious choice themselves.
- A social platform sets profiles to private by default. Anyone who wants their profile public chooses that actively.
- An app does not request location data if that is not necessary for its core function.
Pro tip: For every new feature, check whether the default behaviour is the most privacy-friendly option. This is not a one-off check, but a recurring question with every sprint or product release.
How do you effectively integrate privacy by design into your organisation?
Privacy by design is a continuous methodology, not a project with an end date. Anyone who treats it as a checklist misses the point entirely. Effective integration requires the involvement of privacy professionals, developers and management, right from the first conversation about a new system or service.
Technical measures you take into account from the concept phase:
- Pseudonymisation and encryption of personal data
- Role-based access control, so employees only see what they need
- Technically enforced retention periods, so data is deleted automatically
- Data minimisation as a design requirement: collect only what is strictly necessary
Organisational measures that carry at least as much weight:
- Privacy training for everyone who works with personal data
- An authorisation policy that sets out who may view which data
- Privacy impact assessments for new processing activities or systems
- Involvement of the data protection officer (DPO) in design discussions
A common mistake is treating privacy as a technical problem that the IT department solves. Privacy by design only works if it is also embedded in processes, policy and culture. Organisations with legacy systems run an extra risk here: outdated assumptions about privacy risks lead to compliance problems with new functionalities. The solution is not to replace the entire system, but to design new functionalities in accordance with the current principles.
How do you demonstrate compliance to the Dutch Data Protection Authority?
During inspections, the Dutch Data Protection Authority does not look at paper documents, but at the actual technical set-up of systems. A nice privacy policy sitting in a drawer is no proof of compliance. What counts is what actually happens in practice.
What a privacy officer must be able to demonstrate:
- Technical logs showing who had access to which data and when
- Documented design choices with privacy considerations, preferably in a record of processing activities
- Evidence of privacy training carried out and internal policy
- The technical configuration of access rights and encryption
- The results of privacy impact assessments carried out
The accountability obligation under the GDPR requires that you are not only compliant, but can also demonstrate it. This means that documentation and technical set-up go hand in hand. A system that is technically well set up but whose choices no one has recorded is in a weak position during an inspection.
Pro tip: Record design choices at the moment you make them, not afterwards. A brief note in your project documentation explaining why you opted for pseudonymisation is worth more during an inspection than an extensive report you reconstruct later.
Privacy by design in practice: coaching software as an example
Coaching software processes particularly sensitive data. Session notes, personal breakthroughs, psychological insights and clients' goals are among the most confidential information a professional manages. It is precisely here that privacy by design shows its worth.
According to the EDPB guidelines, strong security and specific access restrictions must be applied to sensitive personal data. Row-level security, where access is managed at the row level in the database, is one of the most effective technical measures for this.
Exantur is an example of coaching software that has built this principle in from the ground up. Concrete measures:
- EU hosting, so data stays within the European Economic Area
- Row-level security at the database level, so coaches only see the data of their own clients
- Multi-factor authentication as a standard security layer
- A protected client portal where the coachee only sees their own progress and goals
- GDPR-compliant data processing as an architectural choice, not a later addition
What this means for a coach: you can record confidential session notes, track goals and send check-ins without worrying about who else is watching. Exantur's security is not a marketing promise, but a technical architectural choice that demonstrably complies with Article 25 of the GDPR.
What does privacy by design deliver for organisations and data subjects?
Privacy by design is not a cost item. Those who implement it well find that it also delivers benefits that go beyond avoiding fines.
For organisations, the benefits are concrete. Privacy risks discovered early cost less to remedy than problems that only come to light after a data breach. Organisations that treat privacy as a core functionality build a lasting competitive advantage, as Cavoukian already described in her original framework. That advantage is measurable in customer trust, fewer incidents and a stronger position in tenders where GDPR compliance is a requirement.
For data subjects, the people whose data is being processed, the effect is perhaps even more direct. They don't have to rely on an organisation's good intentions. The protection is built into the system itself. That is exactly what Cavoukian's second principle promises: privacy as the default, not as an option.
Organisations that take privacy by design seriously also report fewer internal incidents. Not because they are lucky, but because the chance of an error is structurally smaller when access rights are properly configured, retention periods are automatically enforced and employees know what they may and may not process.
As a coach or coaching organisation, do you want to work with software that treats privacy by design not as an afterthought but as a foundation? Exantur is built for coaches who take their profession seriously and want their software to do the same.
Key takeaways
Privacy by design is a legal obligation under Article 25 of the GDPR that requires technical and organisational privacy measures to be built in from the concept phase, not afterwards.
| Point | Details |
|---|---|
| Legal basis | Article 25 of the GDPR obliges every data controller to ensure data protection by design and by default. |
| Seven principles | Ann Cavoukian's framework places privacy proactively, as the default and embedded in the design of systems and services. |
| Privacy by default | Default settings must always be the most privacy-friendly option; pre-ticked choices breach the GDPR. |
| Demonstrable compliance | The Dutch Data Protection Authority assesses the actual technical set-up, not just policy documents. |
| Integrating early pays off | Adding privacy measures afterwards significantly increases costs and risks compared to early integration. |