Joint controller agreement: Benefits and challenges of joint controllership

To many data controllers, the term joint controller agreement (JCA) still conjures up something that is complicated and cumbersome in practice. But they’re wrong! If the JCA is carefully designed, responsible companies can reap many benefits, achieve efficiency gains through forward-looking process design, and operate a correspondingly effective risk management system. This is particularly true for many scenarios in the health sector, where the nature of data processing and the associated technical and organisational measures – in particular the use of encryption mechanisms, electronic signatures and acknowledgement procedures – may give rise to specific requirements (e.g. when processing the personal data of participants in clinical trials or telemedicine services). For example, in the context of clinical trials, it can be particularly beneficial to use a JCA to agree with the other controllers which parties should have what specific roles, responsibilities, and even obligations to inform and cooperate, in the event of access or erasure requests from patients, withdrawal of consent by a patient, or data breaches.

Apart from the potential benefits, organisation are in fact obliged to conclude a JCA if they are joint controllers in practice. If they don’t, they risk being fined.

In this article, we will use some examples from the health sector to show you what is meant by joint controllership, what a joint controller agreement needs to cover, and how a JCA can be structured in a sensible and profitable way for the companies involved.

When is a controller a joint controller?

Joint controllership under Art. 26 GDPR does not only exist when the parties contractually agree on it, but as soon as the conditions are actually met in practice. The specific data protection requirements thus also apply, so companies should always check whether their specific arrangement could give rise to joint controllership under the GDPR.

Unlike in the context of data processing on the controller’s behalf, where the processor is bound by the controller’s instructions, with joint controllership two or more controllers are involved in the data processing. Unlike separate controllers, they must also jointly determine the purposes and means of data processing. This follows from the wording of Art. 26 GDPR, which makes this joint determination the decisive characteristic of joint controllership. There are no fixed criteria for assessing when such joint controllership exists. According to the current Guidelines of the European Data Protection Board (EDPB), however, it exists if more than one entity has a decisive influence on the “whether” and “how” of data processing. With this in mind, it is possible to use some of the indications and clues for certain arrangements that the European Court of Justice (ECJ) has mentioned in several rulings. For example, the European judges do not assume an equal distribution of decision-making power between joint controllers. Joint controllership may also exist where each entity pursues its own purposes, or where not every controller has access to the data to the same extent or at all. It may even be sufficient for an entity to be only partly responsible for the data processing. The concept of joint controllership should therefore be understood in a very broad sense. Separate controllers are more likely to be assumed, for example, where the parties’ purposes are unrelated and one party’s purpose can be well achieved without the involvement of the other.

Identifying joint controllership and distinguishing it from processing on behalf of the controller is of practical importance, as the GDPR contains different requirements regarding the contracts that have to be concluded in each case. Moreover, in order to justify the transfer of data between joint controllers – unlike in the case of processing on the controller’s behalf –a statutory authorisation is always required. In practice, therefore, it makes sense to address the issue early on. In the health sector, particularly in the areas of clinical trials (see also the EDPB guidelines, para. 68), telemedicine, the use of a shared data pool, or when health data is shared within a group of companies, it is advisable that organisations consider whether they might in fact be joint controllers. Joint controllership under data protection law may also exist, for example, in the case of special, new forms of healthcare where the cooperation or involvement of several stakeholders from different areas is necessary or even mandatory (such as the scientific monitoring of new forms of healthcare pursuant to Sect. 92a(1) of Book V of the German Social Code).

What are the implications of a joint controller agreement?

Where data processing involves joint controllers, the parties must conclude a joint controller agreement. In addition, data subjects must be informed of the essential points of the agreement, including in particular the allocation of responsibilities. After all, joint controllers may be jointly and severally liable in the event of fines or claims for damages by data subjects as a result of data breaches. This means that, according to Art. 26(3) GDPR, data subjects can in principle claim against one of the joint controllers for the entire damage. It is up to the controllers to decide how best to share the responsibility. The JCA’s role here is one of documentation and accountability. It makes it easier to assign responsibility for any damage caused. Responsibility for specific damage can be clearly allocated and enforced. In this way, the JCA also serves to establish a balance of liability between the parties.

It is also important for controllers to note that the joint controller agreement should not be used as the sole legal basis for data processing. Although some are in favour of using the joint controller agreement as a legal basis, the overwhelming majority, including the supervisory authorities, take a different view. In practice, therefore, it is important to rely on the general legal bases under Art. 6 and 9 GDPR, as well as any specific legal bases.

What should be included in the joint controller agreement?

Where companies are joint controllers, they should seek to enter into a full joint controller agreement to avoid the risk of infringement and fines. A JCA can be used as a good opportunity to establish clear rules for cooperation between the controllers. In the event of challenges, such as dealing with data protection incidents or requests from data subjects, the agreements can help to ensure that these are dealt with quickly and in accordance with the law. Some content is mandatory in joint controller agreements. Other arrangements are voluntary but often useful.

Mandatory content

In any case, A JCA must cover the purposes and means of the processing. The same applies to the description of the essential functions and roles of the joint controllers, such as which entity in the hospital is in contact with the patients, or which of the stakeholders involved in clinical trials should be the contact point for participating patients who wish to exercise their data protection rights or withdraw their consent. The joint controller agreement also needs to address the internal allocation of responsibilities, in particular who fulfils information obligations, obtains consent, implements and responds to withdrawals of consent, etc. It is important to clearly identify which parties are responsible for fulfilling other rights of data subjects (in particular the rights of access, rectification, restriction of data processing, and data portability). Clinical trials, for example, do not usually work with unencrypted data, but with pseudonymised data sets. In this case, only the entity that manages the pseudonymisation – and can reverse it – will be able to link the data sets to a specific individual and thus fulfil the rights of the data subject. In such scenarios, it may therefore be useful to establish precise rules regarding responsibility and cooperation. These are also helpful in light of the applicable time limits – such as the 72-hour deadline for notifying data protection incidents to the supervisory authority. In the health sector, due to the sensitive nature of the health data processed, there is usually an additional obligation to notify data subjects, which must be done without undue delay.

Useful content

Above all, it makes sense to describe more precisely and concretely the subject matter, nature and scope of the data processing. In practice, it is recommended that organisations include this in their JCA in order to be able to quickly and fully identify data protection incidents and the data involved. Such clauses should ensure that, in practice, it can be determined as quickly and clearly as possible whether certain data is covered by the joint controllership or not. This is important and highly relevant in practice, for example, when a data protection incident has occurred with respect to certain data processed on certain systems (e.g. due to an attack by hackers) and the parties involved must now determine as quickly and reliably as possible – within the 72-hour notification period! – whether the incident involves the joint controllers and thus whether the provisions of the JCA apply with respect to certain responsibilities and processes.

A common contact point can also be agreed. This can be helpful in preventing certain entities involved in data processing from being bogged down by data protection incidents and requests from data subjects that they may not even be able to handle because they lack certain necessary information. For example, in the context of clinical trials, participants may typically contact the sponsor or the clinical research organisation directly to withdraw consent or request access to their data. These organisations may not even be able to relate the data to the named participants, as they only have access to the pseudonymised data. The designation of an appropriate common contact point is recommended by the EDPB (guidelines, para. 184) and may help to direct data subjects to the joint controller best placed to deal with their particular concerns. In this way, unnecessary workload can be kept away from the other controllers and the relevant processes can be designed and defined as cost-effectively and efficiently as possible.

It is also helpful to define common technical standards and technical and organisational measures (TOM). Particularly when transmitting health and patient data, but also in telemedicine, secure measures are necessary to protect the data from unauthorised access and modification and to ensure that it only reaches the intended recipient. This is important not only for data protection reasons, but also because there is a risk that, for example, the wrong patient’s data could be used for treatment, posing a direct health risk to the patient concerned.

An important issue that is of considerable practical relevance for research in the health sector (especially clinical research) is whether and to what extent data, once collected, can later be used for other research projects or evaluations related to the original research project but not specifically planned or even foreseeable at the time of the trial. In order to allow data processing for such secondary scientific purposes (within the limits of what is allowed under data protection law), it is important that all joint controllers involved prepare patient consent and information forms accordingly at the start of the trial – this is known as broad consent. However, it is often precisely the entities that have no direct contact with the patients or trial participants and are not responsible for obtaining patient consent – such as the sponsor or the CRO – that stand to gain the most from such broad consent. This is why these entities should ensure that the exact wording of the patient consent and information forms is agreed upon with the trial sites responsible for obtaining consent. An easy way of doing this is through the JCA.

Examples of other issues which could be useful to cover in the JCA include the implementation of data protection impact assessments, the use of processors, cost and liability issues, and the processing of data in third countries. The latter is already associated with strict data protection requirements, particularly in the health sector. If processing operations outside the EU are envisaged, these should be clearly set out in the joint controller agreement.

What are the challenges in terms of the rights of data subjects?

As already mentioned, the obligation to inform data subjects is a key element of data protection law. The information must be provided in accordance with the requirements of Art. 12 GDPR. In particular, the information must be complete and provided in a “concise, transparent, intelligible and easily accessible form, using clear and plain language”. For the health sector, additional sector-specific regulations must be observed, such as Sect. 40(2) and (2a) of the German Medicinal Products Act (AMG) for clinical trials. Controllers must also obtain the necessary consents for data processing and, where applicable, waivers of confidentiality obligations. Here, too, special standards such as Sect. 40(1) No. 3(b)(c) AMG may be relevant. In this context, data subjects may at any time withdraw their consent or object to certain data processing, both of which should be dealt with quickly and fully. Other rights of data subjects under the GDPR are the right of access (Art. 15), the right to rectification and completion (Art. 16), to erasure (Art. 17), to restriction of processing (Art. 18) and to data portability (Art. 20).

The main challenges for controllers are the sometimes very short deadlines and the fact that data subjects can contact any controller. The latter applies regardless of what is written in the joint controller agreement: each controller to whom a data subject has addressed a request is responsible for processing the request promptly and completely. This is one of the reasons why we recommend setting up a central contact point, so that participants can at least direct their enquiries to the most appropriate place for initial processing and response (in the case of clinical trials, for example, this would be the trial centre).

It should be noted that any failure to fulfil the rights of data subjects may result in fines and that data subjects may lodge complaints with the supervisory authorities. Other challenges include the definition of processes and clear responsibilities between partners, as well as the implementation of technical solutions: responsibilities and processes for handling data subject requests should be aligned as far as possible with existing pseudonymisation management, and it should be possible to search systems using unencrypted data and pseudonyms. Furthermore, it must be possible to erase data properly. For this purpose, regular erasure deadlines for specific data sets must be defined. This should be based on the statutory retention periods that apply to the stakeholders involved in data processing, which are numerous and diverse, especially in the health sector. In addition, it must be possible to export data from the systems used and the allocation of responsibilities should be reflected in appropriate access authorisation policies and the possibility of blocking data for certain data processing operations.

What are the technical requirements for data processing?

Art. 32 GDPR is decisive for the technical requirements. This requires controllers to ensure the security of processing. For this purpose, appropriate protective measures must be taken, taking into account the current state of the art. Due to the increased risk, special attention should be paid to personal data concerning health, and to data transfers. Again, there are often sector-specific requirements to bear in mind, particularly in the health sector. Fines may also be imposed for breaches of the security of data processing. The technical security requirements should be able to ensure the following objectives in particular:

  • Data confidentiality (e.g. through encryption)
  • Data integrity, i.e. protection against undetected change (through control and revision)
  • Data authenticity and availability
  • Data validity
  • Interoperability

In order to ensure technical security as a joint controller, close coordination between all controllers involved in a data processing operation is necessary. With this in mind, it is advisable to make provisions for this in the joint controller agreement as well.

Allocation of responsibilities

On the question of the allocation of responsibility, the ECJ has emphasised in its case law that joint controllership does not automatically imply equal responsibility on the part of all stakeholders. Rather, they could be “involved at different stages of that processing of personal data and to different degrees” (judgment of 5 June 2018 – C-210/16). For this reason, “the level of responsibility of each of them must be assessed with regard to all the relevant circumstances of the particular case”. According to the ECJ, an entity is responsible only for the operation or set of operations that constitute a data processing operation for which it also decides on the appropriate purposes and means. The EDPB also takes the view that joint controllers need to allocate data protection obligations according to the actual circumstances: as long as the joint controllers ensure compliance with the GDPR in the data processing process, there will be some flexibility in terms of sharing obligations. The decisive factor is which of the controllers is in a position to fulfil the corresponding obligations.

