Governance DocsGovernance Docs
Browse Toolkits

CART

No products in the cart.

ISO Compliance Insights & Best Practices

privacy by design explained

Privacy by Design: 7 Principles, GDPR Article 25 and ISO 27701

Privacy by design began as a principle and became a legal obligation, and the two versions are worth keeping apart. The principle is Ann Cavoukian’s: seven foundational principles published in 2009 while she was Information and Privacy Commissioner of Ontario, and adopted as a resolution by the international conference of privacy commissioners in 2010 — proactive not reactive, privacy as the default, embedded into design, full functionality, end-to-end security, visibility and transparency, respect for the user. The obligation is Article 25 of the GDPR, “data protection by design and by default”, which requires a controller to implement appropriate technical and organisational measures designed to implement the data-protection principles, both when the means of processing are determined and when the processing happens, and to ensure by default that only the personal data necessary for each specific purpose is processed. ISO/IEC 27701 turns the obligation into a control a PIMS operates and an auditor tests, and ISO 31700-1:2023 gives consumer-goods designers a standard of their own. This guide sets out the seven principles, what Article 25 actually requires and how the EDPB reads it, how the ISO standards operationalise it, a design-stage procedure with the records that evidence it, and the errors that leave an organisation with the phrase and not the practice.

Privacy by design: principle, law, control
Cavoukian’s 7 foundational principles (2009) → GDPR Article 25 data protection by design and by default (2018) → ISO/IEC 27701 controller control and ISO 31700-1:2023 → a design-stage procedure with DPIA, defaults, minimisation and records.

The seven foundational principles

# Principle What it means in a design decision
1 Proactive not reactive; preventative not remedial Privacy risks are anticipated before the system exists, not patched after a complaint
2 Privacy as the default setting No action is required of the individual to protect their privacy — the most protective configuration ships
3 Privacy embedded into design Privacy is a component of the architecture, not an add-on module
4 Full functionality — positive-sum, not zero-sum Privacy and functionality are both delivered; false trade-offs are rejected
5 End-to-end security — full lifecycle protection Data is protected from collection to secure destruction
6 Visibility and transparency — keep it open Practices and technologies are open to verification by users and providers
7 Respect for user privacy — keep it user-centric Strong defaults, appropriate notice and usable options put the individual first

What GDPR Article 25 requires

Element Article 25 text (paraphrased) What it means in practice
Who The controller Processors help implement it but the obligation is the controller’s
When Both at the time of determination of the means for processing and at the time of the processing itself At design, and continuously in operation — not once
What: by design (25(1)) Appropriate technical and organisational measures, such as pseudonymisation, designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing Measures that make the Article 5 principles work — minimisation, purpose limitation, accuracy, storage limitation, security, transparency — built into the system
What: by default (25(2)) Measures ensuring that, by default, only personal data necessary for each specific purpose are processed — in the amount collected, the extent of processing, the period of storage and the accessibility; in particular, not made accessible to an indefinite number of people without the individual’s intervention Default settings collect least, keep shortest, share narrowest
Taking into account The state of the art, the cost of implementation, and the nature, scope, context and purposes of processing, and the risks of varying likelihood and severity to individuals Risk-based and proportionate — but the state of the art is a moving reference
Demonstration (25(3)) An approved certification mechanism under Article 42 may be used as an element to demonstrate compliance Certification helps evidence it; none is required
Penalty Article 83(4): up to €10 million or 2% of worldwide annual turnover The lower tier — but a design failure usually also breaches Article 5, which is the higher tier

The EDPB’s Guidelines 4/2019 on Article 25 (version 2.0, adopted 20 October 2020) add the reading regulators apply: “effectiveness” is the test — measures must actually implement the principles, not gesture at them; the controller must be able to demonstrate effectiveness with key performance indicators where appropriate; “state of the art” obliges controllers to keep up with technological progress; and the by-default obligation applies to every processing decision, including the options offered to users. The guidelines walk each Article 5 principle through design and default elements — for transparency, for lawfulness, for fairness, for purpose limitation, for minimisation, for accuracy, for storage limitation, for security — which is the most useful checklist a design team has. Our guide to GDPR principles covers Article 5 itself.

Privacy by design in ISO 27701 and ISO 31700

Standard How it handles privacy by design What an auditor asks for
ISO/IEC 27701:2025, Annex A.1 (PII controllers) A control requiring the organisation to design its processes, systems and products so that privacy principles and applicable requirements are implemented by design and by default, supported by controls on minimisation, de-identification, retention and impact assessment The design-stage procedure; evidence it ran on recent changes; the privacy impact assessments; the default configurations
ISO/IEC 27701:2025, clause 6 and 8 Privacy risk assessment at planning and on change; operational planning that includes privacy in change control Risk records for new processing; change records showing privacy review
ISO 31700-1:2023 — Consumer protection: privacy by design for consumer goods and services High-level requirements for organisations designing consumer goods and services: consumer communication, privacy controls, consumer privacy preferences, lifecycle data management, risk management; Part 2 gives use cases Applies to the product, not the management system; used by product teams alongside a PIMS
NIST Privacy Framework Privacy engineering objectives and the Control-P and Protect-P functions Profile-based; no certification

