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 establishes this 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 violation of the law.
What does this mean in practice? The GDPR requires that when designing systems, processes and services you already take technical and organisational measures to protect personal data. Think of choices about which data you collect at all, how long you retain it, who has access to it and how you secure it. You make these choices in the concept phase, not when the system is already live.
The benefits are tangible:
- Lower risk of data breaches because security risks are identified early
- Lower costs, since adjusting afterwards is always more expensive than designing well upfront
- 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 EDPB has adopted these principles as a guideline in its guidance 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 goes 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 an "and/and" approach: good security and good privacy are both achievable.
- Security across the entire life cycle. 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 is specifically about 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 best protected.
| Aspect | Privacy by design | Privacy by default |
|---|---|---|
| Scope | The entire design and development process | Default settings of the end product |
| When it applies | From the concept phase | At 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:
- An online 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 to be public chooses that actively.
- An app doesn't request location data if it's not necessary for the 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 at 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 involvement from privacy professionals, developers and management, right from the first conversation about a new system or service.
Technical measures you include from the concept phase:
- Pseudonymisation and encryption of personal data
- Role-based access control, so that employees only see what they need
- Technically enforced retention periods, so that data is deleted automatically
- Data minimisation as a design requirement: collect only what is strictly necessary
Organisational measures that carry at least equal weight:
- Privacy training for everyone who works with personal data
- An authorisation policy that specifies 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 for the IT department to solve. Privacy by design only works if it is also embedded in processes, policy and culture. Organisations with legacy systems face extra risk here: outdated assumptions about privacy risks lead to compliance problems with new functionality. The solution is not to replace the entire system, but to design new functionality according to current principles.
How do you demonstrate compliance to the Dutch Data Protection Authority?
During inspections, the Dutch Data Protection Authority looks not at paper documents, but at the actual technical setup of systems. A nice privacy policy in a drawer is no proof of compliance. What counts is what 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 processing register
- Evidence of privacy training conducted and internal policy
- Technical configuration of access rights and encryption
- 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 documentation and technical setup go hand in hand. A system that is technically well set up but whose choices no one has recorded stands weak during an inspection.
Pro tip: Record design choices at the moment you make them, not afterwards. A short note in your project documentation about why you chose 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's precisely here that privacy by design proves 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 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 in this principle from the ground up. Concrete measures:
- EU hosting in Frankfurt, so that data stays within the European Union
- Row-level security at the database level, so that coaches only see the data of their own clients
- Multi-factor authentication as a standard security layer
- A data processing agreement; sub-processors process within the EU or under the EU Standard Contractual Clauses
- 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 receive check-ins without worrying about who else is watching. The GDPR setup of Exantur 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. Anyone who implements it well finds 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 in the system itself. That is precisely 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 set up properly, retention periods are enforced automatically and employees know what they may and may not process.
Do you, as a coach or coaching organisation, 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 insights
Privacy by design is a legal obligation under Article 25 GDPR that requires technical and organisational privacy measures to be built in from the concept phase, not afterwards.
| Point | Details |
|---|---|
| Legal basis | Article 25 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 violate the GDPR. |
| Demonstrable compliance | The Dutch Data Protection Authority assesses the actual technical setup, not just policy documents. |
| Early integration pays off | Adding privacy measures afterwards significantly increases costs and risks compared to early integration. |