Form of the agreement

The controllers’ obligations must be laid down in a transparent manner (Art. 26(1) Sentence 2 GDPR). The standard does not contain any explicit requirement as to the form of the agreement (see also AG Mannheim, judgment of 11 September 2019 – 5 C 1733/19 WEG). Even so, due to the obligation of transparency and the threat of fines, it is advisable to play it safe and record the JCA in writing or electronically. The EDPB guidelines also suggest this for reasons of legal certainty, and to show transparency and responsibility (guidelines, para. 173). In any case, the obligation to make the content available to the data subject presupposes the existence of a durable record and thus requires more than oral communication. It is sufficient for the information to be accessible on a website (for other ways of making the information available, see the EDPB guidelines, para. 181).

Joint controller agreement: Conclusion

The joint controller agreement is more than just another data protection obligation for companies. It can also be a good tool for clearly regulated and coordinated cooperation between multiple controllers. It can help meet the many data protection requirements more quickly and easily, creating clarity between partners and avoiding subsequent costs and fines.

Our experts will be happy to assist you in reviewing your specific data processing situation and drafting customised joint controller agreements.

Learn more

  • Joint controller agreement: Benefits and challenges of joint controllership

    The Joint Controller Agreement (JCA) still seems complicated and cumbersome to many managers in practice. But wrongly so: with the careful design of the agreement, responsible companies can benefit from many advantages, achieve efficiency gains through forward-looking process design and operate a corresponding effective risk management.

    Read more

  • The NIS 2 Directive: Key objectives and regulations

    Last December, the European Council and the European Parliament adopted the Network and Information Security Directive (NIS 2 Directive), thus initiating a reform of the legal requirements for IT security in the European area. After coming into force on 2023-01-16, Germany and the other EU member states now have 21 months to transpose the regulations…

    Read more

  • Anonymisation and pseudonymisation

    Anonymisation and pseudonymisation in practice

    In this article, we look at how the supposed contradiction between data protection through pseudonymisation and the use of personal data in scientific practice can be dealt with. In addition, we take a look at the special challenges that actors in the health care sector face in this topic.

    Read more

The NIS 2 Directive: Key objectives and regulations

Over the past year, Russia’s war against Ukraine has once again shown not only Germany, but the whole of Europe, how tense the cybersecurity situation is in the European region. Even before that, there was ample reason to re-examine the security of European network and information systems and possible threats to the functioning of the European single market. Against this background, the Council and the European Parliament adopted the Network and Information Security Directive (NIS 2 Directive) last December, setting in motion a reform of the legal requirements for IT security in the European area. Following its entry into force on 16 January 2023, Germany and other EU Member States now have 21 months to transpose the regulations into national law and to adapt existing regulations to the new legislation. But affected companies already need to take action. What are the changes and what do companies have to consider now? This article provides an overview.

Purpose of the NIS 2 Directive

There is nothing new about the desire to create a uniform level of security for network and information systems. As the name suggests, the NIS 2 Directive now adopted is a recast of the NIS 1 Directive, which came into force in 2016. This, too, was a response to the heightened threat level and the associated higher demands on IT security in Europe. It was intended to build cybersecurity capacity among Member States by establishing national authorities and single points of contact. In addition to requirements for imposing and taking technical and organisational measures (known as TOMs), it included an obligation to report incidents as well as a system of penalties. It is considered one of the most important pieces of European legislation on cybersecurity. Nevertheless, the EU Commission felt that reform was needed. Why?

Since its implementation, the EU Commission considers the NIS 1 Directive to have been a fundamental success, as it has prompted Member States to rethink cybersecurity concerns and ensured the completion of national legal frameworks on the security of network and information systems. But given the pace of digital change, it was deemed no longer fit for purpose or sufficient to ensure effective cyber defence. The implementation of the directive has also been criticised: in particular, the Commission has complained that penalties are often not properly enforced and that there is insufficient exchange between Member States, especially as regards the categorisation of incidents. Moreover, the scope of the directive proved too narrow.

The NIS 2 Directive aims to remedy this situation. Implementing the EU’s Cybersecurity Strategy for the Digital Decade, which was adopted in 2020, it is intended to bring about standardisation as well as a more in-depth and substantive expansion of the requirements for cyber resilience, thus helping to better protect critical infrastructures and digital services. The provisions of the NIS 2 Directive are based on the those of the NIS 1 Directive, but the requirements, standards and possibilities for control and penalties have been tightened in several places in response to the criticism.

Modified and extended scope

Some of the most important changes relate to the scope of the directive. The previous distinction between operators of essential services and digital service providers will be abandoned now that the NIS 2 Directive has entered into force. Instead, the amended scope now distinguishes between “essential” and “important” entities (cf. Art. 3 NIS 2 Directive). The new subdivision is particularly relevant in the context of the new obligations on institutions and the supervisory and enforcement powers of the competent authorities (more on this below). Which entities are essential and important is identified in the respective Annexes I (“High criticality”) and II (“Other critical sectors”) and is based on affiliation to specific sectors, subsectors and types of entities. In order to avoid too much divergence between the Member States, the exact ceilings for essential and now also important entities are no longer set by the states themselves, but are defined and thus harmonised by the directive. According to this, all enterprises in the critical sectors that employ at least 50 people and have an annual turnover or annual balance sheet total of more than EUR 10 million (medium and large enterprises) are included. Microenterprises and small enterprises (i.e. those below the aforementioned ceiling), on the other hand, are generally exempt. But beware: by way of counter-exception, the new regulations also apply to them, insofar as certain qualifying criteria in Art. 2 II NIS 2 Directive are met, according to which they play a key role for the economy and society. This concerns particular critical services, such as services of public electronic communication network providers or trust services.

The lists of sectors covered have also been significantly extended compared to the old directive. In addition to the sectors already covered by the old directive, the waste water industry, public administration and the aerospace industry are now also named as “essential entities”. “Important entities” now also include postal services, waste management, chemicals, food and manufacturing, as well as digital providers.

Newsletter

Subscribe to our monthly newsletter with information on judgements, specialist articles and events (only in german)

By clicking on “Subscribe” you agree to receive our monthly newsletter (with information on judgements, specialist articles and events) and the aggregated usage analysis (measurement of the opening rate using pixels, measurement of clicks on links) in the mails. You will find an unsubscribe link in every newsletter to withdraw your consent. You can find more information in our privacy policy.

Extended catalogue of obligations for companies

The newly extended catalogue of obligations is likely to be of particular interest to companies. The NIS 2 Directive contains a whole raft of new regulations. It imposes more stringent risk management and reporting obligations on the covered entities than its predecessor.

Incidents and reporting obligation

The existing reporting requirements have been clarified with precise guidelines on the procedure, content and timeframe for reporting an incident. There is a new, broader definition of the term “incident”. Previously, only events that had “an actual adverse effect on the security of network and information systems” (Art. 4 No. 7 NIS 1 Directive) were covered. The reform means that the adverse effect requirement is a thing of the past. Instead, an incident is defined as “an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems” (Art. 6 No. 6 NIS 2 Directive). Therefore, the limited availability of data or services is sufficient for an incident to exist.

If a “significant incident” occurs, an initial notification must be made to the competent authority without undue delay and in any event within 24 hours of becoming aware of the incident (Art. 23(4)(a) NIS 2 Directive) and an intermediate report on relevant updates must be submitted upon request. The entity concerned must submit a final report not later than one month after the initial notification.

TOM

Prevention, another central pillar of corporate cybersecurity governance, has been further strengthened as part of the reform. Essential and important entities must now take appropriate technical and organisational measures (TOM) to manage the risks of a network and information system. The assessment must take into account European and international information security standards and the appropriateness of a measure in light of the entity’s individual risk exposure.

In Art. 21(2), the NIS 2 Directive lists various examples of measures:

  • risk analysis
  • crisis management
  • supply chain security
  • policies and procedures to assess the effectiveness of risk management measures
  • use of cryptography and encryption

Supervisory powers, enforcement measures and administrative fines

Particularly in the context of supervisory and enforcement measures, the new distinction between essential and important entities becomes clear. Overall, the NIS 2 Directive provides for stricter supervisory instruments. For example, the authorities can now carry out on-site inspections and request certain information and data access. While a reactive supervisory system applies to important entities (cf. Art. 33 NIS 2 Directive), essential entities (cf. Art. 32 NIS 2 Directive) are subject to much more far-reaching supervisory powers. This allows for measures not related to specific events, such as audits, and this is independent of the risk assessment.

With regard to the means available to the Member State authorities to enforce the obligations, in principle, the same measures can be imposed on operators of important entities as on operators of essential entities. Authorities have a wide range of instruments at their disposal. For example, they can issue binding instructions, set deadlines, impose fines and – only in the case of essential entities – as an ultima ratio, temporarily relieve management of their duties. In the event of infringement, severe administrative fines may be imposed in accordance with Art. 34(4) and (5) of the directive: for operators of essential entities, the maximum fine is either €10 million or 2 per cent of worldwide annual turnover; for operators of important entities, the maximum fine is €7 million or 1.4 per cent of worldwide annual turnover, whichever is greater. Enterprises are to be understood in the context of European law, so that the economic unit is to be considered (all legal and natural persons and partnerships). It remains to be seen, however, whether the strict administrative fines of the NIS 2 Directive can also be imposed on public administration entities in Germany. The EU has left this question to the Member States to regulate in their implementing laws (Art. 34(7) NIS 2 Directive).

How this relates to the GDPR

Companies applying the NIS 2 Directive should always consider the provisions of the GDPR in the event of a significant incident. After all, it is quite conceivable that a significant incident could also involve personal data. In this case, the incident must still be reported to the data protection authority pursuant to Art. 33 GDPR within a reasonable period of time, regardless of whether it has already been reported in accordance with the provisions of the NIS 2 Directive (see Art. 32(1) of the directive).

The only overriding rule involving the NIS 2 Directive and relating to the GDPR relates to administrative fines: if the data protection authority imposes an administrative fine under the GDPR, a fine under Art. 31(4) NIS 2 Directive for the same infringement is excluded. However, other enforcement measures are still possible.

Framework for European Cybersecurity Strategy and cooperation

At the same time, the directive includes a push to strengthen the European Cybersecurity Strategy and improve cooperation between Member States. As well as requiring Member States to develop a national cybersecurity strategy that can be monitored against performance indicators, the directive also requires them to take greater account of supply chain protection. If not already in place, state computer security incident response teams (so-called CSIRTs) must also be established to foster trust and operational cooperation between Member States within a network. Each Member State must also designate an authority responsible for cybersecurity and for the oversight tasks under the directive. In Germany, the BSI (Federal Office for Information Security) is generally responsible. With a view to improving cyber crisis management, an EU Cooperation Group will also be set up to facilitate the exchange of information and a European vulnerability database will be established by the European Union Agency for Cybersecurity (ENISA). Another new feature is that Member States will be subject to subsequent “cybersecurity peer reviews” to assess their cybersecurity measures.

Conclusion and outlook

The NIS 2 Directive introduces a number of innovations to equip the EU for the increased cybersecurity requirements. The reform entails a number of obligations, both for Member States and for the companies concerned. Entities that are now covered by the directive for the first time will have to increase their cybersecurity budget by around 22 per cent. This is the conclusion of the European Commission’s impact assessment of the NIS 2 Directive. On the other hand, companies that already had to take measures under the previous directive can expect additional costs of around 12 per cent. Apart from this, affected companies are advised not to consider the new directive in isolation in relation to the necessary changes, but rather in the context of the wider body of relevant European law. It is conceivable that the addressee of the NIS 2 Directive could also be the addressee of other related European legislation. For example, in addition to the GDPR discussed above, the application of the AI Act or the Digital Security Act may also come into question, depending on the case.