Our guide to ISO 27701 controls covers where the control sits in Annex A; NIST Privacy Framework covers the engineering-led alternative.

A privacy by design procedure

  1. Trigger at the idea, not the build. Any new product, feature, system, vendor, data source or purpose enters a privacy screening before design decisions are fixed — a short questionnaire: what PII, whose, why, on what basis, shared where, kept how long.
  2. Screen for a DPIA. Article 35 criteria and the supervisory authority’s list decide whether a full impact assessment is needed; record the decision either way.
  3. Design the principles in. For each Article 5 principle, the measure that implements it: minimisation (fields removed, not just unused), purpose limitation (data segregated by purpose), storage limitation (retention built into the schema), accuracy (correction paths), security (pseudonymisation, encryption, access), transparency (notice at collection).
  4. Set the defaults. The shipped configuration collects least, retains shortest, shares narrowest, and does not expose data to an indefinite audience without a user action. Opt-in, not opt-out, where consent is the basis.
  5. Test effectiveness. The EDPB’s word: does the measure actually deliver the principle? Test the defaults as a user; verify the retention job deletes; check the pseudonymisation cannot be trivially reversed.
  6. Record it. The screening, the DPIA or the decision not to do one, the design measures, the default settings and the tests — dated, with the approver. This is the evidence for Article 25 and for the ISO 27701 control.
  7. Re-run on change. A new purpose, a new data source, a new recipient or a change in the state of the art re-triggers the procedure — “at the time of the processing itself”.

Privacy by design errors

  • A principle on the wall and no procedure. Article 25 is demonstrated by measures and records, not by a policy statement.
  • Privacy review after the architecture is fixed. The obligation attaches when the means are determined; a review at go-live can only bolt on.
  • Defaults set for growth metrics. Pre-ticked consent, maximum data collection, indefinite retention — each is a by-default breach before any misuse.
  • Minimisation as unused fields. Data collected and not used is still collected; minimisation means the field is gone.
  • State of the art frozen at launch. A pseudonymisation technique adequate in 2019 may not be in 2026; the obligation is continuous.
  • Vendors outside the procedure. A processor’s design choices are the controller’s Article 25 problem; the procedure covers procurement.

Our guide to ISO 27701 implementation covers where the procedure sits in a PIMS build.

Frequently asked questions

What is privacy by design?
The practice of building privacy into systems, processes and products from the design stage rather than adding it afterwards — Ann Cavoukian’s seven foundational principles from 2009 — and, since 2018, the legal obligation in GDPR Article 25 (data protection by design and by default) for controllers to implement measures that make the data-protection principles effective, both at design time and in operation.

Is privacy by design mandatory?
Under the GDPR and UK GDPR, yes — Article 25 binds controllers, with fines under Article 83(4) of up to €10 million or 2% of worldwide turnover, and a design failure usually also breaches Article 5’s principles at the higher tier. ISO 27701 makes it an auditable control for organisations that certify a PIMS.

What is the difference between by design and by default?
By design (25(1)) is about the measures built into the processing to implement the principles — pseudonymisation, minimisation, safeguards. By default (25(2)) is about the settings that apply without the individual doing anything: only necessary data, shortest retention, narrowest access, no exposure to an indefinite audience.

How do you evidence it?
With records from a design-stage procedure: the privacy screening, the DPIA or the documented decision not to do one, the measures chosen per principle, the default configuration, the effectiveness tests and the sign-off — re-run on change. The EDPB’s guidelines expect demonstrable effectiveness, with KPIs where appropriate.

Which standard covers it?
ISO/IEC 27701:2025 as a PII controller control within a certifiable PIMS; ISO 31700-1:2023 as high-level requirements for consumer goods and services; the NIST Privacy Framework as an engineering-oriented alternative. The EDPB Guidelines 4/2019 are the regulatory reading of Article 25.

Where this leaves you

Treat privacy by design as a procedure with records: trigger it at the idea, screen for a DPIA, design a measure for each principle, ship the most protective defaults, test that the measures work, write it down, and re-run it on change. The seven principles say why; Article 25 says you must; ISO 27701 is how an auditor checks that you did.

References

More on ISO 27701

The privacy by design procedure and screening questionnaire, the privacy impact assessment template, the default-settings checklist, the data minimisation and retention templates and the design review record are in the ISO 27701 Toolkit, or start with the free templates.

When a standard changes, know first

One email a month: edition changes, new deadlines, and what they mean for documentation you already have. No sales sequence.

We don’t spam! Read our privacy policy for more info.