What is privacy by design & default according to GDPR?

Privacy by design is an approach to systems engineering initially developed and formalized by a joint team led by the Information and Privacy Commissioner of Ontario (Canada), back in 1995. After a quarter of a century and an ever-growing swamp of personal data leakages, due to both the poor systems design and operations practices, as well as faulty data management habits, what is the purpose of still discussing this concept?

What does Article 25 of GDPR state about privacy by design & default?

The European Union General Data Protection Regulation (GDPR) brings a new perspective: Article 25 is conveniently named “Data protection by design and by default”. Before tackling the deviation from the original concept in wording, here is the breakdown from the Article 25 text:

• What does “Data protection by design and by default” include? Technical and organisational measures, designed to implement data-protection principles, such as pseudonymisation and data minimisation.
• What does it ensure? Meeting the requirements of the GDPR and protecting the rights of data subjects.
• What is the outcome of implementation? By default, only personal data which are necessary for each specific purpose of the processing are processed. Also, data should not be made accessible to a large number of persons without the intervention of the data owner/custodian (which relates to the “deny-first” principle, enabling access to data for only a limited number of authorised persons).
• Who is responsible? Data controllers and processors (as implied by Article 28). To help you determine their roles and how to establish good relationships with them, check out this article: The obligations of controllers towards Data Protection Authorities according to GDPR.
• How and when is it supposed to be applied? Both at the time of the determination of the means for processing and at the time of the processing itself – which translates to the design phase of the development of new systems and business practices, as well as assuring privacy assurance of existing personal data repositories.
• Ok, but what does it actually impose on the data controllers? The obligation applies to the amount of personal data collected, the extent of its processing, the period of its storage and its accessibility.
• Which factors influence the implementation? The actual implementation decision should be taking into account the technological environment, the cost of implementation, and the nature, scope, context and purposes of processing. Also, the selection of the process or tool of choice should be based upon the risk assessment results, taking into account the severity of the risk to the rights and freedoms of data subjects – the latter translates to the necessity of using Data Protection Impact Assessments (DPIAs), while the former leaves the final decision to the Data Controller, without stipulating any specific obligations. To find out more about the DPIA, check out this free webinar: Seven steps of Data Protection Impact Assessment (DPIA) according to EU GDPR.

Hopefully, this breakdown illustrates the vagueness of the principle, as outlined in the GDPR – there is no regulation-imposed measure, rather a set of suggestions, mentioning data minimisation and pseudonymisation.

Full text of the EU GDPR (General Data Protection Regulation)

Free document with the official text of the Regulation in PDF format

Download now

The “privacy by design” approach vs. the GDPR’s “Data protection by design & default” concept

The reader is faced with two terms, both including the same phrase (“by design”), but each appearing in a different day and age. What follows is first the explanation of differences, followed by the summarisation of principles valid for both concepts.

The “original” privacy by design approach is not about data protection; rather, it focused on designing the system in such a way that data doesn’t need protection. The key concept here is anonymisation: a system designed as “fully” privacy compliant simply wouldn’t include disclosure of personally identifiable data to the data controller, while at the same time enabling certain system functionality. An example could be drawn from the Global Positioning System (GPS) device in the context of fleet management solutions – a vehicle’s GPS device enables detection of geographical location, without revealing the driver’s identity.

Somewhat contrary to that, with “Data protection by design & default”, the GDPR adopts the view that processing of personal data is inevitable; therefore, integration of “the necessary safeguards into the processing” is obligatory. It also brings a widening of scope, making it more of a multi-faceted concept. Along with the design of information technologies and systems, it also involves various organisational components, which implement privacy and data protection principles in systems and services.

Seven core principles of privacy by design

Now, let’s focus on the similarities. The “by design” principle in both approaches expresses the need for embedding privacy concerns in the design and operation of systems for personal data processing, business practices and physical design.

The approach specifies seven core principles:

1. Being proactive rather than reactive – by anticipating and preventing privacy-invasive events beforehand, the aim is to prevent privacy risks from materialising.
2. Privacy as the default setting – by ensuring that personal data is automatically protected in any given IT system or business practice, data subjects’ personal information is protected from the beginning of the lifecycle, and remains protected, without action required on their part.
3. Privacy embedded into design – by integrating privacy into the system (without reducing functionality), it is recognised as the core component, rather than being thrown in later as an add-on.
4. Full functionality – privacy should not be incorporated at the expense of, or as a trade-off for, functionality, security and performance.
5. End-to-end security (providing full life-cycle management of data) – this involves ensuring that all personal data is securely collected, stored, processed, shared/disclosed and then securely destroyed at the end of the process.
6. Visibility and transparency of data – this refers to forcing transparency of the processing practices in accordance with the stated promises and objectives, making them visible to the data subjects and processors and subject to independent verification (audit).
7. Respect for user privacy (user-centric) – this requires architects and operators to protect the interests of the data subject by offering such measures as strong privacy defaults, appropriate notice, and empowering, user-friendly options.

Principles in theory vs. practice

All these principles sound excellent (as principles often do). And, while some efforts to put the theory into practice are relatively straightforward and quickly winnable (e.g., developing and publishing privacy policies and notices, introducing privacy awareness programs, assessing data retention obligations, locking file cabinets with employee records), those falling into the technology realm require a more exhaustive approach.

However, serious discussions about privacy principles themselves require a change of mindset in the organisation’s environment. This helps to establish an ongoing effort of raising the level of privacy assurance. And, the best way to raise this GDPR-weighted lever is by starting from the top, all the way down to the very machine running a business – the people and production systems.

Click here to read the full text of the GDPR to find out more about the privacy by design approach.