PL EN
Book a meeting
Chapter 3Security
  1. Chapter 1Basic Compliance
  2. Chapter 2Data Subject’s Rights
  3. Chapter 3Security
  4. Chapter 4Data Processing
  5. Chapter 5Managing Incidents and Data Breaches
  6. Chapter 6Data Protection Officer (DPO)
  7. Chapter 7The Regulator
  8. Chapter 8Legal Remedies, Liability, Administrative Sanctions
  9. Appendix IPersonal Data Protection Policy
  10. Appendix IIData Processing Agreement
  11. Appendix IIIJoint Controllership Agreement
Section 3.4
  1. 3.1Data Security in Light of the GDPR: Risk Analysis and Adequacy of Security Measures
  2. 3.2Pseudonymisation and Encryption: Preferred Methods of Securing Personal Data?
  3. 3.3Privacy by Design
  4. 3.4Privacy by Default: Minimisation
  5. 3.5Data Protection Impact Assessment

Privacy by Default: Minimisation

Aleksander P. Czarnowski, Katarzyna Kloc, Katarzyna Kunda, Maciej Gawronski & Paweł Punda

#4.1 The Principle of Privacy by Default

‘Privacy by default’ is an unclear term, leading to a number of misconceptions. The term itself suggests it relates only to ‘default settings’ of computer systems and other procedures. Understanding it that way: in a situation where a data subject decides to make their data available, this should be within as limited a scope as possible, only to the extent necessary for the controller’s purposes (e.g., when creating a social media account, the initial settings should guarantee the data subject as much privacy as possible; when registering in an application, a data subject should provide necessary data only). Only a data subject should decide whether they wish to reduce the level of protection of their privacy by making further data available, changing their privacy settings, etc.

However, reaching to the specific wording of Article 25(2) GDPR we end up with a different concept.

Pursuant to Article 25(2) GDPR, a controller ‘shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed’ [minimisation of data]. That obligation applies to the amount of personal data collected [minimisation of data quantity], the extent of their processing [minimisation of data scope], the period of their storage [minimisation of data retention] and their accessibility [minimisation of data access]. In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons [control of data access].

As we see, in reality, the data controller should limit data processing in at least four dimensions (quantity, scope, retention, and access).

#4.2 Privacy by Default, i.e. Minimisation

If we take a close look at Article 25(2) GDPR, we can see that privacy by design is, in fact, the principle of minimisation. Minimisation is a multidimensional principle and one quite difficult to put into practice.

We see the following dimensions of data processing minimisation:

  1. 1)minimisation of data quantity;
  2. 2)minimisation of data processing scope;
  3. 3)minimisation of data retention periods;
  4. 4)minimisation of data access, hence;
  5. 5)regulation of data access;
  6. 6)minimisation of data control.

The principle of minimisation derives from the need-to-know principle of information and systems security. Explained simply, it means that a controller or even more accurately a particular member of a controller’s personnel knows only what is necessary for only as long as necessary and that access to the data processed is suitably regulated within the controller’s organisation.

The most important pillar of the principle of minimisation is the minimisation of access, directed both without and within the organisation. To this end, apart from introducing mechanisms that secure systems against external attacks, a controller should also analyse in advance how processing looks internally and then limit the access of new employees in lower positions to information, divide users into classes and resources into thematic groups that can be accessed only by specific classes (e.g., general resources, ascribed to a particular organisational unit, for the purposes of marketing, customers or other purposes on whose basis profiling is performed – here access should be the most restricted).

#4.3 Attributes of Privacy by Default

Guarantee privacy by design means implementing at least three of the following measures:

  1. 1)controlling access to personal data (and the possibility of verifying who accessed data and when);
  2. 2)protecting personal data against access by unauthorised persons or data leaks, e.g. by means of pseudonymisation (named directly as an example of security in Article 25(1) GDPR) or encryption;
  3. 3)restricting the scope of data processing, i.e. processing only those personal data that are necessary to achieve a given processing goal, e.g. using email to send information about a new promotion in an online shop requires only an email address, and so the database need not contain any other personal data.

#4.4 Practical Guidelines

To meet the above attributes of privacy by default in practice, you should begin by:

  1. 1)developing information architecture within your organisation. By ‘information architecture’ we mean not only IT but also a general design of storing, processing, naming, and indexing information;
  2. 2)developing access management rules, including default entitlements for particular user groups to particular resources within the IT architecture and rules for privileged access management;
  3. 3)employing appropriate tools – basic tools for managing logical access can be found in computer operating systems, while managing physical access usually involves keys and access cards;
  4. 4)using such IT services (including cloud computing) and purchasing IT systems that provide access management and accountability;
  5. 5)granting appropriate access rights and obligating personnel to use only those resources necessary for particular employees;
  6. 6)designing appropriate office infrastructure.

While the last point above may not seem key, in practice, the absence of a well thought out infrastructure can result in a high risk of data leakage. For example, we suggest having dedicated printers available to departments that process employee data, including payroll (of course, you should treat this remark as applying also to other departments that handle specific categories of data). A leak can occur if such data are printed out on a printer to which everyone has access.

Moreover, the principle of minimisation is reflected in other principles foreseen in the GDPR:

  1. 1)the principle of adequacy, based on restricting the scope of data collected;
  2. 2)the principles of limiting the duration of data processing.

We will discuss the basic principles of personal data processing individually.

#4.5 Access by an Indefinite Number of Persons