It remains to be seen how the German legislator will adapt the current law based on the innovations of the NIS 2 Directive. By 16 October 2027, the functioning of the directive must be reviewed before its predecessor is repealed with effect from 18 October 2027.

Learn more

  • Joint controller agreement: Benefits and challenges of joint controllership

    The Joint Controller Agreement (JCA) still seems complicated and cumbersome to many managers in practice. But wrongly so: with the careful design of the agreement, responsible companies can benefit from many advantages, achieve efficiency gains through forward-looking process design and operate a corresponding effective risk management.

    Read more

  • The NIS 2 Directive: Key objectives and regulations

    Last December, the European Council and the European Parliament adopted the Network and Information Security Directive (NIS 2 Directive), thus initiating a reform of the legal requirements for IT security in the European area. After coming into force on 2023-01-16, Germany and the other EU member states now have 21 months to transpose the regulations…

    Read more

  • Anonymisation and pseudonymisation

    Anonymisation and pseudonymisation in practice

    In this article, we look at how the supposed contradiction between data protection through pseudonymisation and the use of personal data in scientific practice can be dealt with. In addition, we take a look at the special challenges that actors in the health care sector face in this topic.

    Read more

Anonymisation and pseudonymisation

Anonymisation and pseudonymisation in practice

Whether communicating by email or videoconference, or working with customer or employee data, dealing with personal data is part of our everyday professional (and personal) lives. The fact that data protection must play a paramount role in companies and public authorities is nothing new. But how can data protection be guaranteed when the use of protected data is at the heart of a research project, and the project cannot be carried out without the information provided by the data? Anonymisation and pseudonymisation play a central role in meeting this challenge. They make it difficult or even impossible to (re)attribute data to a specific person. The particular difficulty here is to maintain the usability and informative value of the data while pseudonymising it. In this article, we look at how the supposed contradiction between data protection through pseudonymisation and the use of personal data can be dealt with in research practice. We also take a look at the particular challenges that stakeholders in the healthcare sector face in this regard.

What does anonymisation mean?

Strictly speaking, anonymisation is not mentioned at all in the legal text of the GDPR, with only Recital 26 explicitly referring to “personal data rendered anonymous”. For a legal definition, we therefore need to refer to the Open Data Directive 2019/1024: “Anonymous information is information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or is no longer identifiable.” The decisive factor is that it is no longer possible to identify a person, i.e. the specific person about whom the information provides information can no longer be determined. In this respect, data protection law shifts its protection forward to the moment when the identification of natural persons is only potentially possible, rather than having already taken place. However, without the ability to attribute data to a specific individual, the GDPR no longer needs to be applied, as there is no longer an individual to protect under data protection law.

This means that in practice the possibility of identifying the person should actually be excluded in order to avoid violations of the law. According to the European Court of Justice (ECJ, judgment of 19 October 2016, C-582/14), a person is already identifiable within the meaning of the GDPR if conclusions can be drawn only indirectly about their identity. In this case, the ECJ ruled that even dynamic IP addresses, i.e. those that do not contain direct information about the person accessing the website, can constitute personal data for a website operator. It is irrelevant that the additional information required to identify an individual is not available from the provider of the service itself, but from the internet service provider – because the former has the possibility, under certain circumstances, to demand that the internet service provider link the data to the individual. This is precisely what is relevant under Recital 26 of the GDPR: “To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, (…) either by the controller or by another person to identify the natural person directly or indirectly.” Consequently, anonymisation does not require that identification be objectively impossible for everyone – rather, so-called “de facto anonymity” is sufficient. But the standards are high. According to the judgment, it is not necessary for a possible re-identification “that all the information enabling the identification of the data subject must be in the hands of one person”. Companies should therefore not be too quick to assume that data is anonymous and that data protection law does not apply.

How can data be anonymised?

The GDPR only sets out the framework conditions for anonymisation. In practice, this means that data usually needs to be technically modified to a greater extent than simply adjusting or removing the person’s name in a data set. For example, if a pharmaceutical company is developing a vaccine against a virus and is conducting a clinical trial on a few hundred people, this will generate a large amount of data on the subjects. This may include each person’s name, address, age, weight, information about pre-existing conditions, etc. Even if the company were to remove the name and address of the individual, as this information is not needed for the purpose of the study, it may still be possible to identify individuals without much effort, based on their pre-existing conditions and age, or medications they are taking, and so on. In such a case, there is no question of anonymisation.

There is no general rule as to what measures should be taken to achieve complete anonymisation, but data sets should be modified in such a way that any possible combination of data in the data set results in at least two hits or can be traced back to at least two different individuals. It goes without saying that the higher the number of hits, the better and safer the result. The more specific the information, the more the data set will need to be modified. In addition to not disclosing or erasing data, in practice there are some other anonymisation techniques that controllers can use.

The generalisation/coarsening method enlarges the scale of the data sets to prevent any attribution to individuals. For example, subjects can be divided into age groups, which then replace their exact age. Again, care must be taken not to render the data useless by over-generalisation. By randomly swapping columns in a table, groups of data can be reassigned to other groups of data while other columns remain unchanged. As this can cause statistical correlations to be lost, some of the methods are adapted so that only similar values are swapped – so that, for example, swapping diagnoses for people of the same sex does not change the statistical picture, but preserves the correlations between sex and disease.

So-called “noise” introduces fictitious measurement errors, which slightly manipulate the data without changing the overall picture conveyed by the statistics. This can be done, for example, by changing a person’s date of birth from 5 to 10 April or similar. Also, completely new, artificial data can be created to replace the original data – where the newly generated data set is based on a statistical model created from the original data. It is also possible to simply reduce the number of people represented in a data set. To do this, individual lines are omitted entirely or only revealed at random. Again, it is important to maintain statistical information as much as possible.

None of the above methods can completely eliminate the risk of re-identification. If an attacker gains access to other data that is combined with the anonymised data, they may be able to re-establish an individual’s identity. This is why it is often useful and advisable to combine several anonymisation techniques in order to achieve secure anonymisation.

Pseudonymisation and the attribution of additional knowledge

Unlike anonymisation, it is sufficient for pseudonymisation to separate identity data from information data (Art. 4 No. 5 GDPR). This means that attribution of the pseudonymised data to an individual is still possible using the associated key, which is why the data should still be considered personal data in accordance with Recital 26, Sentence 2 of the GDPR. The “pseudonymisation key” has to be kept separately and under special protection. As such pseudonymisation itself is one of the appropriate technical and organisational measures to protect personal data, and the GDPR still applies to pseudonymised data. This is because as long as it is possible to re-attribute data to a specific individual, this EU regulation applies. This conclusion is not a problem, at least in the case where the pseudonymised data and the corresponding key are held (albeit separately) by the same controller.

The situation might be different if the data necessary for re-identification were not held by the controller but by a third party, and the former had only the pseudonymised data without any possibility of identification. If this additional knowledge of a third party is inaccessible to the controller, i.e. if there is no relationship between the two entities, this could result in de facto anonymisation. This is partly supported by the argument that it must be possible in practice to re-attribute the data to a specific individual in order to be able to assume that the data is personal in nature. In some cases, it is even required that, in addition to the mere practical possibility, there must also be a subjective intention on the part of the controller in order for the GDPR to apply. This broad interpretation of anonymisation is challenged by others who argue that there is always the possibility of attributing data to an individual person if additional knowledge is held by a third party, regardless of the circumstances under which and by whom it can be accessed. The ECJ’s position in this argument was already explained above – according to the case law, additional knowledge held by third parties is attributable (and the GDPR applicable) if access to that additional knowledge by the controller can reasonably be expected. Ultimately, ambiguity in this area cannot be completely eliminated.

In practice, pseudonymisation often uses the hashing method, which replaces certain values with strings. Encryption techniques are also used, where a cryptographic algorithm is used to create an encrypted value from plaintext. Alternatively, pseudonyms can be randomly generated and stored in tables. While encryption allows the original value to be easily recalculated using the key, the hashing process is not easily reversible. In terms of data protection compliance, a comprehensive and technically reliable access and authorisation policy is also important here. There are different levels of pseudonymisation, so both strong and weak pseudonymisation are possible. Strong pseudonymisation is particularly necessary when special categories of data are processed according to Art. 9 of the GDPR, such as data concerning health, or when the data is exposed to an increased risk.

Remember the legal basis!

According to the GDPR, every type of data processing requires a legal basis in order to be legally compliant. However, it is often overlooked that the anonymisation and pseudonymisation of data are themselves a form of data processing. Even if at first sight both instruments have an exclusively positive impact on data protection, it should be noted that the loss of data can also adversely affect the rights and freedoms of data subjects. In principle, all legal bases of Art. 6 of the GDPR come into consideration, in particular legitimate interests, performance of a contract, and consent. Special legal bases may also be used, such as Sect. 27 of the German Federal Data Protection Act (BDSG) for scientific research or statistical purposes.

What are the advantages and disadvantages?

The advantage of anonymisation is obvious: if data cannot be attributed to individuals, and the GDPR therefore does not apply, the controller is relieved of the burden of complying with data protection requirements. However, companies should carefully consider beforehand whether it is even possible to completely eliminate the possibility of attributing data to individuals, and how much effort is likely to be involved. Some even argue that “genuine” anonymisation is practically never possible, as with big data, for example, there is always the possibility of re-identification. According to a 2019 study carried out by research institutions including Imperial College London and the Université catholique de Louvain in Belgium, in all the data sets examined 99.98 % of US citizens could be identified on the basis of just 15 characteristics, such as age or place of residence; in 80 % of cases, only the three characteristics of gender, date of birth and postcode were sufficient for re-identification in supposedly anonymised data sets. So it is clear that this issue merits special attention. On the other hand, it is necessary to check whether the data set will still be usable after it has been anonymised.

The process of pseudonymisation, on the other hand, does not exempt the controller from complying with the requirements of the GDPR. Pseudonymisation may work in favour of the controller’s legitimate interests in data processing. This is because the stronger the pseudonymisation, the more likely it is that the interests of the company (or the controller) will prevail, as the data subjects will be better protected under data protection law. In addition, the requirements for technical and organisational measures to protect data processing processes will be reduced. Attacks on the protected data can then only be carried out by singling out, linking or inference. Singling out involves attackers isolating data that relates to individuals, or attempting to combine multiple pieces of data and draw conclusions. Linking is the process of linking multiple data sets to identify correlations. Inference is the process of determining personal information by making logical deductions from the combination of certain data sets. If controllers are aware of these risks of attack, it will be easier for them to choose the appropriate pseudonymisation procedure and thus to eliminate as many of the risks of re-identification as possible.

Newsletter

Subscribe to our monthly newsletter with information on judgements, specialist articles and events (only in german)

By clicking on “Subscribe” you agree to receive our monthly newsletter (with information on judgements, specialist articles and events) and the aggregated usage analysis (measurement of the opening rate using pixels, measurement of clicks on links) in the mails. You will find an unsubscribe link in every newsletter to withdraw your consent. You can find more information in our privacy policy.

Special case: Anonymisation and pseudonymisation in the healthcare sector

Dealing with data, especially large amounts of it, is unavoidable in the healthcare sector – whether it is for treatment in hospital, or for handling CT scans or X-rays. More and more people are using health apps that collect data about their physical condition. Findings from clinical trials can also help to improve diagnostic and therapeutic options. All of these cases involve data concerning health, which is one of the specially protected categories of data pursuant to Art. 9 of the GDPR and the processing of which is subject to additional requirements.

The healthcare sector also poses particular challenges for anonymisation. Given the great potential of using data concerning health for research purposes, which was illustrated particularly clearly during the coronavirus pandemic, researchers often complain that data protection rules are an obstacle to the freedom of science and research. The appeal to clear the way for research with health-related data is directed in particular at the national government – because other EU countries, such as Finland, already make this possible in a much simpler way. However, in order to ensure that health-related data cannot be attributed to a specific person, advanced anonymisation methods are needed that can cope with the sheer diversity of such data – after all, medical studies analyse not only information in tables, but also image data (such as X-rays) or samples and voices.

