Privacy works best when you account for it from the start, not when you try to bolt it on afterwards. That is the essence of two GDPR obligations: privacy by design (data protection by design) and privacy by default (by default settings). They sound technical, but they touch anyone who helps shape a new process, form or system.
What do the two terms mean?
Privacy by design means you build privacy in from the first design of a product, service or process. You decide up front which data is genuinely needed and how to protect it, instead of patching gaps afterwards.
Privacy by default means the default setting is the most privacy-friendly one. A new user should already be well protected without changing anything, for example because a profile is not public by default.
A concrete example
Say you design a new sign-up form. Privacy by design means asking which fields are genuinely needed and dropping the superfluous ones. Privacy by default means a newsletter checkbox is off by default, not on.
The same mindset applies to a shared folder (restricted access by default), a new app (only the necessary permissions) or a survey (anonymous where possible).
Why this is smart, not just required
Building privacy in up front is cheaper and more effective than fixing it afterwards. Patching a gap in a live system costs more time, money and risk than a good design choice.
It also prevents breaches: data you deliberately do not collect, or that is well protected by default, cannot simply leak. It is data minimisation and security brought together in the design.
What you can do
Even without being a developer, you can contribute:
- For every new process, ask: which data do we genuinely need?
- Choose the privacy-friendly default, even when the less safe option is easier.
- Involve the person responsible for privacy early, not just before go-live.
- Consider a data protection impact assessment (DPIA) for high-risk processing.
How to embed this in your awareness programme
This is material for those who shape processes and projects; segment to that audience.
- Aim this module at project leads, process owners and procurement.
- Build the question 'which data do we genuinely need?' in as a fixed part of every project kick-off.
- Tie it to your DPIA process and involve the person responsible for privacy early.
- Offer depth via our course catalogue.
Related articles
- Data minimisation in practice: collect only what you need
- Privacy implications of AI-driven platforms
FAQ
What is privacy by design?
Data protection by design: you account for privacy from the first design of a product, service or process, instead of patching gaps afterwards. It is set out in Article 25 of the GDPR.
What is privacy by default?
Data protection by default settings: the default is the most privacy-friendly option. A user is already well protected without changing anything, for example because a profile is not public by default.
Does this apply only to IT staff?
No. Anyone who helps shape a new form, process or system can contribute: by asking for less data and choosing the privacy-friendly default. The technology follows from those choices.
When is a DPIA needed?
For processing with a high risk to people's rights and freedoms, such as large-scale profiling. A DPIA is part of privacy by design: you assess the risk before you begin.
Why up front and not afterwards?
Building privacy in up front is cheaper, more effective and less risky than fixing it afterwards. Data you deliberately do not collect, or that is protected by default, cannot simply leak.