The last issue worth taking a look at with respect to privacy by default is that of data being made accessible ‘to an indefinite number of natural persons’. In our view, this issue should not be treated strictly quantitatively (although when data are made accessible to a larger number of persons, great caution should obviously be exercised).

It seems that as long as we are able to precisely specify the circle of recipients who are natural persons, we meet the requirements of privacy by default. It may turn out, though, that such a precise specification of addresses is problematic, even when it seems that the circle is closed.

#4.6 Certification of Privacy by Design and Privacy by Default

Pursuant to Article 25(3) GDPR, you can demonstrate that you have met the obligations referred to in paragraphs 1 and 2 of the article by introducing an approved certification mechanism as described in Article 42 GDPR.

In accordance with the above provision, a controller can fully meet its obligation to apply privacy by design and privacy and default by introducing an approved certification mechanism in its organisation. Even if a controller decides not to introduce such a mechanism, it is advisable to possess complete documentation confirming that the requirements have been met.

#4.7 Privacy by Design and Privacy by Default and Software

The GDPR imposes privacy by design duties on data controllers and data processors. Formally software developers are out of the scope of the Regulations. In practice, however, complying with privacy by design principles requires operating compliant and capable software. Which makes software developers indirectly but very tightly affected by Article 25(1) GDPR.

The Norwegian data protection supervisory body issued Guidelines on Software development with Data Protection by Design and by Default. The Guidelines refer to ISO 27001 standard, to the ISF Standard of Good Practice for Information Security, Microsoft Security Development Lifecycle and OWASP methodologies.

When we look directly at GDPR’s, we come up with a set of conclusions for developing GDPR compliant software.

Principles of processing. It seems not all principles of personal data processing defined in Article 5 GDPR translate into software requirements. Going systematically through the whole list of data processing principles:

  • legality of processing – not relevant unless software allows for capturing basis for processing;
  • fairness of processing – mostly not software relevant, even if software developers are asked to build in potentially excessive functionalities;
  • transparency – software related – proper design, technical and user documentation of software, including describing decisive algorithms;
  • minimisation (adequacy of processing)– software related, e.g. relating specific data retention to specific goals of processing (e.g., why and where a system performs certain data dumps), functionalities allowing for user per-data access and other rights micromanagement (regarding records, cells, etc.);
  • data accuracy – software related – how to ensure data consistency, deduplication, synchronisation;
  • data retention – software related – software tools for management of data retention;
    • security (integrity and confidentiality) – software related – how to ensure software quality and security;
    • accountability – software related – how to ensure user accountability (capture user activities) and non-repudiation.

Privacy by design and by default software potential control points:

  • does a system process personal data: system processes data about persons (personal data), system processes other data than personal data (what other data?), it is an operational technology system (can it affect processing of personal data?);
  • what is personal data: ‘regular personal data’, content (potential personal data), encrypted (potential personal data), pseudonymised, hashed, geolocation data, IP, cookie/Facebook pixel/other internet and other tracking data (personally attributable RFID, IMEI, etc.), if sensitive data are processed (special categories data, ‘criminal’ data, vulnerable persons notably children data);
  • transparency – documentation: data flows mapping including data storage, synchronisation, documenting algorithms, documenting functionalities;
  • purpose limitation: what is software business purpose, what is a scope of collected data, what data are automatically retained, if no other data are intercepted;
  • minimisation and data subjects’ rights: retrievability, selective data deletion, restriction of access, specific types of flagging, automatic data deletion (though dangerous) or other mechanisms allowing for limiting data retention (e.g., multiversioning);
  • data accuracy: consistency, deduplication, synchronisation mechanisms, 360 data view;
  • accountability: logging user access and actions;
  • data micromanagement (is it possible?) managing specific consents (for data processing, for marketing communication), objections, specific data cells, deleting specific data cells (fields), deleting whole records, defining appropriate data field statuses (restricted, updated by a data subject, objected, consent withdrawn, etc.);
  • minimisation – user management – user rights management, user rights micromanagement, managing privileged access, responding to external user management;
  • data access and data copy: formats of data reports, aggregating data from different systems and profiles, automation of review of ‘rights of others’ (Articles 15.4 and 20.4 GDPR);
  • data recipients: registering data recipients (Article 19 GDPR) – registering data transfer;
  • data portability – automation of data export, automation of review of ‘rights of others’ (Articles 15.4 and 20.4 GDPR);
  • automated decision-making – identification and description automated decision-making and decision-making algorithms, designing human intervention functionalities;
  • risk assessment: performing basic personal data processing risk assessment for software, awareness of internal (taken care of) and external (to be taken care by a client) data protection control points, verifying (to the extent possible) necessity of DPIA (including providing default input when required);
  • pseudonymisation, encryption, anonymisation – ensuring internal encryption in transit, verifying user communication encryption, verifying potential and methods of pseudonymisation, verifying use and strength of hashing and salting, verifying usability of differential privacy, verifying risks of nonavailability or losing integrity (loss of passwords or decrypting keys, mixing pseudonymised patients etc);
  • business continuity and disaster recovery – checking resilience and restorability of software;
  • international data transfers: ability of maintaining multiple instances (EU and non EU), ability to maintain EU located data warehouse combined with processing pseudonymised data).

Apart from the above which is a result of our own thinking, the Norwegian data protection supervisory authority Datatilsynet issued their own guidelines on software development with Data Protection by Design and by Default. The Norwegian Guidelines are not very concrete though they include some hints as to designing software. Also, the European Data Protection Supervisor issued on 31 May 2018 the Opinion 5/2018 Preliminary Opinion on privacy by design. That document is, however, even far less specific than the Norwegian Guidelines.