Data Protection: what will be/is already/ the impact of the GDPR on service providers?

Data Protection: what will be/is the impact of the GDPR on service providers?

This Memo is intended for discussion purposes only. All comments and remarks are welcomed and appreciated.

The GDPR (General Data Protection Regulation) will come into force in 2018. This Memo offers a perspective for IT companies preparing for change, with a focus on operational and practical aspects.

Reminder about two definitions (Article 4):

‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction

‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.

Outsourced service providers act as processors when dealing with their customers’ data. This includes all companies providing HR, Security and IT services, to the extent they have access to personal data owned and controlled by their customers (i.e. employees or customers or business partners of their customers).

• The GDPR will have a worldwide legal impact
• The GDPR is having an immediate business impact
• New Risks
• New Costs
• Impact on projects having already gone live (technical and functional impact)
• Binding Corporate Rules (« BCR ») for processors

The GDPR will have a worldwide legal impact

The GDPR will have an impact beyond the EU, and this, in two directions.

• Non-EU processors

Article (3)(2) takes the location of the Data Subjects as the key criteria (“Data subjects who are in the Union”). The GDPR will apply regardless of where the data of Europeans is processed. The following companies and activities will thus fall in the scope of the GDPR:

+ A: Any non-EU IT company (e.g. Indian company) hosting or processing personal data on behalf of EU Customers;

+ B: Any non-EU IT company acting as sub-contractor of “A” (even though such processor has no contract with any EU company);

+ C: Any non-EU company targeting consumers/Users in the EU;

+ D: Any non-EU IT company acting as sub-contractor of “C“ (even though the processor in question has no contract with any EU company).

At the same time, all such offshore data processing activities will remain subject to local laws (USA, India…). This may lead to some difficulties for the lawyers involved.

Suggestion: Possible conflicts of law (GDPR vs. non-EU local law) should be identified upfront. Discussing with the authorities may be an option if such conflict is identified (…).

• Personal Data relating to non-EU residents

Based on Article (3)(1), European IT companies processing data relating to non-EU residents on behalf of non-EU customers could also fall in the scope of the GDPR. This paragraph of the GDPR makes no distinction between EU residents and non-EU residents (“a processor in the Union”). It looks like all activities of European processors are caught by the GDPR, regardless of where the Data Subjects are located.

Will we see one day a claim brought by a citizen of Brazil, USA or India (or from the UK…) against a European processor for breach of the GDPR?

The GDPR is having an immediate business impact

As a result of Article 28(1), compliance with Data Protection rules is already becoming an evaluation criteria of the highest level for customers looking for new service providers. In the context of RFPs, Processors not able to provide sufficient guarantees are already now progressively excluded from the short list.

Article 28

Processor

1. Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject (emphasis added).

Suggestion: having policies and a governance framework in place and implemented is becoming a must for all processors impacted by the GDPR. The only question is about the “how” (with Binding Corporate Rules – BCR – as an option, See BCR Section below). Appropriate technical and organisational measures must be implemented.

New Risks

• Processor’s direct obligations

Data Processors will be much more exposed than under the current regime. They will be directly liable for the security of personal data and for transfers outside Europe. In this respect, Data Processors will be directly confronted to Data subjects, supervisory authorities and consumers associations, with all the impact this type of interaction may have on the image of the company.

Suggestion: Communication Department to be informed about this risk as this is something completely new (except for telecom companies, already required to notify their customers about security breaches, and used to deal with journalists and social media about this type of issue).

• Class-actions

Any association acting in the public interest (human rights, consumers associations etc.) will be able to bring a claim on behalf of affected individuals. In practice, this means that claims will be brought more often, and this, in a rather aggressive way (See the recent evolution in Germany…). Such empowerment of consumers in data protection is one the biggest change brought by the GDPR. Processors must be prepared.

• Responsibility of the Processor in case of violation of the GDPR by the Controller (See: Article 28(3)(f) and 28(3)(h), Article 82).

Based on the above-mentioned articles, it cannot be excluded that a Processor will find itself liable for a failure by a customer to comply with the GDPR.

Suggestion: revisit standard terms, starting with the indemnification clause (customer to indemnify the processor in case the processor is sanctioned because of a violation of the GDPR by the customer). As a side-note, it is rather certain that contract negotiations will become more complex…

