Executive Summary

  • On 17 December 2020, the Information Commissioner’s Office (“ICO”) published a new Data Sharing Code of Practice (the “Code”). As nearly ten years have passed since the implementation of the previous data sharing code published by the ICO, the new Code has been updated to reflect key changes in data protection laws and the ways in which organisations share and use personal data.
  • The Code serves to compile all of the practical considerations that organisations need to take into account when sharing personal data with other parties, bringing together existing items of ICO guidance (e.g. in relation to ensuring a legal basis has been satisfied) and supplementing this with new guidance (e.g. in relation to data sharing issues that arise when conducting due diligence in M&A transactions).
  • Whilst the Code makes reference to data sharing in the context of new technologies and concepts that were not in existence at the time of the previous data sharing code (e.g. automated decision-making), the Code does not address certain perennial issues in detail, such as the distinction between anonymisation and pseudonymisation and the impact on data sharing.
  • Even though the Code does not represent a huge departure from the previous data sharing code and has been somewhat lost in amongst the glut of guidance that has been released by the ICO and EDPB in recent months, it is still a largely helpful piece of guidance that organisations should carefully consider to ensure that they are adhering to its recommendations.

In this article we pull out aspects of the Code that we deem to be noteworthy, such as the practical steps that organisations need to consider when sharing personal data with other parties and our views in relation to whether the Code is fit for a digital age.

Background

Given that the previous data sharing code was published by the ICO almost ten years ago in May 2011, one of the ICO’s key objectives when preparing the new Code was to bring its guidance up-to-date to reflect the current regulatory landscape following the implementation of the General Data Protection Regulation (“GDPR”) and the Data Protection Act 2018 (the “DPA”) (the Code also makes reference to the UK’s exit from the European Union and the EU GDPR being written into UK law  through the European Union Withdrawal Act 2018, clarifying that references to the GDPR in the Code should be read as references to the UK GDPR) together with various technologies commonly used by organisations involving personal data e.g. automated decision-making.

Whilst the Code was published on 17 December 2020, the Information Commissioner has described the publication of the Code as “not a conclusion but as a milestone in this ongoing work” and has already announced plans to update the ICO’s guidance on anonymisation under the Code.

Scope of the Code

Section 121 of the DPA defines data sharing as “the disclosure of personal data by transmission, dissemination or otherwise making it available” and covers data sharing between either separate or joint data controllers and it is this type of data sharing between controllers that the Code focusses on as opposed to data sharing between controllers and processors.

The Code covers two main types of data sharing, namely:

  1. routine (also called systematic) data sharing which is conducted on a regular basis; and
  2. exceptional data sharing, which occurs on a one-off basis, either ad hoc or in emergency situations.

Whilst the previous data sharing code addressed exceptional data sharing to a degree, the Code dedicates a new section to data sharing in urgent and emergency situations, emphasising the benefits of data sharing by referring to recent tragedies such as the fire at Grenfell Tower and terrorist attacks in London. The Code also singles out how proportionate, targeted data sharing (e.g. through the NHS Test and Trace system) can make a positive difference in unprecedented emergencies such as the coronavirus pandemic.

The Code addresses the sharing of personal data, including pseudonymised data (distinct from truly anonymised data), defined by Article 4 of the GDPR as “the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person”. An example of pseudonymised data is where an organisation shares seemingly anonymous data, but the individual can be re-identified with the help of additional information such as internal identifiers (e.g. account numbers) or publically available information (e.g. social media or voter registration records). In such circumstances, the pseudonymised data needs to be treated as personal data in accordance with the Code and the GDPR.

Practical steps for organisations

While much of the Code serves to bring together existing items of ICO guidance that organisations need to comply with when conducting data sharing (e.g. in relation to ensuring a legal basis has been satisfied in relation to the sharing), the Code offers a number of items of new guidance, which we have summarised below:

1. Data Protection Impact Assessments

Organisations should conduct a Data Protection Impact Assessment (“DPIA”) when considering sharing personal data. The aim of a DPIA is to assess the risk of the data sharing and identify where additional safeguards are needed. Carrying out a DPIA is mandatory for data sharing that is likely to result in a high risk to individuals.

However, due to the accountability principle under the GDPR, organisations will still need to demonstrate their compliance with data protection laws in relation to data sharing. As such, even where it is not mandatory to carry out a DPIA in relation to proposed data sharing, the Code recommends that organisations maintain a record of the reasoning as to why a DPIA has not been undertaken and details of the level of expected risk associated with the data sharing.

When faced with an emergency situation which requires data to be shared in a way that is likely to involve a high risk to individuals, the Code recognises that can often be difficult for organisations to conduct DPIAs in advance of such sharing. Instead, the ICO recommends that organisations who are likely to be responding to emergency situations should consider conducting pre-emptive DPIAs in advance where possible.

2. Data Sharing Agreements

The aim of a Data Sharing Agreement (“DSA”) is to establish the particulars regarding a proposed instance of data sharing between two or more controllers, such as the roles of the parties, the purpose for which data is being shared and compliance standards that each of the parties need to meet in relation to the sharing and any subsequent processing of the personal data in clear and concise language.

The Code provides practical examples of what organisations should include in a DSA, e.g. a model form for seeking individuals’ consent for data sharing (if appropriate), a decision flow diagram to assist with deciding whether or not it is appropriate to share data and a process to be followed by the parties when an individual exercises their rights against either or both of the parties.