This is not the only reason why it makes sense to use pseudonymisation methods in the healthcare sector. As it is possible to restore the possibility of attributing pseudonymised data to individuals (see above), this procedure is also suitable for informing study participants of new findings at a later stage. This can be essential, for example, to help those affected by a genetic disease to schedule important screening tests or learn about new treatment options. Especially in the case of rare diseases, it is hard to imagine real progress without data being stored in a database for a long time – and possibly later used for other purposes that were not foreseeable at the time the database was created, but which are useful for the patients concerned. Doctors regularly report that people with rare diseases, in particular, want to be kept informed of progress long after they have participated in a trial, as this is often their only hope of a cure. This complex situation ultimately means that the way in which data protection requirements are implemented will always depend on the nature and scope of the use of medical data. But it is clear that there are few other areas where innovation and progress depend so much on the timely translation of regulatory requirements into practical guidance for doctors and researchers.

Conclusion

Many practical and legal challenges need to be addressed when anonymising and pseudonymising data. Pseudonymisation is clearly more practical than anonymisation, where it is often not possible to be certain that the possibility of attribution to individuals has been completely and irrevocably removed, especially as anonymous data is often not as valuable for research as personal data. Nevertheless, both instruments are suitable for striking a balance between the data subject’s right to “informational self-determination” and the freedom of science and research. It is also clear that personal data must be made usable for research and science, and that this calls for practical solutions. A good example of this is the European Health Data Space Regulation proposed by the Commission, which provides for the cross-border exchange of health data within the EU.

It is therefore advisable to decide between the two procedures according to the purpose that the data must fulfil after the removal or dilution of the possibility of attribution to individuals. In some cases, it will be necessary to use pseudonymisation anyway, because the restoration of this possibility is required by law – for example, in the case of the obligation to document medical treatments under Sect. 630f of the German Civil Code (BGB). In other cases, it may simply be desired, or it may be in the interest of a medical trial, for example, where the data protection principle of purpose limitation collides with a long-term interest in acquiring knowledge. Furthermore, as absolute anonymisation is very difficult to achieve, it is advisable to assume the applicability of the GDPR in case of doubt. Although pseudonymisation cannot completely eliminate data protection measures, it is still a good tool to at least reduce the effort associated with them. In this way, it can at least facilitate the use of personal data for research and other innovative purposes. It is to be hoped that, in the foreseeable future, there will be consensus on the concrete requirements for anonymisation – and whether, in practice, relative anonymisation can be sufficient.

Do you have questions about anonymisation and pseudonymisation? We would be happy to help. Contact us to arrange a no-obligation consultation

Learn more

  • Joint controller agreement: Benefits and challenges of joint controllership

    The Joint Controller Agreement (JCA) still seems complicated and cumbersome to many managers in practice. But wrongly so: with the careful design of the agreement, responsible companies can benefit from many advantages, achieve efficiency gains through forward-looking process design and operate a corresponding effective risk management.

    Read more

  • The NIS 2 Directive: Key objectives and regulations

    Last December, the European Council and the European Parliament adopted the Network and Information Security Directive (NIS 2 Directive), thus initiating a reform of the legal requirements for IT security in the European area. After coming into force on 2023-01-16, Germany and the other EU member states now have 21 months to transpose the regulations…

    Read more

  • Anonymisation and pseudonymisation

    Anonymisation and pseudonymisation in practice

    In this article, we look at how the supposed contradiction between data protection through pseudonymisation and the use of personal data in scientific practice can be dealt with. In addition, we take a look at the special challenges that actors in the health care sector face in this topic.

    Read more

Cybersecurity and data protection: Challenges for companies

With the digital revolution, the future has well and truly arrived in the business world – be it through almost limitless networking possibilities or the ability to work virtually anywhere. By using the very latest in IT solutions, however, future-oriented companies are becoming increasingly dependent on technology. As companies shift every aspect of their business from the analogue to the digital world, they provide hackers with more and more targets for cyberattacks. And then there is the human risk factor: a single careless act can jeopardise protected infrastructures, be it through the use of insecure passwords, opening an email with an infected attachment or link, or the (accidental) disclosure of information. Increasingly complex attacks call for increasingly professional technologies to defend against the sophisticated methods employed by cybercriminals. According to a study, the question is not so much whether a company will suffer a cyberattack, but rather when and how the attack will take place – and how serious its effects might be. Good risk management, strong technical and organisational measures, and a careful strategy are therefore all the more important for cybersecurity within companies!

Types of cyberattacks

A cyberattack is a malicious attempt to compromise IT systems. By launching a targeted attack on a specific information technology structure, hackers or criminal organisations attempt to plant malware inside IT systems in order to cause damage. While some attacks are politically motivated, many hackers are driven by the desire for financial gain when stealing data. Selling stolen data or extorting ransoms can be quite lucrative.

Cyberattacks come in many different forms and are becoming more and more sophisticated. Most attacks are highly complex, making traceability very difficult.

Among the most prominent means and methods for cyberattacks are:

  • Spam emails
  • Malicious software (malware or junkware)
  • Drive-by exploits
  • Brute force attacks
  • DDoS attacks
  • Phishing emails
  • Ransomware

What threats are associated with cyberattacks?

The goal of most cyberattacks is to steal data, whereby personal data is of particular economic value, as evidenced by data-driven business models. Cyberattacks can also encrypt data on which a company depends in order to operate successfully. The data is then usually only released after a considerable ransom has been paid. The economic impact can be enormous, as can the damage to the company’s reputation if the attack becomes known to the public. This is often accompanied by damage to the company’s internal data infrastructure, which is the foundation of any digital company – possibly resulting in operational disruptions or even preventing the company from operating altogether. The misuse of data is also a major threat for affected companies.

Some cyberattacks are a form of industrial espionage, for example with the aim of gaining competitive advantages by stealing information about the victim’s corporate strategy.

Another inherent threat in cyberattacks is the manipulation of communication channels. In a “man-in-the-middle attack”, for example, hackers can eavesdrop on communications between several parties in order to steal information or even manipulate the content before sending it on to the intended recipient.

It is important to note that any such attack triggers legal obligations. Especially when personal data is involved, the regulations of the General Data Protection Regulation (GDPR) must be observed. Companies that process personal data are obliged to ensure the appropriate security of personal data and to report data protection incidents. The principle of integrity and confidentiality includes, among other things, protecting data against accidental loss and damage as well as unauthorised processing (cf. Art. 5(1)(f) GDPR).

How to respond to a cyberattack

Spread the word internally: If a cyberattack occurs, it makes sense to immediately contact the relevant units, such as your information and IT security officers. In addition, the data protection officer, the IT department and of course management should be informed of the attack. They can then take immediate action based on an incident response plan.

Convene the crisis team: Especially in situations that call for swift and prudent action, it makes sense to run things past a crisis team set up specifically for this purpose, in order to avoid a chaotic internal response and to take uniform action against the attack. It is essential to involve the aforementioned internal units in the crisis team, as well as whichever department has been targeted.

Collect information: In order to stop an attack that has already begun, as well as to be able to prevent future attacks, it is sensible to collect certain information about the attack. Among other things, this includes investigating how the attack came to light, what impact the attack may have on the company’s core services, why the attack happened, and the likely impact on third parties such as customers or business partners.

Comply with notification obligations: Furthermore, it may be necessary to notify the competent data protection supervisory authority and the data subjects affected by the attack. Under certain conditions, companies are subject to this obligation under the GDPR.

Depending on the incident, it may also be advisable to bring the attack to the attention of law enforcement authorities and file a criminal complaint.

To put an end to the attack, it usually makes sense to take the affected system – the one used as a gateway by the hackers – offline. In some cases, however, the only way to overcome a cyberattack is to completely reinstall the affected system, as it is usually the entire system that is considered compromised. Cybercriminals use a variety of methods, some of which can cause damage even on a network that has been taken offline. For this reason, companies should be sure to create regular back-ups and store them securely and separately from the rest of the infrastructure.

What cybersecurity steps can companies take?

Cybersecurity is all about taking protective measures to secure and protect systems, networks and programs from unauthorised digital access.

Companies take cybersecurity measures in order to ensure the confidentiality of data and information. In addition, they aim to protect the integrity of personal data. Another goal of cybersecurity is to protect the availability of information used in the company against threats from cyberspace.

Cybersecurity should therefore be embedded as part of the company’s internal risk management. Companies should rely on a combination of strategy, technology and user awareness training. With the right cybersecurity risk management, internal vulnerabilities can be identified and administrative solutions and measures found to offer appropriate protection to the company and its digital infrastructure.

Possible cybersecurity measures

In order to prevent cyberattacks, it is advisable to take preventive measures to protect the company’s internal structures.

It is sensible to implement security gateways for individual network transitions, such as a proxy firewall (also called an application firewall or gateway firewall). A proxy firewall is essentially a security system for a communication network. Using a proxy firewall, no direct connection is established between your own network and another network such as the internet. The firewall is placed between the networks. It filters all requests from the internet, for example, either forwarding them or blocking them. This allows harmful viruses or similar to be detected and warded off before they have a chance to enter your own system.

Furthermore, system segmentation, i.e. the division of computer networks into several smaller subnetworks, is often a successful tool in preventing cyberattacks. With network segmentation, companies can determine whether all network traffic should only remain within one part of the network, or whether it – or at least certain categories of it – should be allowed to pass over into other network segments. This makes it more difficult for hackers and cybercriminals to penetrate the entire network, as the different segments are not connected to each other.

It is also essential to implement a patch management system that identifies software updates and “patches” and makes these available on endpoints such as computers, mobile devices or servers. Installing updates and patches regularly and at short notice is an effective means of eliminating software vulnerabilities that could otherwise be exploited as gateways for cyberattacks. By using patch management, companies can reduce the security risks associated with software and applications. Employees should therefore be made aware of and obliged to install updates and use the latest version of a given application. As far as possible, regular updates should be enforced technically.

The software used by employees should be equipped with effective virus protection from the outset anyway. Ideally, this will prevent malware from infiltrating systems in the first place. It also makes sense to use two-factor identification wherever possible. This can better ensure that only authorised persons ever have access to systems. Effective password management that mandates strong passwords also increases the security of IT systems. Since IT security breaches are often caused by employees clicking on an infected link or similar, employee training is also an effective measure. Regular staff training and clear rules of conduct on the part of the company can raise awareness of cyberattacks before they happen.

AI-based tools that are embedded in the system as a defence against cybercrime and can detect and ward off attacks fully automatically can be particularly effective.

There are already some frameworks on the market for cybersecurity risk management that can also be used to identify measures. Well-known frameworks include ISO 27001 and the BSI-Grundschutz certification process. It is important to document any measures taken.

Conclusion

Cybersecurity and good risk management serve to protect companies from threats to their systems. Anyone who wants to be armed against ransomware, malware and other cyberattacks needs robust cybersecurity. Regularly reviewing your cybersecurity strategy can reveal vulnerabilities in your own company well before an attack occurs and ward off cyberattacks. Nevertheless, it is not possible to be completely protected against all cyberattacks at all times, which is why your company should know exactly how to act in the event of an IT security breach. In particular, it is advisable to document all measures taken – so that the system can be reviewed regularly, but also in order to comply with your accountability requirements under the GDPR (cf. Art. 5(2) GDPR). The Federal Office for Information Security (BSI) also provides companies with comprehensive information on how to manage, report and prevent incidents.

Feel free to contact us – our data protection experts will support you in developing a suitable cybersecurity strategy for your company!

Learn more

  • Joint controller agreement: Benefits and challenges of joint controllership

    The Joint Controller Agreement (JCA) still seems complicated and cumbersome to many managers in practice. But wrongly so: with the careful design of the agreement, responsible companies can benefit from many advantages, achieve efficiency gains through forward-looking process design and operate a corresponding effective risk management.

    Read more

  • The NIS 2 Directive: Key objectives and regulations

    Last December, the European Council and the European Parliament adopted the Network and Information Security Directive (NIS 2 Directive), thus initiating a reform of the legal requirements for IT security in the European area. After coming into force on 2023-01-16, Germany and the other EU member states now have 21 months to transpose the regulations…

    Read more

  • Anonymisation and pseudonymisation

    Anonymisation and pseudonymisation in practice

    In this article, we look at how the supposed contradiction between data protection through pseudonymisation and the use of personal data in scientific practice can be dealt with. In addition, we take a look at the special challenges that actors in the health care sector face in this topic.

    Read more