Note (text mining…): the GDPR contains twelve occurrences of the expression “controllers and processors”, twelve occurrences of “the controller and the processor”, and more than one hundred occurrences of “controller or processor”! This simple fact shows that the two roles tend to converge. The benefit for being a mere processor becomes less and less clear.

Suggestion: as a reaction to this sort of confusion between the two roles, processors should consider taking the position of “joint controller” (Art. 26), in some cases, as an alternative to the classical processor position. At least, this somewhat radical approach will bring clarity. This scenario is not appropriate when dealing with HR Data (HR Data must remain under the sole responsibility of the employer). But it could be considered for other cases, typically with a processor having an active role to play in the processing of the data, given its flexibility (« They shall in a transparent manner determine their respective responsibilities for compliance with the obligations under this Regulation« ). Article 26 makes it possible for a controller and a processor to define their own rules, including the allocation of responsibility between them.

Suggestion for the Regulators: Copyright rules include a distinction between publishers and hosting providers (See Directive 2000/31/EC, “Article 14 – Hosting 1. Where an information society service is provided that consists of the storage of information provided by a recipient of the service, Member States shall ensure that the service provider is not liable for the information stored at the request of a recipient of the service, on condition that: …“). The hosting provider has a duty to remove access to infringing material upon proper notification from the copyright owner, but clearly such provider has no duty to monitor all the contents posted by its customers. This is true only for pure hosting providers. By contrast, publishers can be directly held liable for infringement.

The GDPR does not include any such distinction. Cloud services providers with no control over the stored data such like IaaS providers (IaaS: Infrastructure as a Service) are treated like providers directly involved in the processing of the data. It looks like IaaS and SaaS providers shall be equally responsible for any breach of the GDPR affecting the rights of the data subjects. This lack of distinction has already triggered a strong reaction from an association of IaaS providers (See CISPE).

A comparison between Article 23(3) GDPR and the Article 15 of this copyright Directive (No general obligation to monitor – 1. Member States shall not impose a general obligation on providers, when providing the services covered by Articles 12, 13 and 14, to monitor the information which they transmit or store, nor a general obligation actively to seek facts or circumstances indicating illegal activity) illustrates two opposite solutions to the problem of the hosting providers’ responsibility in case of illegal content installed by the customer (Article 28(3)(h) GDPR: With regard to point (h) of the first subparagraph, the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions).

A likely scenario is that the Data Subject will notify the hosting provider about the illegal processing of data concerning him/her, just like copyright owners do. The Data Subject will then exercise his/her rights (access, rectification, erasure etc.). But the GDPR makes it possible for the Data Subject to sue directly the processor (Article 79). And if the problem affects not only some Data Subjects but the whole process, the processor will be in a difficult situation…

Lack of control usually excludes responsibility! This is not going to be the case in the context of the GDPR, unless regulators address the issue in one way or another.

New Costs

The GDPR will result in a much greater compliance burden for all IT companies that process personal data as part of the services delivered to their customers.

• Records

Processors should implement measures to prepare records of their processing activities, as this is going to become a legal obligation.

Suggestion: Consider developing a web-based platform for this inventory (Art. (30) (2)), and make it accessible to your customers. As an option (possibly a chargeable option), such platform could also be used by them for their own inventory (Art. (30) (1)). The GDPR also creates business opportunities!

As a result of the GDPR, any given data processing involving a processor will be documented twice: by the Controller, and by the Processor. The same obligations applies to both. It is clear that any difference/inconsistency between the two documentations will be problematic, if identified by a Data Subject or an Authority. With or without making business on the basis of this legal obligation, the Processor will have to collaborate with the Controller to ensure consistency between the two records. Still more work for the DPOs!

• Training

Processors must ensure that all employees having permanent or regular access to personal data receive appropriate training about Data Protection (See Article 39 (1) (b), Article 32 (4) and Article 47 (2) (n)) (See below). This is going to represent a cost.

• Monitoring of the regulatory evolutions

The GDPR opens the door to multiple types of regulation, incl. codes of conduct, certification mechanisms… Evolutions will not come only from the regulators. To a certain extent, the GDPR should be seen as a general framework, leaving room for multiple and variable interpretations / guidelines / Opinions at country or EU level.

Suggestion: Processors should, on an ongoing basis, monitor the publication of supervisory authorities and industry published codes of practice. Some of them may have an impact on their business (incl. the business of their customers that has been outsourced to them). The GDPR is going to be a never-ending story!

