The Cyber Academy take
Privacy by design (GDPR Article 25) is the obligation to bake privacy controls into systems from the requirements stage. Privacy by default is the obligation to make the highest-protection option the standard. Auditors look for documented evidence (DPIA, design review, retention defaults) rather than a slogan in a policy.
Two obligations, not one
Privacy by design and privacy by default are written as a single GDPR obligation, but they ask for two different things and practitioners get into trouble when they collapse them. By design means privacy controls are engineered into a system from the requirements stage, before a line of code is written or a vendor is chosen, rather than bolted on once the data subject access requests start arriving. By default means that when a user does nothing, the system already sits at its most protective setting: the narrowest data collection, the shortest retention, the tightest sharing. One is about how you build; the other is about what the system does on day one with no configuration.
The distinction matters because a team can satisfy one and fail the other. You can run a thorough design review, document a DPIA, and still ship a product whose default toggles are all set to maximum sharing because that is what the growth team asked for. That product is privacy by design but not by default, and it is non-compliant. The reverse also happens: a conservative default bolted onto a system that was never assessed leaves the controller unable to show how the choice was made.
What this actually changes in practice
The practical shift is moving privacy upstream. Instead of legal reviewing a finished feature, privacy requirements become design constraints that engineering and product carry from the first sprint. Data minimisation stops being a slogan and becomes a question asked of every field on every form: do we need this to deliver the service, and if not, why is it here. Purpose limitation becomes a constraint on what a data set can later be reused for. Retention becomes a default schedule the system enforces, not a manual cleanup nobody remembers to run.
- Collect the minimum fields the service genuinely needs, and justify each one.
- Set retention periods as enforced defaults, with automated deletion or anonymisation when they expire.
- Default sharing, visibility, and profiling settings to the least permissive option, leaving the user to opt in to more.
- Apply pseudonymisation and encryption as standard architectural choices rather than exceptions.
- Scope access to personal data by purpose, so a system only exposes what a given function requires.
How it sits next to neighbouring concepts
Privacy by design is easiest to understand against the things people confuse it with. It is not the same as a DPIA, which is one piece of evidence that the broader obligation was met for a specific, higher-risk processing activity. It is not security by design, which protects data from attackers regardless of whether that data should have been collected at all; privacy by design starts a step earlier by questioning the collection itself. And it is not a one-time gate. Because systems evolve, the obligation is continuous: every new feature, integration, or data flow reopens the same questions about minimisation, purpose, and default settings.
In a mature programme privacy by design becomes a habit baked into the development lifecycle rather than a checkpoint owned by legal. Product and engineering raise the questions themselves, the DPIA is triggered automatically when processing crosses a risk threshold, and the default configuration is reviewed as part of release rather than discovered in production. That is the difference between an organisation that can demonstrate the principle and one that merely claims it.
Frequently asked questions
01What is the difference between privacy by design and privacy by default?
By design means privacy is engineered into the system from the requirements stage, before it is built. By default means the system ships in its most protective configuration with no action required from the user. A product can satisfy one and fail the other, and both are required.
02Is a DPIA the same as privacy by design?
No. A DPIA is one piece of evidence that the broader privacy by design obligation was met for a specific higher-risk processing activity. Privacy by design is the wider duty to consider privacy across the whole lifecycle, and the DPIA documents that consideration where the risk warrants it.
03How is privacy by design different from security by design?
Security by design protects data from unauthorised access regardless of whether the data should exist. Privacy by design starts earlier by questioning whether the data should be collected at all, and by enforcing minimisation, purpose limitation, and protective defaults. The two are complementary.
04What evidence do auditors look for?
Documented artefacts rather than policy statements: DPIAs for higher-risk processing, design review records showing privacy was considered before build, retention schedules enforced by the system, and the actual default configuration of the live product. A claim with no artefact behind it is treated as no control.
05Is privacy by design a one-time requirement?
No. It is continuous. Every new feature, integration, or data flow reopens the questions of minimisation, purpose limitation, and default settings, so the obligation is embedded in the ongoing development lifecycle rather than satisfied once at launch.