Although it is only compulsory under the GDPR to put a DSA in place where a joint controller relationship is established between two or more parties, the Code recommends that organisations also put a DSA in place to address data sharing between separate or independent controllers in addition, especially given that the ICO will take into account the existence of a DSA when assessing any issues or complaints arising out of an instance of data sharing between controllers, irrespective of whether they share data jointly or independently/separately.

3. Responsibility of disclosing party for recipient’s processing of personal data

For a long time, the extent to which an independent controller which discloses personal data to another controller bears responsibility for the recipient’s processing of that personal data has been somewhat unclear. The Code attempts to provide clarity in relation to this issue, stating that an organisation cannot provide personal data to another when it has no visibility over the measures that the recipient has implemented to ensure that the personal data is consistently protected at all stages of the data sharing.

This indicates that an independent controller that discloses personal data to another needs to ensure that the recipient is subject to sufficiently robust contractual obligations and standards in relation to its handling of personal data upon receipt and undertake a degree of due diligence in relation to the underlying arrangements, for example in relation to the security measures that the recipient has in place.

4. M&A transactions

When one or more parties are involved in an M&A transaction or restructuring which involves the sharing of personal data and/or a change in the identity of the controller, the parties involved need to ensure that due diligence extends to examining issues pertaining to the transfer/sharing of personal data in connection with the transaction. This should include conducting an analysis of:

    1. the purposes for which the personal data was originally obtained;
    2. the lawful bases for the processing of such data;
    3. the lawful basis for sharing such data with a third party (for example, whether privacy notices made available to individuals at the time their data was collected stated that their data would be shared/sold to a purchasing organisation in case of an acquisition);
    4. whether, following the acquisition, the purposes for processing is to change (for example, if the selling organisation collected personal data from customers purely to set up an account with them, the buying organisation cannot use this personal data for a different purpose (e.g. research) without carrying out appropriate compliance steps to legitimise this new purpose); and
    5. whether technical advice is required before sharing data, especially when different systems are involved as there is a potential security risk that the data could be lost, corrupted or degraded.

5. Sharing personal data in databases and lists

The transfer or sharing of any database or list of individuals is also addressed in the Code, which places the onus on any recipient of a database or list of personal data from another party to establish the provenance or integrity of this data and to ensure that all compliance obligations have been met prior to exploiting or otherwise using the data.

The Code makes various recommendations in relation to confirming the source of the data, identifying the lawful basis on which it was obtained, checking what the individuals were told when their data was collected and that the data is accurate and up-to-date.

The Code also refers out to the ICO’s detailed guidance on direct marketing, which indicates that a recipient of a database or list of personal data cannot rely on marketing consents obtained another party to justify its own use of this personal data for direct marketing purposes unless the original consent specifically named the recipient who wishes to rely on the consent.

A code fit for a digital age

As previously mentioned, the ICO’s intention is for the Code to be “up-to-date on current cyber-related privacy issues and to provide a roadmap in anticipating future technological developments”.

The Code seeks to address items such as automated decision-making, which has become more prevalent since the previous code was published and touches on the difference between anonymised data and pseudonymised data.

Automated decision-making

Article 22 of the GDPR sets out the rules which apply to organisations which carry out automated decision making i.e. a decision made with no human influence on the outcome.

The Code makes it clear that a number of steps need to be taken in relation to any data sharing arrangement involving automated decision-making (e.g. if an organisation were to use an algorithm to determine whether or not an individual’s personal data is shared with a third party recipient) namely that a DPIA must be carried out, all requirements set out in Article 22 need to be met in relation to the processing (e.g. individuals should receive an explanation on their rights to challenge a decision and request human intervention) and measures need to be put in place to prevent errors, bias and discrimination in the system.

The difference between anonymised data and pseudonymised data

The Code distinguishes between anonymised and pseudonymised data, specifying that the Code applies to  pseudonymised data (where the individual can be re-identified from data with the use of additional information) but does not extend to truly anonymised data (where the information cannot identify an individual in any way). An example of pseudonymised data would be a spreadsheet containing travel data with the names and addresses of relevant individuals redacted but which could be combined with other data available to the organisation to re-identify the individuals e.g. publicly available information such as social media account details or even an un-redacted version of the spreadsheet stored separately to the redacted version. Conversely, an example of anonymised information would be the publication of data at an aggregated level, which means that the data is stripped of any element that would identify any individuals.

The ICO has recently published a blog post stating that they are gathering insight and feedback over the coming months before publishing further guidance on anonymisation and pseudonymisation.

It will be interesting to see whether or not the updated guidance addresses a number of perennial questions, namely:

  1. Does the same level of protection apply to pseudonymised data as traditional personal data under the GDPR?
  2. What steps need to be taken to change the status of pseudonymised data to anonymised data e.g. if an organisation destroys what they consider to be all additional information that would allow them to re-identify individuals in the pseudonymised data before sharing the data with a third party, does this render the data truly anonymised?
  3. If pseudonymised data is shared with a third party which has no access to the information to re-identify the individuals (which is kept confidentially by the disclosing party only), does the third party still need to treat the data as pseudonymised data if the data is effectively anonymised in the hands of this third party? Further, is the third party responsible for ensuring that the data is kept accurate and up to date when the third party does not have the information to identify the individuals without assistance from the disclosing party?
  4. What provisions need to be included in a DSA governing the sharing of pseudonymised data?

Conclusion

Whilst the Code is far from revolutionary and does not set out any guidance that deviates substantially from what has gone before, organisations should carefully review their data sharing practices against the Code and keep track of upcoming guidance and resources published by the ICO which relates to data sharing.

Duc Tran
Duc Tran
Senior Associate, Data Protection and Privacy, London
+44 20 7466 2954