• Monitoring of sub-contractors

Sub-contractors must be monitored as to their compliance with Data Protection rules (Article 28 (4)). For a vast majority of Processors this is not going to be a new task.

Impact on projects having already gone live (technical and functional impact)

The GDPR must be implemented effectively. Data processing activities will have to be adapted, practically, to the following requirements:

• Data breach notification

Internal process is to be defined in order to make sure all breaches will be detected and reported.

• Right to be forgotten

A deletion process is to be defined. But deleting the data will not be sufficient. The processor must also inform the “recipients”, incl. sub-contractors that the data must be deleted.

Suggestion: Take a proactive approach and start discussing with the concerned customers about the required changes. Consider implementing a centralized and standard process for Data Breach notification and Right to be forgotten, applicable to all customers (vs. one process and one governance scheme per customer…). Processors (typically Processors providing public cloud services) should define their own processes and make them applicable to all their customers without customer-specific deviations.

All processes falling in the scope of the GDPR will have to be adapted to the two above requirements.

The two following requirements will impact some processes, depending on whether they include the regulated feature.

Collection (and recording) of consent (Article 7, Article 8): there are new requirements about the quality of consent, e.g. separate consents must be obtained for distinct processing operations.

Automated decision (Article 22): a manual intervention must be possible on the part of the controller, typically in Big Data environments with predictive analytics. Any Data Subject will have the right to contest the decision taken by the algorithm against him or her. This scenario must be implemented in practice, which means that the concerned processors will be solicited.

These tasks are under the responsibility of the controller, but (1) the line between controller’s responsibility and processor’s responsibility can be difficult to draw, as explained above and (2) practically speaking, the last months before the entry into force of the GDPR may be difficult, with IT companies overwhelmed by change requests. Let us anticipate these change requests!

Binding Corporate Rules for processors

The GDPR encourages IT companies operating globally to adopt Binding Corporate Rules (Recitals 108, 109 and 110). Until recently the BCR option was open only to controllers. It is now also open for processors.

As far as processors are concerned, there are at least two arguments in favor of this approach.

• Legal basis for crossborder data transfers

Firstly, BCRs provide a legal basis for cross-border transfers of personal data outside the EU, within the company, by way of a worldwide policy applicable to all subsidiaries. This legal instrument has not been challenged so far before the Courts (unlike the US Safe Harbor…). But the benefit of having BCRs goes beyond this pure legal aspect.

• A global policy, well adapted to the global scope of the GDPR

Secondly, from a practical perspective, the expected extension of scope of European rules beyond the boundaries of Europe (see above) makes it even more appropriate to adopt a worldwide global and harmonized approach. This is what the BCR approach is about. BCRs, with all required implementation measures, can be used as a commercial argument, when discussing with controllers seeking to comply with Article 28 (1).

The BCR processor cooperation process has already been successfully conducted under the supervision of either the Dutch DPA or the French DPA acting as lead authorities (incl. Align Technologies B.V., BMC Software, Capgemini, Atos). No doubt that more IT companies will follow this approach!

Suggestion for the Regulators: With the entry into force of the new GDPR in May 2018, companies will have to be able to demonstrate to the data protection authorities that they have put in place the means to comply with the law under the new accountability principle. When further defining the requirements of the means enabling compliance with GDPR, article 29 WP (and EDPB in the near future) should include BCR as a valid accountability demonstration mechanism having the same demonstration effectiveness as others (codes of conduct, certification mechanisms).

BCR were put in place by Article 29 WP to serve as a personal data transfer mechanism to third countries on the basis of article 25 of Directive 95/46 of 24 October 1995. Now, BCR are a perfect accountability tool as defined in GDPR, and should be recognized as such by the Authorities (Note: this aspect is also valid for Controllers).

Emmanuel Cauvin

(*)

GDPR: Training as a legal obligation

Article 39 1 (b)

(b) to monitor compliance with this Regulation, with other Union or Member State data protection provisions and with the policies of the controller or processor in relation to the protection of personal data, including the assignment of responsibilities, awareness-raising and training of staff involved in processing operations, and the related audits;

Article 47 2 (h)

…monitoring compliance with the binding corporate rules within the group of undertakings, or group of enterprises engaged in a joint economic activity, as well as monitoring training and

Article 47 2 (n)

…the appropriate data protection training to personnel having permanent or regular access to personal data.

Article 32 4

The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law.