Skip to content
← Back to the blog

Privacy by design: from best practice to legal obligation

Privacy by design began as a principle in the 1990s and became law under the GDPR. What it means, and how it is applied.

3 min read

Privacy · GDPR

For a long time, privacy was treated as an add-on: something to sort out at the end, with a policy page and a few settings buried in a menu. Privacy by design turns that logic around. The idea is simple but demanding: data protection must be built in from the start, as part of the design, not bolted on afterwards.

In short. Privacy by design emerged as a principle in the 1990s, was formalised into seven foundational principles, and was adopted internationally in 2010. With the GDPR (Regulation (EU) 2016/679) it stops being a best practice and becomes a legal obligation: Article 25 requires data protection “by design” and “by default”, with data minimisation at its core.

Where it comes from (and its seven principles)

The concept was developed by Ann Cavoukian, then Information and Privacy Commissioner of Ontario, Canada. Its roots go back to the 1990s (an early joint report dates to 1995); the mature framework was published in 2009 and gained international recognition in 2010, when it was adopted by the global assembly of data protection authorities.

Privacy by design is organised around seven foundational principles:

  1. Proactive not reactive; preventive not remedial.
  2. Privacy as the default setting.
  3. Privacy embedded into design.
  4. Full functionality — positive-sum, not zero-sum.
  5. End-to-end security across the full data lifecycle.
  6. Visibility and transparency.
  7. Respect for user privacy — a person-centric approach.

The fourth principle is perhaps the least intuitive and the most important: protecting privacy should not mean giving up functionality. A good product doesn’t ask people to choose between usefulness and confidentiality.

From principle to law: GDPR Article 25

With the General Data Protection Regulation, privacy by design enters European law. Article 25, titled “Data protection by design and by default”, sets out two complementary obligations.

Protection by design requires appropriate technical and organisational measures — from the moment the means of processing are determined — to implement data-protection principles, such as minimisation, in an effective way. In practice: privacy is built into the product’s architecture, not applied after the fact.

Protection by default requires that, without any action from the user, only the personal data necessary for each specific purpose are processed. It covers the amount of data collected, the extent of processing, retention periods and accessibility. In other words: the most privacy-protective configuration must be the starting point, not an option to hunt for.

The operational core: data minimisation

Article 25 doesn’t stand alone: it explicitly points to data minimisation, one of the principles in Article 5 of the GDPR. Under Article 5(1)(c), personal data must be “adequate, relevant and limited to what is necessary” in relation to the purposes of processing.

It’s a principle that is disarming in its simplicity: collect only what you need, keep it only as long as you need it, make it accessible only to those who need it. The less data you collect, the less can be lost, misused or exposed in an incident. Minimisation is, at once, a privacy safeguard and a security measure.

European regulators have clarified how to apply all of this: the EDPB (European Data Protection Board) guidelines on Article 25, adopted in their final version in October 2020, offer concrete guidance on turning the principle into design choices.

How we apply it

In OM Software’s apps the principle shows most clearly in the defaults: the most protective option is already on at first launch, and any additional sharing is an explicit choice by the person using the app, never a setting they have to find in order to switch it off.

Sources

Related insights