Many articles have highlighted the changes that the Regulation (EU) 2016/679 of the European Parliament and of the Council on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (more commonly referred to as GDPR) will bring to companies. Usually, the focus rests on companies in their capacity of data controllers. There has been considerably less exposure of the impact of the GDPR on IT service providers who process personal data on behalf of their customers (data processors).
Under the current legal framework, data processors have no legal regime that applies directly to them. The data protection obligations of the data processor are in a general manner obligations that contractually derive from the obligations of the data controller. In essence, the data controller has an obligation to choose a reliable data processor and to execute a data processing agreement with the data processor, in which it must impose certain contractual obligations[2]. Over the years, the contract practice has developed more elaborate data processing agreements. For instance, even though there is no general personal data breach notification obligation in Belgium (except for the electronic communications sector), many contracts already impose such an obligation on data processors.
The GDPR considerably expands the current legal framework in relation to data processors. As of 25 May 2018, data processors will have their own legal framework. Moreover, the requirements of data processing agreements are reinforced. Below, we provide some insight into the consequences this will have on IT service providers and their contract practice.
I. When does the GDPR apply to data processors?
In terms of scope, the GDPR does not distinguish between data controllers and data processors.
The GDPR applies “to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system”. To put it shortly, if IT and personal data are involved, the GDPR will apply and if no IT is involved, the GDPR will only apply if the personal data is structured data. E.g. a data shredder that shreds personal data from a paper filing system (structured data) will be subject to the GDPR, whereas a data shredder that shreds the same personal data not part of a paper filing system, e.g. a disposal bin for confidential information (unstructured data), will not be subject to the GDPR.
For the territorial scope, the main criterion is the location of the establishment of the data processor. The location of the assets that are used for the data processing activities is irrelevant.
If the data processor is established in a member state of the EU, the GDPR will apply to any activity covered by the material scope mentioned above.
If the data processor is not established in a member state of the EU, the GDPR applies extraterritorially to data processing activities that are related to:
- the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the EU;
- the monitoring of the behaviour of data subjects as far as their behaviour takes place within the EU.
IT service providers established outside the EU will thus have to be very careful if they provide IT services to any data controller that carries out the abovementioned processing activities (e.g. the hosting of a web shop that specifically targets consumers in the EU). For the GDPR to apply, it suffices that the data processor provides a service that relates to such an activity. It is not yet clear how strong the relation must be for the GDPR to apply. Does the GDPR also apply to a back-up service provider of a data processor (i.e. a sub processor) that falls under the scope of the GDPR?
The definition of scope may also pose some practical problems, especially where the service provider has no knowledge about the activities of the data controller (e.g. a hosting provider that has implemented a zero-knowledge encryption in relation to the hosted data). A prudent data processor will request information about the nature of the data controller’s data processing activities or even a contractual indemnity, as the financial impact of applying the GDPR is not negligible.
II. Obligations of the data processor
As there is a specific legal regime for data processors under the GDPR, it logically follows that the data processor has its own legal obligations.
It should however be noted that, contrary to what is often asserted, the data processor is not directly subject to the accountability mechanism of the GDPR.
- The appointment of a representative
If the data processor is not established in the EU, it must appoint a representative based within the territory of the EU.
This obligation, which exists only for data controllers under the current legal framework, has lately received some press exposure as result of a decision of the Court of The Hague of 22 November 2016 concerning the obligation of WhatsApp Inc. to appoint a representative in the Netherlands based on an order of the Dutch data protection authority (Autoriteit Persoonsgegevens)[3].
It would be prudent to anticipate an increased enforcement, because a single representative will suffice under the GDPR. As the administrative burden is greatly reduced, the supervisory authorities are likely to be less tolerant about infringements.
There is an exemption under the GDPR for this obligation, but the conditions are very strict. It is unsure whether many data processor may invoke the exemption.
- The maintenance of records of processing activities
Each data processor must retain a record of all categories of processing activities carried out on behalf of its customers (i.e. the data controllers). The register must include the name and contact details of the data controllers, the data processors, their representatives and the data protection officer. The register must also contain information about the categories of data processed, an overview of international data transfers and, where possible, a general description of the technical and security measures in place.
Data processors employing less than 250 persons are conditionally exempted. However, the conditions are very strict and it is unlikely that many data processors may invoke the exemption. In this respect, there is an ongoing debate on the concepts of “occasional processing” and “risk”. Until this debate is resolved, applying the exemption will be difficult.
- The appointment of a data protection officer (DPO)
Concerning the conditions under which a DPO must be appointed, the GDPR does not distinguish between data controllers and data processors[4].
The role of DPO may be outsourced to a service provider, in which case the DPO will in all likelihood also qualify as data processor. It is hardly conceivable that a DPO could assume his function without having access to the personal data being processed by the data controller or the data processor.
- Security of processing
Under the GDPR, both the data controller and the data processor are under a legal obligation to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. This obligation of the data processor must also be reflected in the data processing agreement.
- Personal data breach notification
The data processor has a separate personal data breach notification obligation towards the data controller.
The data processor must notify the data controller without undue delay after becoming aware of a personal data breach. This notification will subsequently trigger the personal data breach notification of the data controller towards the supervisory authority and, possibly, the data subjects.
It is common practice to reflect this legal obligation (already at this moment) in the data processing agreement. Consequently, failure to comply with the personal data breach notification will probably qualify a breach of a legal obligation and a breach of contract in most instances.
We have already noticed that some entities impose a short deadline of 24 hours on their data processors, based on the reasoning that these entities only have 72 hours to comply with their personal data breach notification obligation. However, we believe this reasoning does not correctly reflect the trigger of the personal data breach notification of the data controller, that must notify without undue delay and within 72 hours, after becoming aware of the breach, i.e. after having been notified by the data processor.
- Cooperation duty
The data processor must cooperate, on request, with the supervisory authority. This obligation should be hardly surprising, given the fact that data processors have a legal regime that is directly applicable to them under the GDPR.
- International data transfers
The provisions in relation to international data transfers, i.e. transfers to third countries, shall also be directly applicable to data processors. It is interesting to note, in this regard, that the GDPR mentions the possibility of contractual clauses (model clauses) between data processors[5]. This is an option which does not exist at this moment. There are currently no model clauses between EEA-based data processors and non-EEA based sub processors[6]. This situation must be circumvented by either a direct contract between the data controller and the sub processor or a mandate for the data processor to conclude model clauses with the sub processor on behalf of the data controller. Either will work fine, but it is slightly more administrative burden than a processor-to-processor solution.
III. The data processing agreement
The GDPR confirms the requirement of a written or electronic data processing agreement between the data controller and the data processor. In practice, this requirement often takes the form of a specific section or annex with data protection related clauses that forms part of a broader agreement.
Existing data processing agreement templates and data processing agreements that continue beyond 25 May 2018 will however require some degree of revision, as the GDPR has considerably increased the content requirements for data processing agreements.
A data processing agreement must contain the following provisions:
a. Generic requirements
The GDPR requires that each data processing agreement sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller.
Whilst most of this information is typically included in all agreements, many data processing agreements do not currently describe the type of personal data and categories of data subjects. This can be explained by the fact that for many IT service providers, it is not necessary to include this information. Even though not contradictory as such, it may also appear contradictory at first sight to require this information in an agreement, where the service is organised in such a manner that the service provider cannot access the personal data being processed (e.g. hosting services using zero-knowledge encryption). Having a summary in the data processing agreement does not reduce the zero-knowledge encryption solution.
It may be expected that data processors will impose an information duty and even indemnification obligations on their customers in relation to the information they have provided pursuant to this requirement.
Data processors that provide hosting services will also have to pay attention to stay within the scope of the liability exemption regime that applies for hosting services under Directive 2000/31/EC. They must ensure that the information they obtain to comply with their obligations does not place them in a situation where they obtain actual knowledge of illegal activity or information or facts or circumstances from which the illegal activity or information becomes apparent. Given the generic nature of the information requirements, we believe that hosting providers should be able to stay within the limitations of the liability exemption.
b. Limitation of the authority of the data processor
The data processing agreement must stipulate that the data processor may only process personal data on documented instructions from the data controller.
This rather formal requirement must be read together with the provision of the GDPR that prohibits data processors (and any person acting under the authority of the data processor) from processing personal data except on instructions from the data controller. Consequently, merely stipulating this restriction will not be sufficient. The data processing agreement should also clearly provide a clear and complete description of the data processing activities that the data processor shall carry out.
c. Confidentiality
The data processing agreement must ensure that the persons processing the personal data are bound by a contractual or statutory obligation of confidentiality. Data controllers shall in all likelihood enforce this obligation through audits and contractual indemnities.
d. Security measures
The data processing agreement must confirm the legal security obligation of the data processor. It is currently already a standard practice to include a description of the security measures in the data processing agreement.
e. Limitations on the appointment of sub processors
Under the GDPR, data processors may not engage another data processor (i.e. sub processor) without the prior specific or general written authorisation of the data controller. Moreover, in the case of a general authorisation, the data processor still has an information obligation and the data controller still has a right to object.
This requirement is a considerable reinforcement of the current rules, which simply apply the common contract law provisions on subcontracting. Whereas currently the appointment of another data processor is treated in the same manner as any other subcontracting, the GDPR creates a specific subcontracting regime in relation to the processing of personal data. This will most likely result in two clauses in relation to subcontracting (one for data processing related subcontracting and one for other types of subcontracting).
This requirement will be particularly difficult to comply with in standardised many-to-many service models (e.g. cloud computing services where there may be many customers and subcontractors). It is also conceivable for those many-to-many service models that the right to object will be linked to a termination for convenience (with or without compensation) of the agreement, as it will be very difficult or impossible for a service provider to accommodate a diverging application of the right to object amongst its entire customer base. In practice, if the client cannot switch from one IT service provider to another without continuity risks or substantial additional cost, coupling the opposition to a termination will imply that the right to object will be ineffective.
The data processor must also pass through its obligation to any sub processor and the data processor remains fully liable towards the data controller for the performance of that sub processor. This implies that some service providers shall have to abandon their practice to include subcontractor breach of contract under force majeure, at least for data processing related activities. As this is not a proper application of force majeure anyway, we can only applaud this.
f. Assistance to the data controller in relation to the exercise of data subjects’ rights
The GDPR requires that the data processing agreement provides that the data processor assists the data controller with the fulfilment of the data controller’s obligation to respond to requests for exercising the data subject’s rights. This obligation is an effort obligation.
The data processor should therefore, under an effort obligation, design its service in such a manner as to facilitate the data controller when confronted with data subject requests. Moreover, if the data processor is confronted with a request, it should assist the data controller (in all likelihood subject to reasonable additional compensation, similar to other support services).
As an alternative to this assistance obligation, the data controller could envisage mandating the data processor to handle data subject requests on behalf of the data controller. This alternative will largely depend on the level of trust between the parties and the nature of the data processing agreement.
g. Assistance to the data controller in relation to the latter’s own rights
The data processor must also assist the data controller in ensuring compliance with its duties, such as security measures, personal data breach notification, the performance of data protection impact assessments and prior consultations. Again, it is likely that data processors will require some form of compensation for these obligations.
Given the early stage in which the data protection impact assessments and prior consultations should take place, we believe it might be rather unusual that a data processor is involved, unless of course the data processor has already been selected at a very early stage of the organisation of the intended data processing activity.
h. Retransition provisions
It will also be mandatory for data processing agreement to contain provisions in relation to the retransition of the personal data. It must be stipulated that, at the choice of the data controller, the data processor deletes or returns all the personal data to the data controller after the end of the provision of services relating to processing, and deletes existing copies unless a legal data retention obligation exists.
This requirement is unlikely to pose contractual problems, as clauses of this type are common in relation to confidential information and personal data. Still, the data processor shall have to implement proper measures to ensure (technical) compliance with this obligation.
Finally, the data processor must also inform the data controller if, in its opinion, an instruction infringes the GDPR or other applicable data protection provisions. Whilst this may appear to be a new obligation, it should be noted that Belgian common contract law imposes an information duty on professional services providers, including an obligation to warn the client in case of inaccurate, incomplete or illegal instructions that the professional service provider becomes aware of. Consequently, we do not believe this requirement is really a new obligation for the data processor.
i. Provide compliance information and participate in data protection audits
The data processing agreement must stipulate that the data processor makes available to the data controller all information necessary to demonstrate compliance with the obligations mentioned in this section. This obligation is in fact a derivative of the legal requirement of the data controller to be able to demonstrate compliance with the principles relating to the processing of personal data (“accountability principle”). By contractually imposing an information duty on the data processor, it assists the data controller in demonstrating its own compliance.
Furthermore, the data processor must allow for and contribute to audits, including inspections, conducted by or on behalf of the data controller. This requirement is not new compared to the current Belgian legal framework and the existing contract practice.
Based on our experience with other IT related services, the negotiating position of the data processor will largely determine whether the data processor may obtain payment for the performance of these obligations.
Given the obligation of the data processor to cooperate with the supervisory authority, we believe it makes sense to include audits performed by the supervisory authority in the contractual arrangements. This may enable the data processor to recover the costs of such an audit from the data controller.
IV. The liability regime of the data processor
Whereas under the current legal regime the liability of the data processor is essentially contractual, the regime with direct legal obligations of the data processor also entails a regime of liability that applies directly to the data processor. This implies, amongst other, the possibility of liability claims (damages), but also the application of the system of administrative fines on data processors. A lot has already been written on these topics, so we will not repeat the details here.
As a final note, it is interesting to see that the GDPR embeds the position that was previously published by the Article 29 Data Protection Working Party, i.e. that a data processor that determines the means and purposes of the processing shall be considered to be a data controller[6]. Given the consequences, data processors should be very careful not to exceed the limitations of the data processing agreement because of the specific manner in which they perform their agreement.
V. Conclusion and practical tips
The GDPR will substantially alter the legal position of data processors by creating a specific legal regime applicable to data processors with direct enforcement possibilities. This may be particularly challenging for non-EU based data processors, as the activities of their clients will determine whether or not the GDPR will apply to them.
The organisational requirements, e.g. the register of processing activities, will undoubtedly be an area of focus for many data processors. We believe it may be useful that both parties expand the drafting exercise in relation to the data processing agreement and include, in the data processing agreement, all elements which the data processor must include in its register of processing activities. Instead of limiting the data processing agreement to the legal requirements, a blueprint of the data processing activity could be annexed. In doing so, the data processor’s administrative burden in relation to the register of data processing activities is reduced, whilst at the same time increasing compliance for both parties.
Given the obligation of data controllers to designate only reliable data processors, there will also be a strong case for certification to avoid onerous precontractual screening. Data processors that present evidence of adherence to internationally recognised standards (e.g. certification against ISO 27001) may consequently, considerably speed up the precontractual phase and reduce the administrative burden caused by repetitive compliance surveys.
The contractual practice of data processing agreements will also be changed by the GDPR, mainly because of the many new content related requirements. Standard templates will have to be adapted for use after 25 May 2018. The same applies to existing data processing agreements that continue after that date. However, in all honesty, it should be mentioned that many ICT related agreements already impose obligations that substantially comply with the new requirements of the GDPR: personal data breach notification, retransition, the information duty and the audit provisions are already included in many agreements to some extent. For these contracts, the exercise will mainly be limited to bringing the wording and practice in line with the new requirements, rather than completely renegotiating the agreements. However, in practice, it may be easier to simply replace the existing agreement without reviewing in detail the gaps between the current agreement and the future requirements.
[1] In the context of the implementation of Directive 1995/46/EC, some countries have imposed some obligations directly onto the data processor. E.g. Belgium, where the security obligation applies directly to the data processor also.
[2] The decision can be consulted here (Dutch only): http://deeplink.rechtspraak.nl/uitspraak?id=ECLI:NL:RBDHA:2016:14088.
[3] In relation to this topic, we refer to the recent guidance from the Article 29 Data Protection Working Party for more ample information: Article 29 Data Protection Working Party, Guidelines of 13 December 2016 on Data Protection Officers (‘DPOs’) and WP243 Annex – Frequently Asked Questions.
[4] As a result of the decision of the Court of Justice of the European Union in the so-called Schrems case, the European Commission is currently reviewing the existing model clauses.
[5] Article 29 Data Protection Working Party, FAQs of 12 July 2010 in order to address some issues raised by the entry into force of the EU Commission Decision 2010/87/EU of 5 February 2010 on standard contractual clauses for the transfer of personal data to processors established in third countries under Directive 95/46/EC.
[6] Article 29 Data Protection Working Party, Opinion 1/2010 of 16 February 2010 on the concepts of “controller” and “processor”.