Rights of the data subject under the GDPR: An overview

The EU-wide General Data Protection Regulation (GDPR) came into effect on 25 May 2018. Ever since then it has presented companies with enormous challenges. Especially in the area of what are known as the rights of the data subject, many things have changed compared to the previous legal situation. Data subjects have been given a variety of tools to help them monitor and manage how their personal data is handled. Since the GDPR came into effect, the supervisory authorities in Germany and other EU countries have already imposed a large number of administrative fines, many of them for non-compliance with the rights of data subjects. The list ranges from not granting access, to missed deadlines and failing to delete data despite the right to erasure. The right to data portability under Art. 20 GDPR also poses a major challenge for companies.

What are “rights of the data subject”?

Rights of the data subject means the rights of any individual affected by data processing pursuant to Art. 12 et seq. GDPR. They protect the right to “informational self-determination” (Art. 2(1) in conjunction with Art. 1(1) of the German constitution) and serve to provide information and transparency.

Art. 12(3) GDPR stipulates that data subject requests must receive a response “at the latest” within one month. An extension for a further two months is possible in exceptional cases. However, this extension is not justified by arguing, for example, that the company is generally too busy to respond sooner, but must be considered on a case-by-case basis.

What rights of the data subject does the GDPR define?

1. The controller’s duty to inform (Art. 13, 14 GDPR).

Art. 13 and Art. 14 GDPR together form a single complex. Together with Art. 15 GDPR, the provisions constitute an essential component (“Magna Carta”) of the rights of the data subject. It is only through the information obtained with the help of Art. 13 GDPR that the data subject can properly assess a data processing operation and properly exercise their rights as a data subject. Art. 13 GDPR is therefore of fundamental importance.

The EU legislator has fleshed out the principles of fair and transparent processing by specifying certain information which the controller is obliged to provide. In this sense, Art. 13(1) GDPR stipulates that the data subject must be informed above all of the contact details of the controller, the purpose (for each individual data processing operation separately) and the duration of the data processing, as well as information about the recipients of the personal data, the legal basis of the data processing, and a comprehensible explanation of how the interests of the data subject were weighed against those of the controller.

According to Art. 13(1) and (2) GDPR, the data subject must also be informed of all rights of the data subject, i.e. that they have a right of access, a right to rectification, to erasure, to restriction of processing, a right to object, and a right to data portability. What’s more, the data subject must be informed about the extent to which decision-making is based exclusively on automatic data processing (especially profiling). It is important to note here that the data subject must be provided with all this information where the data is collected, e.g. when subscribing to a newsletter or concluding a purchase contract online, but possibly even before concluding a purchase contract, e.g. when registering for a user account. Art. 12(1) GDPR requires that the information to be provided to the data subject is presented in a “transparent, intelligible and easily accessible form, using clear and plain language”. This means that the respective addressees must be able to understand the information – so privacy notices, for example, should avoid ambiguous wording, foreign words and complicated syntax and instead use more everyday language. Under the GDPR, the information can be provided orally, in writing or electronically. Particularly with regard to children, attention must be paid not only to the aforementioned obligation to use simple language, but also so the fact that the language is appropriate for the age group. According to Art. 13(4) GDPR, the obligation to provide information only does not apply if the data subject already has the necessary information when their data is processed. If there is any doubt, it is up to companies to prove this.

Newsletter

Don’t miss any updates on data protection, information security and compliance. Subscribe to our newsletter today (only in German)!

By clicking on “Subscribe” you agree to receive our monthly newsletter (with information on judgements, specialist articles and events) and the aggregated usage analysis (measurement of the opening rate using pixels, measurement of clicks on links) in the mails. You will find an unsubscribe link in every newsletter to withdraw your consent. You can find more information in our privacy policy.

Art. 14 GDPR also regulates corresponding information obligations in the event that the data was not collected by the controller itself, but by third parties (e.g. information about creditworthiness obtained from credit agencies). Where data was collected from third parties, the company’s information obligations are basically comparable to those under Art. 13 GDPR. In addition, the company has a duty to disclose the source of the information. Unlike under Art. 13 GDPR, the information does not have to be provided immediately in all cases, but at the latest within a maximum period of one month after obtaining the data. If, however, the personal data is to be used to communicate with the data subject, the notification has to be given no later than when the first contact is made.

2. The controller’s active duty to inform corresponds to the data subject’s extensive right of access (Art. 15 GDPR)

Art. 15 GDPR grants a right to comprehensive information regarding the personal data processed as well as specific circumstances of the data processing. This right of access is limited by conflicting rights of third parties. This has the particular consequence that access does not have to be given to information pertaining to trade secrets. Art. 15 GDPR is highly relevant in practice and is likely to become even more so in the future.

The right of access is structured in two stages. The first stage gives the data subject the right to know whether or not personal data concerning them is being processed. If this is not the case, the controller must inform the data subject accordingly. If the data subject’s data is being processed, then the second stage gives the data subject a right of access to that personal data and to certain additional information.

In order to establish this right, the data subject may request access to information about data processing at reasonable intervals. In principle, there are no formal requirements for requesting access. In the event of a data subject access request, the controller must above all provide information about the purpose of the data processing, the categories of personal data processed and the recipients or categories of recipients to whom the data may have been disclosed.

In addition, the right of access covers further information such as

  • The envisaged storage period or the criteria used to determine that period
  • Information about the individual rights of the data subject (such as the right to rectification, erasure, restriction of processing, right to object, right to lodge a complaint with a supervisory authority)
  • The existence of automated decision-making, including profiling, and any further consequences
  • In the case of data transfers to third countries or to international organisations, information about appropriate safeguards.

In addition, pursuant to Art. 15(3) GDPR, the data subject has a right to receive a copy of the personal data undergoing processing free of charge. The controller may charge a reasonable fee for any further copies. The data subject is not considered to be requesting a “further” copy if they submit a new request for access and the data held by the controller has changed significantly since the last copy was sent. However, there is still a great deal of controversy in terms of what and how much exactly is covered by the right to a copy of the data. The information to be provided by the controller can be very extensive indeed, depending on the amount of data involved. In these cases, it is advisable to prepare the data accordingly as part of the access process – a process which should be integrated into ongoing business processes well in advance.

3. The right to rectification (Art. 16 GDPR)

If the data subject’s personal data has been processed incorrectly, the data subject has the right to rectification without undue delay. The right of the data subject to rectification is closely related to the right of access under Art. 15 GDPR. Without the right of access to the personal data concerning them, the data subject would not be able to exercise their right to rectification. The right to rectification has two components: the data subject may request both that inaccurate data be rectified and that incomplete data be completed or supplemented.

4. The right to erasure (Art. 17 GDPR)

The right to erasure (Art. 17 GDPR) is also known as the “right to be forgotten”. The data subject has the right to obtain from the controller the erasure of personal data concerning them without undue delay and the controller has the obligation to erase personal data without undue delay where one of the following grounds applies:

  • Storing the data is no longer necessary in relation to the purposes for which it was collected
  • The data subject withdraws the consent to data processing which they gave previously
  • The data subject has objected to the processing and there is no legitimate interest in the processing (in the case of Art. 21(2) GDPR, erasure must take place regardless of the controller’s interest in the processing)
  • The data has been unlawfully processed
  • The company is obliged to erase the data due to a legal obligation (under EU law or the national law of a Member State).
  • The personal data has been collected in relation to the offer of information society services referred to in Art. 8(1) GDPR.

In addition, according to Art. 17(3) GDPR, there are a number of derogations where the erasure obligation does not apply. The most important derogation is where the obligation to erase data does not apply due to a legal obligation, for example if there is a duty to retain data for a longer period under employment, tax or commercial law.

5. The right to restriction of processing

According to Art. 18 GDPR, the data subject has a right to restriction of processing. This provision is intended to strike a provisional balance between the data subject’s interests – namely in the protection of their right to “informational self-determination” – and those of the controller in processing the personal data. The data subject has the right to obtain from the controller the restriction of processing where one of the following applies:

  • The data subject contests the accuracy of the data
  • The processing is unlawful
  • The controller no longer needs the personal data for the purposes of the processing, but the data is required for the establishment of legal claims
  • The data subject has objected to processing pursuant to Art. 21(1) GDPR pending the verification of whether the legitimate grounds of the controller override those of the data subject.

According to Art. 18 GDPR, once processing has been restricted, data may now only be processed under particularly narrow conditions and for special purposes. The personal data does not have to be erased, but may no longer be processed in any other way. To this end, the data whose processing is to be restricted needs to be marked and treated accordingly.

6. Right to data portability (Art. 20 GDPR)

The right to data portability is a new right created by the GDPR. The provision is intended to give the data subject more efficient control over their data and to counter lock-in effects by facilitating “provider switching”. This is to promote competition. The provision gives the data subject the possibility to obtain data stored about them (for example, on social media) in an appropriate portable format for the purpose of transmission or, where appropriate, to have the data transmitted directly to the other provider. This is to prevent monopolies, for example because the data subject fears that setting up a new profile with a competing provider would take them too much time.

However, this provision only covers data which the data subject has provided to the controller. In particular, this means data that the data subject themselves used when creating the user account or when posting on social media. The question of whether the provision applies to data collected through interaction with the controller’s service, such as data collected by smart devices or “wearables”, has yet to be clarified.

Since it is quite possible for the data provided by the data subject to contain information not only about themselves but also about third parties, Art. 20(4) GDPR specifies that the right to data portability must not adversely affect the rights and freedoms of others. This means that in the case of data concerning third parties, the fundamental rights and interests of the person making the request must be weighed against those other data subjects. After all, the right to data portability does not apply if it would be used for unfair or abusive purposes.

7. Do the rights of the data subject apply equally in all Member States?

One of the aims of the GDPR is to create a uniform level of data protection in all Member States. However, at many points the GDPR contains so-called “opening clauses” (e.g. Art. 85(2) GDPR), which allow Member States to adopt their own national regulations within certain limits. In Germany’s case, it is particularly important here to take what’s known as media privilege into account, which the German legislator has regulated in Sect. 55 of the Interstate Broadcasting Treaty (RStV). In abstract terms, it can be said that this media privilege leads to the extensive exemption of the press, broadcasting and telemedia from data protection requirements.

Conclusion and recommended action: How important are the rights of the data subject?

The rights of the data subject are one of the central pillars of the GDPR. The supervisory authorities punish infringements with hefty administrative fines. For individuals, the rights of the data subject are a means of both communicating with and monitoring controllers. No company can avoid compliance with the GDPR. It is one of the fundamental legal obligations of any company towards its customers. For this reason alone, it is vital that companies attach great importance to how the public perceive their approach to their data protection duties. A well-managed data protection department that swiftly, comprehensively and reliably complies with the rights of all data subjects sends a strong message. Companies should always take requests from data subjects seriously but also use them to self-monitor and improve the quality of their existing data protection processes.

Learn more

  • Joint controller agreement: Benefits and challenges of joint controllership

    The Joint Controller Agreement (JCA) still seems complicated and cumbersome to many managers in practice. But wrongly so: with the careful design of the agreement, responsible companies can benefit from many advantages, achieve efficiency gains through forward-looking process design and operate a corresponding effective risk management.

    Read more

  • The NIS 2 Directive: Key objectives and regulations

    Last December, the European Council and the European Parliament adopted the Network and Information Security Directive (NIS 2 Directive), thus initiating a reform of the legal requirements for IT security in the European area. After coming into force on 2023-01-16, Germany and the other EU member states now have 21 months to transpose the regulations…

    Read more

  • Anonymisation and pseudonymisation

    Anonymisation and pseudonymisation in practice

    In this article, we look at how the supposed contradiction between data protection through pseudonymisation and the use of personal data in scientific practice can be dealt with. In addition, we take a look at the special challenges that actors in the health care sector face in this topic.

    Read more

New EDPB guidelines on the right of access: How companies can provide information in a legally compliant manner

