Data protection by design and by default pursuant to Art. 25 GDPR ("often also referred to as Privacy by Design and default") is, along with accountability (Art. 5(2) GDPR), the right to be forgotten (Art. 17 GDPR), the right to data portability (Art. 20 GDPR) and data protection impact assessments (Art. 35 GDPR), one of the fundamental innovations brought about by the General Data Protection Regulation (GDPR).
The provision obliges the controller to take appropriate technical and organisational measures "both at the time of the determination of the means for processing and at the time of the processing itself" in order to meet the requirements of data protection law and to protect the rights of the data subjects. Furthermore, the controller is obliged to ensure, by means of default settings, that only as much personal data is processed as is necessary to fulfil the purposes of the processing.
The Specific Requirements from the Law
In its paragraphs 1 and 2, the provision lays down two essential requirements that controllers must meet. It should be emphasized that the requirements affect both software developers and operators equally. Data protection conformity must be taken into account not only in the programming, but also in the selection of the software. In the following, the requirements from the provision are explained in detail.
Data Protection by Design (Art. 25(1) GDPR)
The first requirement, Data protection by design, is regulated in Art. 25(1) GDPR. The provision states:
"Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.“
This requirement aims at ensuring compliance with data protection principles. These are the cornerstone of European data protection law and form the framework for the lawfulness of processing. Data protection by design is a product of the risk-based approach of the GDPR, as is, for example, the notification of a personal data breach to the supervisory authority pursuant to Art. 33 GDPR or data protection impact assessments pursuant to Art. 35 GDPR. It is true that the controller has a margin of discretion in the selection and deployment of appropriate technical and organisational measures. However, on the one hand, these must correspond to the state of the art and, on the other, take into account the probability of occurrence and the severity of the risks to the rights and freedoms of the data subjects. Consequently, it must always be checked in advance whether the intended measure
a). actually achieves the purpose for which it is intended to be used and
b). is proportionate to the risk to be avoided
why the controller is granted a margin of discretion dependent on certain factors. The provision explicitly mentions one example, namely pseudonymisation to comply with the principle of data minimisation (Art. 5(1)(c) GDPR). Here is a reference to practice: it would not be in the sense of the provision to pseudonymise only a few individual characteristics from a larger data set on a data subject, so that the overall measure fails to have the required effect. For example, it would make little sense to pseudonymise only the street and house number from an address file if the data subject lives in a small village, the postal code is still given and the person has a rather rare surname. In the end, the person could be inferenced without much effort.
On the other hand, the provision also protects the controller from excessive implementation of measures. For example, a company's internal ordering software for advertising products with only a few personal data does not have to provide a comprehensive and expensive "Privacy Dashboard", which allows employees to perform all functions themselves.
Data Protection by Default (Art. 25(2) GDPR)
The second requirement, Data protection by design, is regulated in Art. 25(2) GDPR:
"The 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. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. 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.“
Paragraph 2 requires the controller to take preventive measures. The software must be configured in such a way that it is already "data protection friendly" in many respects at the time of its initial use. Four criterions are mentioned, the amount, the extent, the storage period, the accessibility:
The software should already collect only as much personal data as necessary for the purposes of the processing. In other words, this requirement basically reflects the principle of data minimisation from Art. 5(1)(c) GDPR. A very good example for this criterion is the authorisations in apps. An app which allows images to be edited must not unnecessarily access the microphone and record voices in the background, access the address book and scan contacts or access the calendar and record appointments.
The criterion 'extent' is not primarily aimed at the quantity of personal data, but at the depth or complexity of the processing. Controllers are encouraged to reconsider each processing step and assess its necessity. In particular, data should not normally be linked or chained, for example for profiling.
The storage period of personal data is a very sensitive issue. On the one hand, controllers must observe and comply with (special) legal retention periods. On the other hand, the principles of data minimisation and storage limitation (Art. 5(1)(c) and (e) GDPR) require that personal data must be erased once the purpose has been achieved or once their retention period has expired. For software, this means that it must provide for possibilities to erase personal data on time. These can be either indicative settings (alerts, push notifications, e-mail notifications), which want to obtain a manual check and erasure, or automated erasure procedures, which carry out the erasure themselves.
The fourth criterion, 'accessibility', relates to the means of access to personal data. For example, software with individual user accounts should not be preset in such a way that users can see all the personal data from one another. Or a software for managing personal data should not, for example, allow an administrator to authorize any user to be a further administrator.
Impacts on Asian Companies
The requirements of data protection by design and default also affect Asian companies. In the following, the reason for this is explained and it is shown what Asian companies would have to pay attention to.
Territorial Scope of the GDPR
The GDPR is not only applicable to companies based in the EU. Every company that offers products and services to consumers in the EU must comply with the data protection requirements of the GDPR. This is regulated within the territorial scope pursuant to Art. 3(2)(a) GDPR.
On 12 November 2019, approximately one year after drafting its Guidelines 3/2018 on the territorial scope of the GDPR, the European Data Protection Board (EDPB) adapted them. In these Guidelines, it emphasises that the absence of an establishment in the EU does not automatically mean that a company would not have to comply with the data protection requirements of the GDPR. The EDPB illustrates this with various examples, such as the following:
A start-up established in the USA, without any business presence or establishment in the EU, provides a city-mapping application for tourists. The application processes personal data concerning the location of customers using the app (the data subjects) once they start using the application in the city they visit, in order to offer targeted advertisement for places to visits, restaurants, bars and hotels. The application is available for tourists while they visit New York, San Francisco, Toronto, Paris and Rome. The US start-up, via its city mapping application, is specifically targeting individuals in the Union (namely in Paris and Rome) through offering its services to them when they are in the Union.
This example shows that the GDPR becomes applicable even if the data subjects are non-residents of the EU.
Review and Adaptation of Software and App Functions
Now that the "extraterritorial" applicability of the GDPR has been clarified, the question arises as to what Asian companies must observe in order to comply with data protection requirements. This is because software products and apps (hereinafter referred to as software) from Asian companies are also offered for use on the European market.
Based on the data protection principles, the requirements can be explained as follows:
Lawfulness, Fairness and Transparency (Art. 5(1)(a) GDPR):
All software must be able to meet the data protection information requirements pursuant to Art. 12 seq. GDPR. Data subjects must be informed about processing in clear and plain language and in a concise, transparent, intelligible and easily accessible form. The data protection notice should be accessible from any page with one click and the link should be clearly visible.
Purpose Limitation (Art. 5(1)(b) GDPR):
The software would have to be programmed so that personal data are processed only for the intended purpose. In particular, a system-sided separation of data records would play a special role here. It should not be possible to link personal data to create personality profiles.
Data Minimisation (Art. 5(1)(c) GDPR):
Only those personal data should be collected from the beginning that are also necessary for the achievement of the purposes. For example, it would not be necessary for a company's internal software for planning trade fair appearances of employees, which has an interface to the ERP, to record not only master data, working hours and vacation time, but also salary data or the tax class of the employees.
Accuracy (Art. 5(1)(d) GDPR):
On the system level, the accuracy of personal data can be guaranteed in various ways. For example, software that has an interface to the CRM could automatically update customer-related data records if the record is first updated in the CRM. Or the software could provide employees with a self-service function that allows them to maintain changes to the data themselves.
Storage Limitation (Art. 5(1)(e) GDPR):
The software could - as already described in section 2.2 - have functions which draw attention to relevant erasure periods and deadlines, for example through an alert or notification function or automated e-mails or small pop-ups and windows which open automatically when the software is used.
Integrity and Confidentiality (Art. 5(1)(f) GDPR):
First of all, the software should enable the configuration of a data protection-friendly roles and rights concept that allows access within an appropriate framework and also logs all actions and processes. Furthermore, the software should only use encrypted connections, such as SSL encryption. It should also work with two or even multi-level mechanisms. If, for example, a user wants to share contents from an app on his profile in a social network, then a small window should open that asks for additional confirmation.
Possible Actions by Supervisory Authorities
Disregarding the requirements of Data protection by design and default may result in fines. According to Art. 83(4)(a) GDPR, a violation of Art. 25 GDPR can be sanctioned with up to €10,000,000 or in the case of an undertaking with up to two percent of the total worldwide annual turnover of the preceding financial year, whichever is higher. However, the supervisory authorities have far more options than just imposing a fine. Within the scope of their corrective powers pursuant to Art. 58(2)(f) GDPR, they may, for example, also impose a temporary or definitive limitation on processing, including a ban. In the worst case, this would mean that the software or app may no longer be operated on the European market.
IT Contract Law
European users wishing to purchase new software will insist in their contracts or in the calls for tenders on compliance with the principle of " data protection by design and default ". Such clauses often are read as follows:
"Software manufacturer is obliged to provide its services in accordance with the principle of data minimisation and to observe the principles of "data protection by design" and "data protection by default" when creating software. Given this background, software manufacturer will in particular perform its service "Evaluation of user behaviour" only with pseudonymised or anonymised data.“
To the extent that Asian software manufacturers cannot prove compliance with this principle in the tendering procedure, they are likely to drop out of the bidding process for software tenders by European institutions and companies for this reason alone. In current IT contracts, non-compliance with the principles would almost certainly constitute a material defect with the consequence that the software manufacturer would have to remedy the defect (unless it is time-barred). If this fails due to the ability or will of the software manufacturer, the user usually has the right to claim damages and/or to end the IT contract by withdrawal or termination.
The principle of " data protection by design and default" is one of the few real "game changers" in the GDPR and should lead to nothing less than a paradigm shift for Asian software manufacturers and software users if they want to remain in business in Europe or with Europeans: Not a more (of personal data) is more, but a less (of personal data) is more!