The sharing of personal data by businesses and other organisations is, within Europe and to an extent outside Europe, subject to the General Data Protection Regulation (GDPR). If your organisation is sharing personal data with another organisation, you should be thinking about the legal implications of the sharing.
It is useful to categorise sharing in order to get a clear idea of those legal implications, and to better understand the steps you should be taking to facilitate compliance with the GDPR. In this post, I highlight the key categories and distinctions. I consider, in particular, the contractual arrangements that organisations may need in place under the GDPR.
NB I use "share" and "transfer" interchangeably in this post.
CONTROLLERS AND PROCESSORS
Role of data transferor
Before thinking about any other aspect of a data sharing agreement, you should establish the role of the party making the transfer: is that party a controller or processor with respect to the shared personal data?
‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;
‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller;
Once you have established the role of the transferor, you need to think about the role of the transferee.
Data sharing by controllers
There 4 common types of sharing that may be initiated by a controller.
- Case 1.1: Sharing with an independent controller, where each party will independently determine the purposes for which the shared personal data may be used.
- Case 1.2: Sharing with a joint controller, where the parties together determine the purposes for which the shared data may be used.
- Case 1.3: Sharing with its own processor, where the controller passes personal data to another, so that the other can perform some tasks on behalf of the controller.
- Case 1.4: Sharing with another's processor, where a recipient processor is a processor on behalf of some third party.
Although the definition of controller references means as well as purposes, the latter seems to take precedence.
The categorisation above is not exhaustive. For example, a controller may share with a data subject or with a person acting entirely outside the scope of the GDPR. However, transfers to data subjects carry a different set of issues and are not considered here, while transfers to unregulated actors will be rare.
In Case 1.3, the Article 28 of the GDPR requires that the transfer be made under a contract, and that certain clauses be included in the contract. See below for more detail on Article 28.
In all the other Cases, there is no blanket requirement in the GDPR that a contract be entered into. However, guidance from the Information Commissioner's Office states that Case 1.1 and Case 1.2 require contracts in some situations. Case 1.4 can be seen as a variation on Case 1.1 or case 1.2 and, accordingly, may also require a contract.
So, when in those other Cases will a contract be needed? In general, the more risk that attaches to an arrangement, the more reason there is to have a contract. From the perspective of data protection law, the particular risks that are relevant are those affecting data subjects, rather than the organisations doing the sharing. Factors which may be relevant to risk include:
- the nature of the data being shared;
- the relationship between the parties;
- the level of oversight available to each party;
- whether the transfer is to a third country (ie from within the EEA to outside the EEA); and
- the regulatory regime in a recipient country.
I consider some of these factors in more detail below.
Data sharing by processors
Again ignoring transfers to data subjects and unregulated parties, there are 5 common ways that sharing by processors may be categorised by reference to the recipient's role under the GDPR.
- Case 2.1: Sharing with its own controller, where a party acting on behalf of a controller passes data to that controller.
- Case 2.2: Sharing with a third party controller, where a processor passes data to a controller, but that controller is not the processor's controller with respect the transferred data.
- Case 2.3: Sharing with own sub-processor, where the processor has appointed a person to handle the personal data on behalf of the processor.
- Case 2.4: Sharing with own controller's processor, i.e. passing data to a processor who is acting directly or indirectly on behalf of the transferor's own controller.
- Case 2.5: Sharing with a third party's processor, where the personal data is shared with another processor who is acting on behalf of a different controller.
The application of Article 28 to processor sharing
Article 28 applies directly or indirectly to each of these Cases.
In Case 2.1, the processor should have a contractual obligation to provide the data to its controller, at the end of the contract at least. There should also be an obligation to act only on the instructions of the controller, which is sometime implemented as an obligation to act upon the instructions of the controller – although with such an implementation the processor will want to see limits and qualifications upon the controller's power to instruct.
In Case 2.2, 2.4 and 2.5, the transfer should, again, only be made on the instructions of the original controller or if required by law. It will usually be a matter between the controller and (directly or indirectly) the recipient to put in place appropriate contractual terms in each of these circumstances.
Article 28 applies with full force to Case 2.3: transfers from a processor to its sub-processor must be made under a contract complying with the Article 28 requirements.
Article 28(3) sets out the core rules (although it ends with a confusing error, perhaps a typo):
Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that 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. 2That contract or other legal act shall stipulate, in particular, that the processor:
(a) processes the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the processor is subject; in such a case, the processor shall inform the controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest;
(b) ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;
(c) takes all measures required pursuant to Article 32;
(d) respects the conditions referred to in paragraphs 2 and 4 for engaging another processor;
(e) taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III;
(f) assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor;
(g) at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data;
(h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller.
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.
RISKS AND DISTINCTIONS
Mutual or unilateral?
After you have established the formal roles of the parties, and whether and how Article 28 applies, you need to think about some of the specific features of the sharing. This will help you to decide whether a contract is necessary and what issues to deal with in any contract.
First, does the arrangement involve the transfer of personal data from one party to another, or will data travel both ways?
Although in principle more complex, mutual agreements may be easier to negotiate because: what is good for the goose is good for the gander. Where data is travelling in both directions, you should however take care to think about the effects of each mutual provision from both perspectives.
Occasional or systematic?
Some transfers are one-off, or occasional; other are systematic. In some situations, data may be pooled, with the sharing parties having independent access to the data. In other cases, transfers may be discrete acts of sharing.
Where Article 28 does not apply, for example in the case of controller-to-controller transfers, then one-off and discrete transfers may not require a contract. Systematic and ongoing transfers are more likely to create risks, and therefore more likely to require a formal contract.
However, even one-off discrete transfers may create risks, and may require contractual protections.
Arms' length or intra-group?
Is the sharing between unconnected parties, or between related companies?
All else being equal, an arms' length agreement is more likely to create risks for both organisations, and with more risks more contractual protections should be put in place.
In the case of intra-group transfers, the group structure is also important. If the transferor organisation has full control over the transferee organisation, then fewer protections may be needed. If the two organisations are semi-independent, then it may be sensible to treat the transfer as akin to an arms' length transfer.
Special or un-special?
Does the sharing involve special categories of personal data or data relating to criminal convictions?
"Special categories" refers to:
personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.
An obvious point, but the sharing of special categories creates more risks. Many of the bigger fines we have seen issue by supervisory authorities under the old regime arose out of data breaches featuring medical data and other types of sensitive data.
Again, with more risks should mean more mitigation, including but not limited to contractual mitigation.
Automated processing and profiling
As with special categories, sharing arrangements which involve automated processing and profiling of data subjects may create more risks.
Intra-EEA or extra-EEA?
Last, but by no means least, you need to take full account of the distinction between transfers within the EEA and transfers out. Chapter 5 of the GDPR sets out the requirements for the transfers out.
Assuming the recipient country does not benefit from an adequacy decision, the easiest way to comply with the rules is to apply the "standard contractual clauses" to such transfers; however, we don't currently have any such clauses for processor-to-sub-processor transfers, and as a result it is these transfers which cause the most problems. The law of agency can be used as workaround here, with the processor entering into the standard clauses as agent for either the controller or the sub-processor, but sometimes this is not practicable.
Lastly, don't forget to consider the effects of the law in the jurisdiction to which data is transferred. In some cases, there may be an irreconcilable contradiction between EU law and applicable national law.
In this post, I've sketched the main legal distinctions that affect data sharing agreements, and discussed some of the issues which you should think about when entering to these agreements.
Notwithstanding that many of the rules on data sharing are an evolution of the earlier rules under the Data Protection Directive, I'm expecting the volume of formal data sharing agreements to increase significantly now that the GDPR is in force.
Because the GDPR is much less prescriptive when it comes to sharing with controllers as compared to transfers to processors, it is likely to take some time before practice becomes settled.