On 28 January 2022, the European Data Protection Board (EDPB) published guidelines on the right of access (Guidelines 01/2022). They serve first and foremost as a guide to ensure that the General Data Protection Regulation (GDPR) is applied consistently in all Member States of the European Union. While not legally binding, they are used by data protection authorities, data protection consultants and, under certain circumstances, even courts, which is why companies should definitely be familiar with them. The EDPB addresses some questions that the courts have in some cases answered inconsistently in recent years, such as how wide-ranging the right of access really is. In addition, companies can derive important recommendations from the guidelines. In this article, we present the guidelines and provide companies with valuable practical tips on how to proceed when faced with an access request.

When do companies have to provide access under Art. 15 GDPR?

First of all, it is important to understand when companies are required to provide access in the first place. The law itself states that a data subject has the right to obtain from the controller confirmation as to whether or not the controller processes their personal data. The controller is the party which, alone or jointly with others, determines the purposes and means of the processing of personal data. So if a company determines whether, for what purposes, and how personal data is processed, it is considered a controller under the GDPR. It should be noted that the data subject’s right of access is unconditional. This means that the controller need not check why a request has been made and whether it meets certain requirements. In principle, natural persons are always entitled to request access, in which case the company must respond.

Applying a kind of three-step test, companies should then determine to what extent they have to provide access. It is important to consider here whether the company even processes any personal data of the person requesting access.

  • If this is not the case, then the company needs to inform the person of this.
  • If the company does process the person’s data, then the data subject has a right of access to their personal data and to the information referred to in Art. 15(1)(a)–(h), (2) GDPR.

If a company processes personal data, then under Art. 15(3) GDPR it also has to provide a copy of the personal data that is the subject of the processing. The first copy is always free of charge – no matter how much it costs the company to issue it. The copy must comprehensively list all the data mentioned in Art. 15(1) GDPR. Simply providing a brief summary is not sufficient.
Companies may charge a reasonable fee for any additional copies. In this context, it is often not clear whether the data subject has submitted a new request, which would then again entitle them to a free copy, or whether it is a question of merely providing an additional copy. The EDPB explains that this depends on the specific request and how it relates to the first request in terms of time and scope. If the data subject requests a different amount of personal data at a later date, then the company should assume that the request is for a new copy and not for a further copy.

What data and information does the company have to provide access to?

The data

So far, understanding of the scope of the right of access has been characterised by inconsistent case law. The EDPB states that a very broad understanding should be taken as a basis. It argues that an access request covers all of the data subject’s personal data. Besides basic personal data like name or address, a variety of other data must also be included, such as medical findings, creditworthiness indicators, activity logs and search activities. Pseudonymised data is also listed as personal data which controllers have to provide. Communication history – something often requested when the parties have communicated by email – is also considered data which is subject to disclosure. This even applies if the emails have already been deleted but the server provider still has access to them. The Hanover Regional Labour Court (LAG) ruled differently (judgment of 9 June 2020, ref. 9 Sa 608/19) in June 2020, when it ruled that Art. 15 GDPR did not apply to the email correspondence that an employee had conducted or received themselves. The EDPB, on the other hand, bases its view on the very broad understanding of Art. 4 No. 1 GDPR, which provides for a comprehensive definition of personal data. It argues that the right of access under the GDPR must be as broad as the definition allows for the categorisation of personal data. That means a very broad definition – and not one that is overly restrictive. This was also the understanding of the Cologne Higher Regional Court (OLG) when it considered the case (judgment of 23 October 2020, ref. 20 U 57/19) of an insurance policyholder who had contacted their insurance company requesting access. The court took the view that this also applied to information about the history of the premium account, the establishment of the insurance contract, and to the correspondence stored about the data subject.

Newsletter

Don’t miss any updates on data protection, information security and compliance. Subscribe to our newsletter today (only in German)!

By clicking on “Subscribe” you agree to receive our monthly newsletter (with information on judgements, specialist articles and events) and the aggregated usage analysis (measurement of the opening rate using pixels, measurement of clicks on links) in the mails. You will find an unsubscribe link in every newsletter to withdraw your consent. You can find more information in our privacy policy.

Only if the amount of data had been too extensive would the controller have been allowed to demand that the data subject specify their request in more detail. A restricted scope may also be considered if the data subject has explicitly requested only certain data.
By way of example, the EDPB lists the following data which has to be disclosed, taking into account the rights and freedoms of others:

  • Special categories of personal data: sensitive data such as health data
  • Personal data relating to criminal convictions and offences
  • Data knowingly and actively provided by the data subject, such as account data or data collected via forms, etc.
  • Observed data provided by virtue of using a service or device, such as access logs, history of website usage, search activities, location data, clicking activity, keystrokes, etc.
  • Data derived from other data, such as credit ratio, country of residence derived from postcode
  • Data inferred from other data but not directly provided by the data subject, such as algorithmic results, results of a health assessment or a personalisation or recommendation process
  • Pseudonymised data.

In line with this, in a key ruling the Federal Court of Justice (BGH) already ruled (judgment of 15 June 2021, ref. VI ZR 579/19) in favour of a broad understanding of the right of access. Among other things, information should be provided on what is already known or on internal notes.

As regards requests from employees, companies should be aware of the EDPB’s view that elements that have been used to decide whether to promote someone, give them a raise, or assign them a new job must be classified as personal data to which the employee would have a right of access. This might be their annual performance review, training requests or other career potential. This is something the Hamm Regional Labour Court (LAG) decided in its judgment of 11 May 2021 (ref. 2 AZR 363/21), in that it regarded data about an employee’s performance and conduct as personal data within the meaning of Art. 4 No. 1 GDPR.

In response to a request, companies are also required to disclose inaccurate or unlawfully processed data. This helps data subjects to gain a true understanding of all processing operations. Unlike the right to data portability under Art. 20 GDPR, where data can be taken from one controller to another, the right of access also includes derived rights. With data portability, only data generated by the respective company itself can be transferred. Conversely, companies are required to provide access with regard to derived personal data from other providers.

The information to be provided

The data subject may request the following information regarding the processing of the personal data which is the subject of their access request:

  • The purposes for which the data is processed
  • The categories of data, such as health data, biometric or genetic data
  • Information about recipients to whom the data has been disclosed
  • To the extent possible, the envisaged storage period or the criteria used to determine that period
  • The existence of the right to request that data be rectified or erased, that its processing be restricted, or the right to object to processing
  • The existence of a right to lodge a complaint
  • All available information as to the source of the data
  • The existence of automated decision-making, for example by means of artificial intelligence
  • Information about data transfers to third countries, insofar as the data was transferred to a third country.

According to the EDPB, one way for companies to communicate this information is to use existing text from their privacy notice or from their records of processing activities (cf. Art. 30 GDPR). Here, however, it should first be checked very carefully whether the information that uses boilerplate can actually answer the request specifically enough. This would make sense especially in the case of general information that is often identical, such as a notification about the right to rectification, in which case companies could employ automated processes here.

You might also be interested in this:

How should companies grant access?

How can companies retrieve the necessary data?

According to the EDPB, it is important to take into account not just data found in IT systems, but also all non-IT file systems. So companies are also required to research and disclose data from paper files. Personal data collected in a computer memory by means of binary code or stored on a videotape is also considered a potential source of data for such data subject requests. Against the background of the data protection principles of “privacy by design” and “privacy by default”, companies should already have implemented appropriate ways in their IT systems to be able to quickly find requested data. This involves data protection-friendly default settings on the technical side for data processing procedures.

Form

Companies are required to communicate the data as well as the information in written or other form, possibly also electronically. A permanent copy of the information should be provided. For example, if the data subject wishes to receive information orally, companies should comply. However, companies should still be able to provide copies of data if requested by the data subject. As a rule, requests for access are made electronically. According to the EDPB, if the request was sent electronically, then the data copy should also be sent by electronic means of communication. For example, a company might choose to send a PDF file by email. Another option might be an online self-service tool that processes requests automatically. This would only be different if the data subject expressly requested that information be provided in a certain form, for example as a written document sent by post. Then companies should also comply with this wish.

Presenting the information

All notifications must be conveyed in a precise, transparent, comprehensible and easily accessible form, in clear and simple language. A particular challenge for companies is often the sheer volume of data to be disclosed, which can conflict with the requirement to keep things concise. One solution the EDPB mentions here is a layered approach, in which the information is communicated in different layers. In the first layer, companies could communicate information about the processing and the rights of the data subject as well as providing initial information about which personal data is processed. The second layer would then provide more detailed personal data.

Granting access: The clock is ticking

If a company receives a request for access, it is imperative to take action immediately. Companies need to respond to the request as soon as possible, and in any case within one month. In exceptional cases, for example if a company receives a high number of highly complex requests, it may be possible to have the deadline extended by two months.

Limitations

A data subject’s right to obtain a copy of their processed data may not adversely affect the rights and freedoms of others. With regard to the limitations, the EDPB states that trade secrets and intellectual property of the company itself also fall under the rights and freedoms of others, and as such these must not be infringed. In any case, the company would be required to prove any impact on its own rights and freedoms.
Should there be a conflict of interest between the person requesting access and the interests of others, the EDPB certainly sees the possibility of redacting relevant passages or otherwise making them unrecognisable. This would make it possible to grant access to the information while protecting the interests of another person or the company itself. Cologne Regional Court (LG) already came to a similar conclusion (judgment of 24 June 2020, ref. 20 O 241/19) with regard to data disclosure by sending a claims file. It was argued that, in principle, an insurance company was not permitted to transmit an entire claims file due to the interests of third parties. However, personal data of third parties can be redacted in such a case in order to still grant access.

Companies have a right of refusal if requests are manifestly unfounded. The EDPB emphasises that this can only be assumed in very few cases. Companies may also refuse to grant access if requests are frequently repeated and thus excessive in character.

Companies can find further restrictions on the right to access in Sect. 34 of the German Federal Data Protection Act (BDSG). Among other things, under this regulation data subjects do not have a right of access if the data has been stored only because it may not be erased due to legal or statutory provisions on retention. Especially in the case of personal data found in commercial books, annual financial statements or business letters, companies may refuse to provide access. The same applies if data is used exclusively for the purposes of data backup or privacy monitoring. This means, for example, backup copies or log files. However, there must also be disproportionate effort involved, whereby it is primarily a matter of weighing up the interests of the data subject or the controller.

Checklist for requests for access

Companies should take requests for access seriously and process them carefully. Otherwise, they may risk fines or claims for damages under the GDPR. The following checklist will help add structure to the process:

  • Check whether a request is a request for access to personal data under Art. 15 GDPR.
  • Check whether the sender is entitled to obtain access – by checking their identity to determine whether they are a data subject or whether they are entitled to make a request.
  • Find out about the scope of the request – to which data is the person requesting access? If necessary, you can ask the data subject to specify their request.
  • The right of access extends to processed personal data and further information pursuant to Art. 15(1)(a)–(h) GDPR. The EDPB generally considers it to be possible to use existing text taken from the controller’s privacy notice to convey the information from Art. 15(1)(a)–(h) GDPR.
  • The EDPB takes the view that an automated process should be set up for granting access. Especially in the case of large numbers of requests, this serves to relieve the workload of company staff. It is advisable to create a list documenting the date of the request, the requesting person, the contact details of the requesting person, the date and nature of processing and the member of staff responsible within the company. Otherwise, the EDPB recommends setting up a self-service tool that processes requests automatically on its own.
  • Consider the interests of other persons and weigh up whether it is still possible to provide information. For example, redacting certain information could be sufficient.
  • Check whether the request is manifestly unfounded or excessive. Then you can demand a reasonable fee for granting access or simply refuse.

We are happy to support you with all questions regarding EDPB guidelines. Contact us now!

Designing and structuring an efficient DPMS

Implementing data security and data protection appropriately within your company is a complex task. Given the large number of data processing operations that are carried out every day at different points and the equally large number of legal rules that have to be observed, it is easy to lose track of exactly what is going on. This is why companies should opt for a comprehensive data protection management system (DPMS) to help them keep track and not risk being fined for legal violations. In this article, we will show you what is most important.

I. DPMS: A brief introduction

A DPMS is a way to centrally manage and take care of all your data protection requirements. It defines processes, determines who is responsible for what, and introduces control mechanisms. The most important processes include: maintaining records of processing activities; handling data subject requests, complaints and data protection incidents; and conducting regular staff training. As for determining who is responsible for what, it is important to clearly separate your different responsibilities at team or department level and to appoint data protection coordinators. In addition, there should always be close cooperation with the person in charge of data protection. Regular review processes and internal audits are recommended for control purposes.

Newsletter: Stay always up to date

Don’t miss any updates on data protection, information security and compliance. Subscribe to our newsletter today (only in German)!

[ctabtn target=”#newsletter” subject=”Information”]Newsletter subscription[/ctabtn]

II. Designing a DPMS

In order to be able to define a meaningful structure for your DPMS, it is first important to know what companies are generally required to do under data protection law. Any collection, use, archiving or even erasure of personal data constitutes a processing operation that must comply with the General Data Protection Regulation (GDPR). Besides defining responsibilities, legal bases or documentation practice, there are requirements such as ensuring compliance with the data protection principles of “privacy by design” and “privacy by default”, and special regulations for data transfers to third countries, for processing data on the controller’s behalf, and other scenarios. This all results in a large number of overarching goals that your DPMS should achieve – and on the basis of which your DPMS can be structured. These include in particular:

  • Transparency
  • Purpose limitation
  • Data minimisation
  • Accuracy
  • Storage limitation
  • Integrity and confidentiality
  • Accountability.

The many requirements can cause data protection management within your company to become highly time-consuming and tedious for the staff involved. Given that there are different tasks with different deadlines, and differently structured documents sent out to different departments, the whole affair is very prone to errors. This makes a carefully crafted DPMS all the more important.

You might also be interested in this:

Transmission of health data: pitfalls in health apps & fitness trackers
The biggest GDPR myths: the consent – what is right and what is wrong?
Handling enquiries from data subjects – what is really relevant?

III. Key content in an DPMS

One important component of any DPMS is information about records of processing activities. It also contains all the documentation necessary for accountability purposes under Art. 5(2) GDPR. But it also serves as a basis for the monitoring processes that are mandatory under Art. 32 GDPR. In addition, it contains information on the erasure concept, service provider management, on documentation of technical and/or organisational measures, on data security and data protection impact assessments (DPIAs). Other points to include in your DPMS are processes involving data subjects’ rights, data protection incidents and requests from authorities, as well as staff training.

Dealing with data subjects’ rights is another central part of a DPMS. The most important thing here is to make sure that you are guaranteeing these rights in the legally prescribed form. This includes informing data subjects in plain language about the processing of their personal data and what specific rights they have, for example the right of access or to have their data erased. In order to answer requests from data subjects in full and on time, companies need to set up an effective system that includes a whole host of factors, such as who is responsible and who to contact, appropriate tools for answering or forwarding requests, as well as erasure and deadline management systems.

Finally, it is crucial to react properly to data breaches. Under the GDPR, breaches must be reported to the supervisory authority within 72 hours at the latest, and in the case of a particularly high risk, also to the data subjects themselves. A complete DPMS therefore also includes processes for dealing with data breaches and reporting obligations. Your staff need to know the potential scenarios in which data breaches may occur and how to report them.
This does not mean simply drawing up a list, but regularly reviewing and updating that list is crucial to ensure a functioning DPMS and also to comply with accountability requirements under data protection law.

IV. The PDCA cycle

When it comes to implementation, it is advisable to apply a four-phase PDCA cycle (Plan Do Check Act), which is highly suitable for a DPMS and can therefore also be found in the standard data protection model. It consists of four phases that are repeated with the aim of continuously learning and improving. The first step should be to obtain an overview of all processes which involve processing personal data. Subsequently, compliance with the data protection requirements is reviewed. It is not only important to record individual data breaches that have already occurred: according to a risk-based approach, the respective processes in the company also need to be evaluated with regard to the potential risk of data breaches. In the case of a high risk, you should then set about using the results obtained and taking action to improve the situation even before a breach occurs. For example, measures can be taken to implement data protection principles such as data minimisation or to ensure the fulfilment of data subjects’ rights. It is also important to ensure that the DPMS integrates well with existing systems and processes. This results in the following verification phases within the PDCA cycle:

  1. Plan: Planning, specification, documentation
  2. Do: Implementation, logging
  3. Check: Check, audit, assessment
  4. Act: Improvement.

V. What else belongs to a DPMS

One of the advantages of a DPMS is that it can employ uniform documentation. This makes it easy to set deadlines and priorities and to send notifications or reminders early on. Through change management, adjustments can be made quickly to different documentation such as the records of processing activities or a DPIA, while the documents remain synchronised and up to date. The DPMS can also be used to carry out comprehensive compliance checks and risk analyses. In addition, a DPMS is a good way to work on data protection in a team. With responsibilities clearly distributed, direct communication channels and uniform documentation, misunderstandings and additional work can be prevented. A digital DPMS is not a must, but an advantage. This offers a central database as the basis for all requirements under data protection law, which your staff can access via a user-friendly dashboard depending on their responsibilities. In addition, communication among each other can be made easier with task assignment or comment functions.

VI. Conclusion

A DPMS makes it much easier to comply with data protection obligations. Documenting and reviewing the GDPR requirements promotes clarity and helps avoid data breaches while reducing time and effort. A good DPMS also enables you to react quickly to changes. Constantly reviewing the data protection standard and the possibility of flexible adjustments ensure that all measures always remain up to date. Dedicated DPMS software can make things even more straightforward, as it lets you centralise and automate data protection throughout your company. In the long term, this can be a way of improving processes as a whole and not only in the area of data protection. Companies that want to implement a DPMS should be guided by the requirements of the GDPR and use the records of processing activities as a basis for creating a suitable, comprehensive system.
Please contact us if you need advice on DPMS.

Transmission of health data: pitfalls in health apps & fitness trackers

Digitisation is permeating all areas of life. Also, especially within the health care sector, the eagerness to spur the digital transformation is immense – equally from state and private sides. Thus, the market is already well-filled with a variety of fitness trackers and health apps today. Even health insurances promote the use of their own apps and the purchase of fitness bracelets with premiums. However, in view of the increasing trend of self-measurement, this development is no surprise. The digitalisation of the health sector has the potential to significantly improve the quality of medical care: more reliable diagnoses by using artificial intelligence (AI), extensive development of rural areas through new communication channels, drastic reduction of public expenditure by optimising health care.

The key question: what should be considered when transmitting health data?

Fitness trackers develop their full potential only in conjunction with a corresponding app that visualises the collected data pleasantly and understandable. Mostly, users must first register and create a new profile in order to fully benefit from the app. This profile and the collected personal data are usually transmitted to a central server, stored and synchronised continuously. The requirements placed on such data transmission are tightened by the fact that the data to be processed is regularly health data. In addition, hackers are following the development of the self-optimisation market closely, because wearables have become a popular target. Payment data, user and health data are the focus. In this respect, from a technical point of view, data controllers must ensure greater security of data. So, what should be considered with regard to such transmission?

Legal challenges – tightened requirements within the health sector

1. The combination of individual data also leads to personal reference
Unquestionably, the scope of the General Data Protection Regulation (GDPR) is open to application in case data collected via a fitness bracelet or an app (user profile, IP address etc.) is processed since it bears direct personal reference. In addition, it regularly affects particularly sensitive health data. Thus, the combination of a fitness bracelet and an app can even allow recording of ECGs. In order to receive e.g. optimised training recommendations, more data could be entered by the user. However, it must be considered that the combination of individual data may allow drawing conclusions regarding the health state of the person affected. Like this, the so-called “Body Mass Index” (BMI) can be derived by combining additionally indicated data such as weight, age and size. Therefore, companies are often unaware of the specific amount of processed health data. However, a complete capture of the processed data is necessary in order to be able to fulfil the comprehensive transparency and information requirements under Article 13 GDPR.

2. Use Privacy Impact Assessment for your own gain
The common Blacklist of data protection authorities shows: If measured data of sensors, installed in fitness bracelets or smartphones (heart rate monitors, acceleration sensors, etc.), are stored centrally, a data protection impact assessment (DPIA) is regularly to be carried out in accordance with Article 35 GDPR. This obligation to conduct a DPIA should not be seen as a chore by companies, but as an opportunity. DPIAs help companies to evaluate what data they are processing and what they have to be aware of when submitting data in order to comply with the General Data Protection Regulation. By this means, challenges regarding data protection and data security can be identified at an early state in the development in order to prevent later legal complications and penalties.

3. Know specific legal bases for the processing of health data
If health data are processed (including transmission), data controllers are not provided with the regular legal basis of Article 6 (1) GDPR. Accordingly, the processing of health data remains inadmissible despite the existence of one of the legal bases of that article. The lawfulness of the processing of health data is governed exclusively by Article 9 (2) GDPR. If health data is collected and processed via a fitness tracker or a corresponding app, the consent of the person affected must regularly be obtained.

In general, the same requirements apply to the granting of consent under Article 9 (2) (a) GDPR, as to the granting of consent under Article 6 (1) (a) GDPR. However, due to the sensitivity of health data and therefore the narrow interpretation of exemptions for formulating declarations of consent, data controllers should be particularly rigorous and fully informed about the processing intended. Especially the fact, that the data does not remain on the end device but is transmitted to a central server of the enterprise should be highlighted and presented comprehensively.

In addition, if companies intend to process the personal data for a purpose which is not necessary for the provision of the actual service, the so-called prohibition of coupling must be considered. For example, if the data is to be further processed for marketing purposes, such consent may not be combined with the central consent form, but instead the consent must be obtained separately. The same applies in case of transfer to third parties, which is common in the field of health apps.

Checklist Consent

  • voluntary
  • for certain cases (general consent is inadmissible)
  • delivered in an informed and unmistakably manner
  • understandable and easily accessible form
  • clear and simple language

4. Choose conscientious data processors
Server operators on the one hand and providers of apps and fitness trackers on the other hand are often not identical. The server operation is rather outsourced to a specialised service provider (so-called outsourcing), who then is able to inspect the personal data. Such a service provider is regularly qualified as a data processor, so that the conclusion of a data processing agreement becomes relevant. In accordance with Article 28 (1) and (3) (c) GDPR – and in order to avoid reportable data breaches – data controllers must ensure by contract that also the service provider adopts adequate, state-of-the-art safeguards for the protection of data (technical and organisational measures) whilst processing health data. This applies especially in the context of highly sensitive health data.

Due to existing or advantageous infrastructures, companies often fall back on providers from abroad such as Amazon Web Services. In doing so, it is necessary, that data controllers must raise the following questions: has the commission decided by resolution that the respective country shows an adequate level of protection regarding data protection matters? Has the provider been certified under EU-US Privacy Shield? If this is not the case, data controllers and their processors must provide for appropriate guarantees under Article 46 (1) GDPR, such as standard contractual clauses.

The safety of health data plays a key role

Data security has a special importance in the context of health data processing. Hackers show increasing interest in wearables and health apps and, unfortunately, providers oppose only in the rarest of cases with appropriate safeguards. This deficiency is crucial when it comes to an app that is used by hospitals, e.g. for the purpose of monitoring patients. In this context, the continued availability, confidentiality, and integrity of health data is predominantly important. Compromising single connections and manipulating individual measured data can lead to health-damaging or even life-threatening false diagnoses.

In addition, data controllers should not only protect the connection between end device and server from so-called “man-in-the-middle” attacks, but also focus on the transfer between wearable and app, as this is also a popular target of hackers. An encryption of connections (Secure Sockets Layer, short: SSL) should therefore be flanked by the encryption of the transmitted data (keyword “hashing”) by default.

Especially from a technical point of view, that is an opportunity to stand out from the competition.

Reliable anonymisation of health data remains a difficult part

Whenever possible, personal data should be anonymised. In this way, the scope of application for GDPR is left, so that there is significantly less administrative effort concerning the use of data.

With regard to health data, however, successful anonymisation within the meaning of the GDPR (re-identification impossible) seems doubtful. For example, a 2013 study has shown that 4 to 5 blood glucose or cholesterol levels out of around 60,000 patients are enough to allow unambiguous identification of affected individuals.

In this respect, at least the pseudonymisation of personal data should be promoted.

Recommendation for action and Conclusion

Data protection and technical challenges associated with the processing of health data are considerable. For this reason, companies must consider their obligations in order to be able to survive on the market of fitness trackers and health apps in the long term.

In order to avoid data breaches and life-threatening incidents, data controllers should, first of all, take care of particularly secure connections between the tracker, app or smartphone and server. The transfer to third parties should be avoided, if possible. Ideally, companies operate servers on their own. For the purpose of financing, it makes sense to dispense with advertising and, alternatively, develop paid-for apps that impress with particularly high data security levels.

Handling enquiries from data subjects – what is really relevant?

The proper handling of enquiries from data subjects benefits any business. A well-versed approach can not only ensure compliance, but also optimise and accelerate the entire business process. For this reason, responding to data subject requests should be a firm component of a good data protection management system in the organisation. But how does one deal with data subject’s enquiries properly? What should be considered according to the GDPR?

Recognise an enquiry from a person affected

First of all, a request from those persons affected must be recognised as such. This may sound simple, but it is not always simple like that! After all, the majority of the persons concerned are legal laymen who are unlikely to literally use the word “data subject” and, in particular, name the specific right that they seek to assert. However, they do not have to! Here, the data controller is asked to discover what the data subject actually requires. In case of the following phrases, one may already assume that the message represents a data subject’s request and therefore precautionary treat it as such:

  • “I have a question relating data protection” or “I want to know something about how my data is being handled”
  • Terms like information, disclosure, blocking, limitation of processing, deletion, right to be forgotten or objection are used
  • “Where did you get my data from?”
  • Unauthorised, unwanted advertising, spam is objected to
  • “Please unsubscribe from the newsletter”
  • “Please correct the following information about me”
  • Person threatens with lawyer, warning or notification to data protection authority
  • Person demands the data protection officer

These phrases may indicate the different types of request that are to be assigned to the respective data subject’s rights of the GDPR:

  • The right to information (right of access)
  • The right to erasure
  • The right to restriction of processing
  • The right to rectification
  • Right to data portability
  • Right to object to previously granted consent

The Response – what should be considered?

It is true that the requests can be made by any means, such as orally, electronically, by telephone or written. However, the response should always be in writing or, if necessary, electronically. Electronic responses should be handled with care as data security during transmission must be ensured. In addition – and required by law – the answer must be precise, transparent, comprehensible and easily accessible to those concerned. We also advise that the entire process and the entire communication is fully documented!

Furthermore, of course there is a deadline to consider. It is intended that the answer must be given immediately, but no later than within one month of receipt of the request. Although there is an exceptional extension of time up to three months, but you better not rely on it! This is only permissible in rare cases.

It should also be noted that the data subject must always be informed if their request can not be met. This is the case, if e.g. the person requests the deletion of their data, but it is precluded by statutory retention requirements.

If the request reaches the processor, he does not have to answer it, but forward it to the data controller instead. A data processing agreement (DPA) should regulate precisely the order of processing.

[bluebox]

The Response – the Process

What is the best way to proceed when a claim has been received? We recommend the following approximate sequence:

  1. Forward the request to the data protection coordinator of the company
  2. Specify the deadline: note the time of receipt of the request
  3. Send acknowledgment of receipt to the person concerned
  4. Research: Searching the data sources for the information of the data subject
  5. Identification: Data protection coordinator identifies data subject based on data sources
  6. Data protection officer can be contacted at any time
  7. Change of database according to the type of request
  8. Send a reply via data protection coordinator
  9. Documentation of the process by data protection officer

[/bluebox]

In particular, the fourth point encounters difficulties in practice, because the data on the requesting person must first be found. Here, a well-maintained record of processing activities (according to Article 30 GDPR), which clearly lists the data, is enormously helpful.

The consequences of the request

The consequences of the data subject’s request depend on the specific type of query:

Right to information (right of access): If the data subject claims information, he / she must be informed about the stored data and provided with the information to the legally-defined extent. The person specifically has a right to information about the processing purposes of personal data (e.g. for the purposes of e-mail marketing), the categories of personal data being processed (e.g. contact details), the recipients of the data (especially outside the EU) and the retention period of the personal data.

Right to data correction (right to rectification): The Right to data correction includes the right to correct and supplement incorrect data concerning a person.

Right to restriction of processing: Here the data controller must ensure that the stored personal data are no longer processed.

Right to erasure (“right to be forgotten”): If the deletion of personal data is requested, the consequences are self-explanatory: the relevant data must be deleted. In some cases, however, an anonymisation may be sufficient, if reidentification of the person is technically and organisationally excluded.

Right to data portability: If a person asserts his or her right to data portability, the person must receive the data from the data controller in a structured, commonly used and machine-readable format, if the processing takes place in an automated process and on the basis of a consent or if it is required in order to carry out a contract. If technically feasible, the data can also be transmitted directly to another data controller.

Right to object: With the right of objection, the data processing being intrinsically allowed is made inadmissible for the future. The right may be exercised on data processed based on public or legitimate interest. However, it should be noted that consents can be withdrawn, too.

Conclusion: Ensure compliance with structure and routine!

In fact, it is not that difficult to deal with said enquiries properly. If you are familiar with the procedure of how to respond and what to consider which each type of request occurs, that is half the story.

However, the devil is in the details!

It always depends on the individual case and on how the answers are structured in terms of language and content. It may even happen that you have to deviate from the usual procedure. For this reason, we recommended to entrust an experienced data protection with including the data subjects’ requests into the companies’ data protection management system and establishing a proper and complete record of processing activities.

Please do not hesitate to contact the IT and legal experts of ISiCO Datenschutz GmbH! We can show you how to safely and correctly deal with data subjects’ enquiries and help you to create your own record of processing activities! Moreover, we train your employees in the proper handling of data subjects’ rights and we would also be happy to take the role as a data protection officer in your company!

The biggest GDPR myths: the consent – what is right and what is wrong?

GDPR myth busters – Part 1

The GDPR is effective since 25 May 2018. Before and after, there was a lot going on. Hardly any other topic has been talked about and published so much. Unfortunately, the numerous publications with the allegedly “best” references and recommendations have not resulted in an understanding amongst the “data controllers” of what it is about. On the contrary, there is still general confusion about the implementation of the GDPR. Best example: The flood of newsletter emails before and after 25 May 2018, with the request to give consent again (or for the first time) or simply with the information that newsletters will not be sent in the future due to lack of consent. What is true and what is wrong? Lots and lots of questions, but no satisfying answers. With this series, we want to give the required answers: What myths are there about the GDPR? What is right and what can be refuted?

The biggest GDPR myths about consent:

In data protection law, the principle applies: The processing of personal information is prohibited, unless the law or the data subjects permit it. This permission is called Consent and is the linchpin of the GDPR. The law places strict requirements for consent. But what is it exactly and is everything that you hear about it true? Nine misconceptions about consents under the GDPR:

1. Consent must always be obtained in writing!

With the form of the consent, the GDPR complies with the data controller. For example, in Sec. 4a of the former German Federal Data Protection Act (FDPA), the written form for consent in the processing of personal data was so far ordered. According to the GDPR, a written form is not necessary anymore. A “declaration or other affirmative action” suffices, i.e., theoretically, even a nod would be enough. However, only in theory, because data controllers must prove that the consent has been given effectively (obligation of documentation and proof). This may be difficult when you have only a nod. Instead, the active clicking on a check box (opt-in) is sufficient.

Caution: A check box where the box had already been ticked and has to be deactivated (opt-out), is not considered an effective consent.

2. Consents, which were obtained before the rule of the GDPR are invalid!

That is not correct. The European legislator has decided in favour of the processors that also consents obtained before 25 May 2018 remain in full force and effect. This means, that once effectively obtained data protection legal consents do not need to be obtained again, as long as they also comply with the provisions of the GDPR. Since – for example in Germany – the previous requirements are very similar to those of the GDPR, in most cases a renewed request for consent will not be necessary.

Caution: There are special requirements for the consent of minors.

3. Minors can not give consent effectively!

It is true, that the GDPR sets rigid age limits for the effective submission of consent. The GDPR stipulates that minors can only effectively consent to the processing of their personal data by the age of 16 years. This age limit can be lowered by the member states up to the absolute lower limit of 13 years. For the processing of personal data of under 16-year-old persons data controllers need the approval of the person’s legal representative.

4. Consents can also be obtained later!

The myth, that it is not a matter of the timing of obtaining the consent, is not true. “Consent” is a legal term and means prior consent. The opposite of consent is the “authorisation”, i.e. subsequent consent that does not legitimise the processing of personal data.

5. For consent, the double opt-in procedure is mandatory!

First, it can be stated with certainty: The opt-out has become obsolete! Consents designed as opt-in (that is, ticking in a check box) must be granted actively. It is questionable whether the so-called double-opt-in is mandatory for the granting of consent. Under the Double-Opt-in procedure, the tick is set first. In addition, a provided link, e.g. when subscribing to the newsletter, must be clicked to confirm the consent. The advantage of this procedure is that it offers a simplified proof of the granting of consent, which is mandatory for the data controller’s obligations of documentation and proof. If this proof can also be provided with the single-opt-in method, this is enough, so that a double-opt-in procedure does not necessarily have to be carried out. However, it can be said: The Double-Opt-in offers more security against sanctions and two is better than one anyway!

6. One consent for all data processing is sufficient!

The idea that one blanket consent is sufficient for legitimacy of unlimited data processing is grossly wrong. The principles of consent are voluntariness and purpose. The person affected must be informed precisely regarding the purpose for which his data is used. He/she then has to decide for him/herself which processing operations he/she wants to agree to.

Caution: Voluntariness is not given if the rendering of a service is made dependent on the consent of a processing that is not necessary for the provision of the service (so-called prohibition of coupling).

Example: A customer orders goods in an online shop. During the ordering process, the customer is informed that the data entered (e.g. e-mail address, address, telephone number) can also be used for advertising purposes. In order to continue the ordering process, the customer must give his consent to the use of his data for advertising purposes. Since the consent to data processing is not needed for the provision of services (shipping of the product) the prohibition of coupling applies.

7. The revocation of consent must be equal to the granting!

A once given consent must be revocable for the future. New in this context is the regulation of Art. 7 para. 3 p. 4 GDPR: The revocation of consent must be as simple as the granting of consent. However, this does not mean that the revocation procedure must be completely the same as the one granted. Especially in online trading, the consent is usually given once via opt-in before the data processing begins and there is no possibility of removing the tick later, unless there is a customer account. The keyword is simplicity. As long as there is an easy way to revoke consent, this is sufficient. In newsletters, for example, this is possible by putting an unsubscribe-link to the end of the email or an opt-out option into the privacy policy.

Caution: The possibility of withdrawal must be made aware of clearly and easy to read.

8. I can not process any data without consent!

If consent or permission according to Art. 6 para. 1 lit. b or c GDPR are missing, data processing can also be based on legitimate business interests under certain conditions, insofar as these outweigh the rights and interests of the data subject (Article 6 (1) (f) GDPR). Even without consent, data processing is possible. According to the recitals of GDPR, economic interests and, in particular, direct marketing are expressly recognized as legitimate corporate interests. However, companies must in fact carry out a balancing of interests and this must be in favour of the company.

9. For every cookie I need a permission!

The subject of cookies and consent is still confusing under new data protection law. In any case, it is clear, that cookies represent personal data that must be measured against the GDPR. This means, that the use of cookies is generally prohibited, unless the data subject has consented, or it is subject to one of the permitted grounds of Article 6 GDPR. As described above, data processing in accordance with Art. 6 para. 1 lit. f) GDPR can be allowed, if there is a legitimate interest. This includes, inter alia, commercial corporate interests (e.g. advertising). It must always be considered, whether the interest in data processing outweighs the data subject’s interest in the protection of his/her data.

However, for good reasons, the setting of cookies for advertising purposes can be based on a predominant interest in accordance with Art. 6 para. 1 lit. f GDPR as long as the data is collected in a pseudonymous form. The pseudonymisation would meet the needs of the users’ legitimate interests. As a result, one would be back at the opt-out option. However, also in this constellation, it is useful, to use a cookie banner on which the website user is informed about the setting of cookies and their purposes.

Caution: The person affected must always be given the opportunity to object and must be clearly informed about this opportunity.