ICO issues draft International Data Transfer Agreement and guidance on undertaking risk assessments for consultation on ensuring compliance for data transfers from the UK

The UK has taken its first big data protection step in a post-Brexit world with the Information Commissioner’s Office (“ICO“) publishing its own version of an international data transfer agreement and accompanying methodology for conducting international risk assessments on 11 August 2021.

The ICO has published the following documents, which all inter-relate with one another:

  1. a draft international data transfer agreement to address transfers of personal data outside of the UK (“IDTA“) (available here);
  2. an international transfer risk assessment guidance note and tool (the “Risk Assessment Guidance“) (available here); and
  3. a UK addendum for inclusion to the European Commission’s standard contractual clauses (the “Addendum“) (available here).

The ICO has launched a consultation seeking views on the IDTA, the Risk Assessment Guidance, and the Addendum which will close on 7 October 2021, following which proposals will be laid before Parliament.

This follows in the footsteps of a busy period for the EU regarding the issue of international transfers of personal data. Over the past few months, we have seen:

  • the European Commission publish its final version standard contractual clauses for the international transfer of personal data to third countries (the “New EU SCCs“) (see our blog post here) and Article 28 clauses (see our blog post here);
  • the European Commission adopt two adequacy decisions for the UK (under both the GDPR and the Law Enforcement Directive); and
  • the EDPB issue its finalised guidance on supplementary tools resulting from the Schrems II judgment from the Court of Justice of the European Union (see our blog post here).

Key Takeaways

  • The UK’s approach – The ICO has adopted a user-friendly, business-focused and streamlined approach to implementing an updated set of Standard Contractual Clauses to address transfers of personal data outside of the UK and has devised a similarly user-oriented and pragmatic mechanism for conducting risk assessments in relation to these transfers (each a “TRA“), required as a result of the Schrems II decision. In addition, the Addendum provides an effective mechanism for UK organisations to interface with EU requirements in relation to transferring personal data outside of the EU and the scope of the consultation highlights the ICO’s willingness to integrate with global privacy positions.
  • The IDTA – The IDTA diverges from the approach of the New EU SCCs in its nature and structure in that it is formed of a combination of tables, free text, and mandatory clauses in order to provide organisations with flexibility to adapt it to their circumstances and any pre-existing contractual arrangements, as well as being a relatively simple document for organisations (particularly smaller ones) to contend with. Notably it caters for C2C, C2P, and P2P scenarios but not P2C (each defined below) and does not follow a modular format in the same manner as the New EU SCCs. The mandatory provisions of the IDTA are broadly reasonable in placing obligations on both exporting and importing parties, however they do take on a distinctly English law flavour and include some potentially controversial clauses, for example in relation to incorporating TRAs and commercial positions, English language requirements, and the introduction of an IDTA-specific arbitration scheme.   
  • The TRA The Risk Assessment Guidance is a helpful and detailed attempt by the ICO to support organisations with their obligation to undertake a TRA. It adopts a solution-oriented and risk-focused approach that suggests a range of considerations, decision trees, and mitigations which organisations can apply when undertaking a TRA and will form an integral part of putting in place an IDTA.   
  • Timeline – The ICO has issued the IDTA, Risk Assessment Guidance, and Addendum for consultation to seek industry stakeholder views, notably in the context of legal, economic or policy considerations. The consultation closes on 7 October 2021 following which consultation analysis and finalisation will occur before putting the proposals before Parliament. A finalised IDTA, Risk Assessment Guidance, and Addendum could be expected in late 2021 or early 2022 and, in the consultation, the ICO is also seeking views on transition periods post-implementation, namely: a 3 month grace period for organisations to introduce IDTAs for new arrangements, with a further 21 months (i.e. 24 months in total) to repaper existing arrangements.

Legal Background

Chapter V of the UK GDPR prohibits the transfer of personal data out of the UK to a third country or international organisation unless one of a number of available conditions under the UK GDPR is satisfied.

One of the conditions most often relied upon to legitimise the international transfer of personal data is the use of so-called Standard Contractual Clauses (effectively a contract entered into between the data exporter and the data importer and impose certain data protection obligations on both parties).

Prior to Brexit, the UK utilised two different sets of SCCs which had been approved by the European Commission to cover transfers from: (i) a controller to another controller (“C2C“); and (ii) a controller to a processor (“C2P“) (the “Old EU SCCs“).

Following Brexit, the European Commission has published the New EU SCCs to update the Old EU SCCs in light of GDPR, the Schrems litigation, and to remediate a number of weaknesses in the drafting. However the New EU SCCs do not apply to transfers from the UK to jurisdictions outside the UK, and UK-based organisations have in the meantime needed to rely on the Old EU SCCs when transferring personal data outside of the UK.

As a result, the ICO has been working to establish the UK’s position in relation to legitimising international transfers of personal data out of the UK from a contractual and logistical perspective and the IDTA and Risk Assessment Guidance is the result.

Given the interplay with the New EU SCCs, the UK’s approach has been keenly awaited and in this blog we “summarise” (the IDTA and Risk Assessment Guidance are lengthy) some of the key changes and considerations for organisations and international data flows.

The UK’s approach to standard contractual clauses

In this section, we look at each of the IDTA, Risk Assessment Guidance, and Addendum in more detail.


IDTA Overview

The IDTA is the document which UK organisations will need to put in place when transferring personal data outside of the UK.

The ICO has adopted a distinct approach to the IDTA, in particular:

  • Nature of the agreement: The IDTA has been developed as an agreement which can either act as a standalone data transfer agreement between parties, or be incorporated into a broader commercial agreement or other arrangement (termed “Linked Agreements” by the ICO).
  • Structure: We discuss the structure in more detail below, but broadly it consists of a combination of tables alongside a set of mandatory operative provisions and free text sections. This appears to have been designed to enable the parties to it to adapt it to their particular needs and broader contracting arrangements.  
  • Controller and processor data flows: As with the New EU SCCs, the ICO has ensured that the IDTA is appropriate for use in C2C, C2P, and processor to processor (“P2P“) scenarios. The IDTA does not, however, contain any clauses to address cross-border transfers from processors to controllers (“P2C“), which the European Commission controversially introduced in the New EU SCCs.
  • Application of the relevant provisions: The IDTA does not follow a strictly modular structure (as per the New EU SCCs) and has instead developed provisions which are designed to be applicable depending on the factual circumstances of the parties (e.g. if the importer’s processing is subject to UK data protection law, then the importer does not need to comply with clauses regarding data subject rights (on the basis that they will be directly applicable)). The IDTA does provide that non-applicable provisions can be removed but, as discussed below, this does not appear to be mandatory and therefore is unlikely to happen in practice when organisations start implementing the IDTA.

The approach taken by the ICO appears to provide a more streamlined, flexible, and business-friendly mechanism for organisations to deploy the IDTA where necessary, certainly in terms of its non-modular nature and accessible manner in detailing the necessary elements of a transfer. In comparison to the New EU SCCs, the removal of a potentially complex and time-consuming analysis to implement the appropriate combination of modules is to be welcomed, although the ‘if applicable’ approach of the IDTA mandatory clauses does present its own challenges of interpretation, not only to the uninitiated.

IDTA Structure

Considering the IDTA at a more granular level, it has been arranged in four parts:

  1. A series of four tables to detail the nature of the transfer and any further protections (this includes population of the relevant details of the importer and exporter, a string of check-boxes to document information on the transfer itself and data involved, and a free text area to including additional security requirements which have been identified as necessary further to a TRA).
  2. A section where additional technical, organisational, and contractual protections can be set out which have been identified as necessary following a TRA (and for which the ICO’s TRA tool provides examples). This section envisages being able to cross-refer to relevant other areas (e.g. relevant parts of a Linked Agreement or the security requirements sections of the first part of the IDTA).
  3. A section for commercial clauses which, while perhaps useful for smaller organisations and low-risk arrangements, is likely to have limited utility with parties almost certainly having a distinct commercial arrangement (i.e. a Linked Agreement) and requiring one in a C2P scenario in order to have in place appropriate Article 28 clauses.
  4. The mandatory clauses which, ultimately, are the most important, operative part of the IDTA and are discussed in detail below.

This structure provides an adaptable model which organisations should find relatively simple to both populate and review, which should assist organisations will putting in place, and feeling comfortable about, a compliant international data transfer arrangement.

Mandatory Clauses

The fourth part of the IDTA is an area which will attract a significant amount of scrutiny given the mandatory nature of the clauses, and indeed it proposes some particularly notable positions:

  • Amendments: The IDTA does not permit any amendments other than: to update cross-references where amendments to parts one to three of the IDTA require it; in order to render the IDTA multi-party; and to dis-apply any non-applicable provisions.

In relation to the latter point, as noted above, the IDTA is not strictly modular, however the mandatory clauses contain a range of caveat drafting across them which dis-applies certain clauses depending on the nature of the party (controller, processor). While simplifying the approach in terms of incorporating the IDTA (i.e. rather than choosing specific modules as per the EU’s mechanism), the interoperability of clauses is not always clear. Additionally, where parties do dis-apply provisions, given it would appear that dis-applied provisions will apply regardless if they were incorrectly dis-applied, there is perhaps little utility to undertaking such a task. The publication by the ICO of worked versions of amended mandatory clauses would perhaps be useful in this regard.

  • Precedence: The terms of the IDTA will take precedence over any Linked Agreement or other agreement (which could include the New EU SCCs), unless there is greater protection provided by other terms or the other terms are a requirement due to Article 28 of UK GDPR. A potential conflict between EU and UK positions (each of the IDTA and New EU SCCs claim precedence) has, from a UK perspective, been to some extent fudged in leaving it to a consideration of the relative level of a protection of a term.
  • TRAs: There is a somewhat unsatisfactory circular contractual position whereby the exporter is under a duty to provide the importer with a copy of any TRA the exporter has undertaken, but the importer is bound to a contractual promise that prior to entering the IDTA it has provided the exporter with “all relevant information” which is “complete and accurate” (a high bar) regarding the local laws of the importing country in order to enable the importer to undertake the TRA. The importer is also under a continuing obligation to verify whether local laws change and inform an exporter if such change would impact its ability to comply with its obligations under the IDTA.

Given the broad definition of ‘local laws’ under the IDTA, this raises several issues including the implications for pre-contractual representations and information provision, the quality of knowledge of an importer, and the extent to which importers will or can comply with such an onerous obligation.

  • ICO involvement: The IDTA provides that both importer and exporter agree to provide the ICO with certain information (including the IDTA, any TRA, and the importer’s information regarding local laws) where it reasonably requests it. As well as providing the ICO with an avenue to access a substantial amount of information on local law requirements and risk assessments, these provisions place a direct obligation on an importing entity who perhaps might have no other link to the UK, to provide information to a UK-based regulatory information request (of particular relevance to entities further down in a chain of processors).
  • Data subject requests: The IDTA provides that, where a data subject requests a copy of the IDTA from the exporter or importer, this must be provided to them. It is accepted that Linked Agreements do not need to be provided however, if the commercial clauses section of the IDTA is used, while they can be redacted for the purposes of sending to a data subject, a summary of the information must be provided. As such it seems unlikely that parties would complete this section of the IDTA given the potential for disclosure.
  • English language requirement: Where a controller is the importer, there is an obligation on them to be able to easily communicate with data subjects in English and without undue delay, which is a potentially onerous expectation.
  • Commercial provisions: The IDTA incorporates a range of commercial positions and provisions which, given the precedence of the IDTA over a Linked Agreement, could have broader implications as, depending on the importance of the data transfer element to the agreement, commercially agreed positions may be frustrated by positions under the IDTA:
    • Liability: There is an uncapped liability regime in relation to a party’s breach of the IDTA causing damage to a data subject, with a fairly high bar for proving non-involvement in an incident causing damage.
    • Significant Harmful Impact: The IDTA introduces the concept of ‘Significant Harmful Impact’ whereby, if there is more than a minimal risk of a breach to the IDTA which may cause indirect or direct significant damage to a data subject or a party, this will be a trigger for various termination rights. This appears to be looking to align with the approach to data breaches, however the various rights to terminate resulting from this make this a material contractual consideration.
    • Third party rights: Data subjects have a range of provisions under the IDTA under which they can bring a claim against either the exporter or importer (as applicable) and the ICO also has more limited direct rights under the IDTA.
    • Boilerplate: Provisions regarding notice, assignment, sub-contracting, and severance (amongst others) have been included and this could cause issues, for example where a Linked Agreement permits unrestricted assignment, this would not be able to occur as the IDTA requires the consent of the other party.
  • Arbitration: The IDTA suggests that a specific IDTA arbitration scheme could be introduced as an optional dispute resolution mechanism for use in claims between the parties or involving the ICO or data subjects. A data transfer-specific arbitration scheme would be a novel mechanism in this context.

Risk Assessment Guidance and TRA

The ICO has produced the Risk Assessment Guidance in light of the decision in Schrems II in order to assist organisations with carrying out a TRA as part of putting in place an IDTA. It consists of guidance pertaining to general considerations for organisations conducting a TRA, as well as a detailed TRA tool.

Some of the key points emerging from this are:

  • Not an adequacy assessment: The Risk Assessment Guidance contains a disclaimer that a TRA should not amount to a mini-adequacy assessment, but rather a consideration of whether the destination jurisdiction “shares certain key principles which underpin [their] law and practice“, and should focus on two key aspects: (i) enforceability of the IDTA’s provisions; and (ii) third party access to data. If these aspects are sufficiently similar, then the IDTA’s provisions should provide sufficient protection within that jurisdiction.

The Risk Assessment Guidance further notes that the assessment should not involve a consideration of the whole country’s legal regime, but only the aspects which are relevant to the transfer. The extent to which this is practicable is perhaps questionable, particularly in light of the factors that the ICO suggests need to be considered, although the narrow focus of the assessment, which is supplemented by the detailed information in the ICO’s TRA tool, provides some comfort (see below).

  • Factors to consider: The ICO highlights a range of factors to consider in relation to: (i) the particular facts of the transfer (type of data, purpose, movement, etc.); (ii) the facts of the jurisdiction destination (human rights record, legal system, laws and practices regarding third party access); and (iii) the potential impact on data subjects and any risk of harm. The ICO notes that some jurisdictions should be obvious, for instance where there is rule of law or robust regulation of third party access to data (although there is no “shortcut” TRA approach for obvious jurisdictions), but there will likely be a range of liminal countries where a granular analysis will be technical and time consuming, even more so in complex multijurisdictional transfer scenarios.
  • Assessment and reassessment: The Risk Assessment Guidance (and the IDTA) make clear that ongoing review of a transfer arrangement will be required both where the context changes (such as due to a change in law, nature of the transfer evolves, or there are technical developments) and periodically. Indeed, given that the ICO will have both a regulatory and contractual mechanism for requesting TRAs, ensuring that there is an internal, operational mechanism to undertake the necessary TRAs, and ensure that they do not become historic, will be important.
  • The TRA tool: The ICO’s TRA tool is structured around a three part process (transfer assessment followed by consideration of an IDTA’s enforceability and the protection from third party access to data which are afforded in the importing jurisdiction) in order to ascertain whether and how, in routine transfer scenarios, any supplemental measures need to be incorporated into the IDTA:
    • Analysis support: Each stage of the TRA has been designed with decision trees and detailed guidance which will assist organisations with considering and developing their documented TRAs.

Of particular assistance are a range of tables which: detail the types of data and context within which a red, amber, green risk rating can be applied (e.g. basic contact details of consumers would likely be low risk/green); note considerations to inform whether enforceability and access are sufficiently similar to the UK; and highlight factors which may develop and adjust an organisation’s consideration of a risk level (e.g. an intra-group transfer lowering the risk, versus a large volume of data about an individual likely increasing the risk).

    • Supplementary measures: Following each step of the analysis, the Risk Assessment Guidance provides practical technical, organisational, and contractual steps which can be taken depending on the level of risk identified (e.g. a spectrum of encryption or more robust contractual complaint mechanisms).
    • Risk: Notably the tool highlights the importance of focusing on “risk” where an opinion on a jurisdiction is difficult to form. This approach, allied to the pragmatic risk mitigations given, provides practical and considered support which recognises the importance of maintaining data flows while providing sufficient protections, which organisations will likely find very helpful.
  • Complex scenarios: More complex transfer scenarios will require a more forensic analysis and the ICO highlights situations such as multijurisdictional arrangements, novel technology usage, and countries with a questionable human rights record that could produce a high risk and where relying on the tool will not be sufficient. That said, the range of user-friendly and focused guidance and considerations in the tool will no doubt assist organisations with undertaking a more complex analysis.


The ICO has produced an Addendum which is designed to be used in combination with the New EU SCCs in order to validate international transfers to a third country and provides for a range of non-controversial amendments to the New EU SCCs to adapt them to apply in a UK context.  The intention appears to be to provide an alternative to the IDTA route whereby a UK organisation could utilise the New EU SCCs in combination with the Addendum in order to validate a transfer from the UK (i.e. in a similar way to which the Old EU SCCs are currently used).

Should this route be taken instead of, or in addition to, that of the IDTA, for organisations with an EU and UK nexus it would simplify the contractual process (for both new contracts and any repapering exercise) in that a single, consistent approach could be taken (i.e. implement the New EU SCCs incorporating as necessary the Addendum). However if only the Addendum route was taken, then UK organisations would need to adopt the modular mechanism and become cognisant of the complexities regarding the New EU SCCs.

Indeed it is interesting to note that the ICO’s consultation document is seeking views on the adoption of the Addendum in the context of the New EU SCCs, but also whether there are any other model data transfer agreements for which such a path could be taken (calling out also New Zealand and the Association of Southeast Asian Nations’ model clauses). It may be then that the result of the consultation brings about various routes by which a transfer from the UK can be legitimised for UK organisations (perhaps based on the importing jurisdiction), which would be consistent with the UK’s stated business-friendly, flexible approach to international data flows.

Final Thoughts

The ICO has devised a detailed and well-considered approach to address international transfers of personal data out of the UK in a post-Brexit world which has clearly been designed to interface with EU and global data protection and privacy laws and practice. As such, early concerns raised in relation to the UK adopting a drastically different mechanism to that of the EU (with the potential to cause chaos for multi-national organisations transferring personal data in and out of both the UK and EU), have been somewhat quelled.

Certainly the TRA is a document which will likely provide great assistance to UK (and potentially EU-based) organisations as they grapple with the risk assessment requirement brought about by Schrems II. Indeed it is perhaps difficult to see what more the ICO could have done in this regard as the TRA is practical, solution-oriented, and user-friendly.

The IDTA does diverge from the approach taken by the EU in relation to the New EU SCCs, but the IDTA’s combination of tables, free text, and mandatory clauses is once again more business-focused and streamlined. The format enables parties to be flexible depending on their current and future arrangements and, by way of the Addendum, provide effective interoperability with the New EU SCCs. The mandatory clauses of the IDTA do, however, raise some questions, in particular those which have a distinctly English contract law flavour, and may result in some robust discussions with non-English counterparties.

It will be fascinating to see what responses the ICO will receive as part of the consultation and what ICO’s final approach (including in relation to timeframes for implementation) will be.

Miriam Everett
Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378
Duc Tran
Duc Tran
Of Counsel, Digital TMT, Sourcing and Data, London
+44 20 7466 2954
Claire Wiseman
Claire Wiseman
Professional Support Lawyer, London
+44 20 7466 2540
Alasdair McMaster
Alasdair McMaster
Associate, London
+44 20 7466 2194



On 28 May 2021, the Information Commissioner’s Office (“ICO“) published a call for views on the first draft chapter of its anonymisation, pseudonymisation and privacy enhancing technologies draft guidance). This first chapter is part of a series of chapters of guidance that the ICO will be publishing on anonymisation and pseudonymisation and their role in enabling safe and lawful data sharing. Addressed to organisations seeking to anonymise personal data, it seeks to define anonymisation and pseudonymisation and provides some practical advice to such organisations on how to manage their obligations.

The guidance supplements the ICO’s Data Sharing Code of Practice (the “Code“), which we discussed in our blog post here. The Code contained guidance on the aspects organisations need to consider while sharing personal data. While the Code briefly touched upon anonymisation and pseudonymisation, it did not address some of the key issues that arise time and again when organisations seek to anonymise and pseudonymise data. This new series of guidance, with its specific focus on anonymisation and pseudonymisation, will hopefully address these issues.

In this blog post, we discuss our key takeaways from the first chapter of the guidance and the impact that it is likely to have.

What is Anonymisation?

The first chapter of the guidance explains that anonymous information is data which does not relate to an identified or identifiable individual. Data protection law does not apply to truly anonymous information. According to the guidance, anonymisation is the way in which personal data is turned into anonymous information, and includes the techniques and approaches which can be used to this end.

The guidance also clarifies that it is not necessary that anonymisation be free of risks, and emphasises that the risk of re-identification should be mitigated to the extent that it becomes sufficiently remote and that information becomes ‘effectively anonymised’. In this respect, guidance states that anonymisation is ‘effective’ when: (a) it does not relate to an identified or identifiable individual; or (b) is rendered anonymous in such a way that individuals are not (or are no longer) identifiable.

Importantly, the guidance makes the important clarification that applying anonymisation techniques to render personal data anonymous is considered a processing activity in of itself, and data protection requirements have to be adhered to while undertaking such processing, which includes informing data subjects that this is to take place.

What is Pseudonymisation?

The first chapter of the guidance confirms that pseudonymisation is a method used to remove or replace information that identifies an individual, for example, by replacing names or other identifiers with codes or numbers. However, the guidance cautions that organisations must take care to maintain the additional information (i.e. the identifiers) separately and protect it using appropriate technical and organisational measures, as individuals can be identified by reference to this additional information.

Crucially, the guidance seeks to address one of the long-debated questions surrounding pseudonymised data – can pseudonymised data be considered anonymised data in the hands of a third party who has no means to re-identify that data?

In this respect, the guidance clarifies that when transferring the pseudonymous data to a third party, an organisation needs to consider the context and circumstances of the transfer – if the third party has no means which are reasonably likely to re-identify the individuals in the transferred dataset, the dataset may be considered ‘anonymous information’ in the hands of the third party. However, should the transferring organisation still have access to the additional information which can identify individuals, the dataset will continue to be personal data in that organisation’s hands. Whilst many organisations have been operating under the assumption that pseudonymised data can be considered anonymised data in the hands of a recipient without the means re-identify that data, this is a welcome and important clarification.

Accordingly, both disclosing and recipient organisations will need to carefully consider whether the data is anonymous or pseudonymous in their hands, to consider their data protection obligations.

The guidance also sets out that pseudonymous data is still personal data and data protection law applies to such data. However, it does not specify if there is any degree of difference in how data protection law will apply to conventional personal data and pseudonymous data. We expect that the ICO will address this issue in the remaining chapters of its anonymisation and pseudonymisation guidance. It remains to be seen what the obligations of a recipient third party will be in context of a pseudonymised dataset it receives, when it does not have the additional information which can re-identify individuals from that dataset.

The Way Forward

The ICO will be publishing further chapters of its anonymisation and psuedonymisation guidance on identifiability, pseudonymisation techniques, accountability and governance requirements, amongst other topics. These upcoming chapters will hopefully provide further guidance and clarity on the obligations of organisations while sharing pseudonymised data and best practice to be followed in order to ensure compliance with data protection requirements.

Duc Tran
Duc Tran
Of Counsel, Data Protection and Privacy, London
+44 20 7466 2954
Ananya Bajpai
Ananya Bajpai
Trainee Solicitor, London
+44 20 7466 2952


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 was then laid before the Parliament on 18 May 2021 and will come into force after 40 sitting days.
  • 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.


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 and is due to come into force as the end of June 2021, 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?


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, as well as deadlines for enforcement.

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

EDPB and ICO respond to the Brexit data transfer window

As most in the data community are aware, the EU-UK Trade and Cooperation Agreement (the “Brexit Deal”) was agreed on Christmas Eve and provides for an interim period (up to a maximum of six months ending on 30 June 2021) whereby data transfers from Europe to the UK will not be treated as transfers to a third country subject to Chapter V of the GDPR following the end of the transition period on 1 January 2021, provided the UK complies with certain conditions during the interim period (discussed in our blog here).

Following this, both the European Data Protection Board (“EDPB”) and the UK’s supervisory authority (the Information Commissioner’s Office (“ICO”)) have issued either updated or new responses which provide some more clarity on areas of focus and what to expect over the coming year.

The EDPB’s Response

Prior to the Brexit Deal being agreed, in mid-December the EDPB adopted its ‘Statement on the end of the Brexit transition period’ (here) (the “Statement”) and an ‘Information note on data transfers under the GDPR to the United Kingdom after the transition period’ (here) (the “Information Note”) which highlighted some key considerations of the EDPB.

Following the agreement and implementation of the Brexit Deal from the beginning of 2021, the EDPB has now updated the Statement and Information Note.

  • The interim data transfer window

In line with Article FINPROV.10A of the Brexit Deal, the update to the Statement and Information Note emphasises that data transfers to the UK can continue to take place without the requirement of a transfer tool under Article 46, or relying on the derogations list under Article 49, until 30 June 2021 (at the latest) provided that the UK’s current data protection regime stays in place.

  • Preparing for an adequacy decision (or lack of one)

The EDPB provides no further view on the adequacy of the UK’s data protection regime other than that the timeline for a favourable decision has now been pushed to the end of June. If a favourable adequacy decision is not taken by 30 June 2021, the EDPB emphasises in the Statement and Information Note that transfers between entities regulated by the GDPR to the UK will become subject to Chapter V of the GDPR. This will mean that transfers to the UK will require adequate safeguards such as standard data protection clauses, binding corporate rules, intra-group agreements, codes of conduct etc. to be put in place along with ensuring enforceable data subject rights and effective legal remedies for data subjects as required by Article 46.

The Information Note further reminds controllers and processors that, absent an adequacy decision, from the end of the interim period compliance with other GDPR obligations will come into sharper focus, including:

    • updating privacy notices and records of processing to account for data transfers to the UK;
    • taking caution if intending to rely on grounds under Article 49 in the absence of safeguards under Article 46, as such grounds are to be interpreted restrictively, only being fit for occasional and non-repetitive transfers; and
    • considering whether any supplementary tools may need to be put in place, a relatively complex and time-consuming consideration discussed further here (albeit the fact that the UK’s data law is the application of the GDPR then such consideration should theoretically be straightforward).
  • One-Stop-Shop mechanism

While not affected by the EDPB’s updates, it is worth noting that the Statement and Information Note also clarify the applicability of the One-Stop-Shop (“OSS”) mechanism envisioned by the GDPR within the UK.

The OSS mechanism provides that the supervisory authority in the jurisdiction of an entity’s main establishment will act as the lead supervisory authority and carry out compliance and regulatory functions on behalf of supervisory authorities in each EU jurisdiction in relation to that entity.

From 1 January 2021, the OSS will not apply in the UK so that the ICO will not be able to act as a lead supervisory authority (i.e. the Brexit Deal did not extend this mechanism). The EDPB notes that it has engaged with supervisory authorities and the ICO to ensure a smooth transition of existing cross-border cases.

The Statement and Information Note goes on to remind controllers and processors that they remain free to establish a main establishment in an EU jurisdiction under Article 4(16) to utilise the OSS mechanism (although the feasibility of this for many entities may well be impracticable). If this is not in place, entities will need to designate a representative under Article 27 as long as their activities are subject to the GDPR under Article 3(2).

The ICO’s Response

In a blog posted on 22nd January (here), the ICO’s Information Commission Elizabeth Denham responded to the Brexit Deal (the “ICO Response”) by welcoming the long-term commitments made by the EU and UK, most notably, to promoting high international standards of data protection, developing a regulatory relationship, and co-operating on enforcement activity.

The ICO Response considered the interim period allowing data transfers between Europe and the UK as the “best possible outcome for UK organisations” in light of the risks and impacts to digital trade if this had not been put in place. However, given this interim period will end in either four or six months under the Brexit Deal, the importance of a positive adequacy decision for UK data flows is clear in the ICO Response, emphasised by the reference to the EU’s commitment to considering the UK’s adequacy position “promptly” in a declaration accompanying the Brexit Deal. Although the ICO Response also sounds the warning that adequacy is not guaranteed and so organisations should be putting in place appropriate safeguards during this window.

Finally, as well as some specific commentary regarding data sharing in the context of law enforcement  and noting that the UK must also notify the EU-UK Partnership Council, as far as reasonably possible, of any new international transfers of personal data between public authorities for international transfers of personal data, the ICO Response also highlights that the process for any decisions in a range of areas (including UK adequacy decisions, approving international transfer mechanisms, or standard contractual clauses) must be put before the EU-UK Partnership Council. Given this requirement, it may be that material departure from the current UK data protection position is unlikely in the imminent future.

Miriam Everett
Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378
Claire Wiseman
Claire Wiseman
Professional Support Lawyer, London
+44 20 7466 2267
Alasdair McMaster
Alasdair McMaster
Associate, London
+44 20 7466 2194
Asmita Singhvi
Asmita Singhvi
Trainee, London
+44 20 7466 3697

ICO fines Marriott £18.4 million in relation to Starwood Hotel’s 2014 data breach


  • The ICO has fined Marriott Inc (“Marriott”) £18.4 million in relation to a 2014 cyber-attack on Starwood Hotels.
  • The ICO had previously issued a notice of its intention to fine Marriott £99.2 million. The Penalty Notice does not explain the reasons why the final fine is considerably lower than this amount.
  • Following the ICO’s consideration of three rounds of representations made by Marriott, Marriott has been fined for failing to process personal data in a manner that ensures appropriate security of the personal data.
  • The ICO has made clear that its decision relates solely to Marriott’s failures after 25 May 2018 (i.e. post-GDPR) despite the historic, pre-2018 nature of the cyber-attack.
  • The ICO identified four principal security failures which may be useful for organisations looking to understand the level of security measures that the regulator expects to be in place.
  • In its Penalty Notice, the ICO has unfortunately avoided giving any real guidance as to what it expects from the data protection and cyber security due diligence process in corporate transactions (such as the Marriott acquisition of the Starwood Group).
  • This decision follows the recent announcement of the ICO’s decision to fine British Airways a significantly reduced fine of £20 million (rather than its original proposed fine of £183 million).


As we detailed in our blog post back in July 2019 (https://hsfnotes.com/data/2019/07/10/marriott-starwood-data-breach-ico-intention-to-issue-another-big-99-million-mega-fine/), the guest reservation system of the Starwood group of hotels was compromised in 2014, exposing the personal data of approximately 339 million guest records globally, of which around 30 million related to residents of 31 countries (at the time) in the European Economic Area. Seven million of those related to UK residents. However, this data breach was not discovered until 2018, following the acquisition of the Starwood group by Marriott in 2016.

In July 2019, the Information Commissioner’s Office (“ICO”) issued a notice of intent to fine Marriott £99.2 million for this data breach. It was announced one day after the notice of the ICO’s intent to fine British Airways £183.39 million.

The ICO investigated this case as the lead supervisory authority on behalf of other EU Member State data protection authorities.

The ICO’s decision

The ICO has issued a monetary penalty notice (“Penalty Notice”) to Marriott, fining Marriott £18.4 million for failing to process personal data in a manner that ensures appropriate security of the personal data, as required by Article 5(1)(f) and Article 32 of the GDPR, representing a significant reduction of £80.8 million from the original figure of £99.2 million.

In a similar way to the British Airways penalty notice, the Penalty Notice does not explain the reasons why the final fine has been reduced by such a substantial amount, although it is to be noted that Marriott made three rounds of representations to the ICO, with the third round of representations being specifically in respect of the financial impact on its business caused by the Covid-19 pandemic.

It appears that Marriott’s representations led to the following:

  • the ICO clarifying certain factual findings made in its notice of intent in light of Marriott’s new submissions;
  • the removal of the provisional finding by the ICO of a breach by Marriott of Article 33 of the GDPR (notification of a personal data breach to the supervisory authority) proposed in the ICO’s notice of intent; and
  • no finding in the Penalty Notice in relation to a breach by Marriott of Article 34 of the GDPR (communication of a personal data breach to the data subject) despite a provisional finding of the same proposed in the ICO’s notice of intent.

According to the Penalty Notice, the ICO has taken into account the following factors in calculating the fine, in accordance with Article 83 of the GDPR and the ICO’s Regulatory Action Policy:

  • Financial Gain: Marriott did not gain any financial benefit or avoid any losses directly or indirectly as a result of the breach. The ICO, therefore, did not add an initial element at this stage.
  • Nature and Gravity: The ICO considered the nature of the failures to be of significant concern, affecting an extremely large number of individuals although the mitigating steps taken by Marriott were taken into account.
  • Duration: Although the cyber-attack spanned a four-year period, the Penalty Notice relates to infringements occurring between 25 May 2018 to 17 September 2018. Regardless of this, the ICO considered this to be a significant period of time over which unauthorised access to personal data went undetected and/or unremedied.
  • Culpability: The breach was a not an intentional or deliberate act on the part of Marriott. The ICO rather found Marriott to be negligent. In coming to this conclusion, the ICO took into account Marriott’s size and profile.
  • Responsibility: The ICO found Marriott to be wholly responsible for the breaches of Article 5(1)(f) and Article 32 of the GDPR.
  • Previous Actions: Marriott had no relevant previous infringements or failures to comply with past notices.
  • Cooperation: Marriott fully cooperated with the ICO’s investigation.
  • Categories of Personal Data: The affected data included unencrypted passport details, credit card data and various other categories of personal information.
  • Notification: Marriott is considered to have complied with its notification obligations.

Taking into account the factors above, the ICO considered that a penalty of £28 million (before any adjustments) would be an appropriate starting point to reflect the seriousness of the breach, and the need for the penalty to be effective, proportionate and dissuasive in the context of Marriott’s scale and turnover. There is nothing in the Penalty Notice which indicates how the ICO reached the amount of £99.2 million in its original notice of intent.

The ICO did not consider there to be any aggravating factors to apply in order to increase the penalty and further did not consider it necessary to increase the penalty in order for it to be ‘dissuasive’.

Turning to any potential downwards adjustment, the ICO considered a 20% downwards adjustment (£5.6 million) to be appropriate, taking into account various mitigating factors, including:

  • Marriott’s continual and increasing investment in security;
  • the immediate steps to (i) mitigate and minimise the effects of the cyber-attack and (ii) protect the interests of data subjects through the implementation of remedial measures;
  • Marriott’s full cooperation with the ICO’s investigation including its prompt responses to requests for information;
  • the broad press coverage as a result of the cyber-attack will have likely raised awareness with other controllers of potential risks; and
  • the adverse effect on Marriott’s brand and reputation.

Finally, having regard to the impact of the Covid-19 pandemic on Marriott, the ICO applied a further reduction of £4 million to the fine, taking it to a final amount of £18.4 million. It should be noted that although the ICO acknowledged the significant impact of the Covid-19 pandemic on Marriott’s revenues, it did not consider that the imposition of a penalty in the range being proposed would cause financial hardship to Marriott, or that Marriott would be unable to pay such a penalty.

Details of the GDPR infringements

The ICO concluded that, between 25 May 2018 and 17 September 2018, Marriott failed to comply with its obligations under Article 5(1)(f) of the GDPR – the integrity and confidentiality principle – and Article 32 of the GDPR – security of processing. According to the ICO, Marriott failed to process personal data in a manner that ensured appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical and organisational measures. The ICO identified four principal security failures:

  • Insufficient monitoring of privileged accounts that would have detected the breach

The ICO was concerned that Marriott did not have appropriate and adequate measures in place to allow for the identification of the breach and to prevent further unauthorised activity, particularly once the attacker had found its way into the cardholder data environment (CDE). This included a failure to have ongoing monitoring of user activity, particularly activity by privileged accounts.

  • Insufficient monitoring of databases

Marriott was found to have failed to adequately monitor the databases within the cardholder data environment. The ICO was concerned with three failures in particular: (a) deficiencies in Marriott’s setup of security alerts on databases in the cardholder data environment; (b) the failure to aggregate logs; and (c) the failure to log actions taken on the cardholder data environment systems, such as the creation of files and the exporting of entire database tables. Whilst Marriott did have a system in place to log activity and issue alerts, the ICO deemed this to be unsatisfactory given that Marriott did not ensure the logging of key activities taking place on the databases. Marriott also did not engage in server logging of the creation of files which allowed the attacker to export entire databases undetected. In addition, alerts were only placed on tables that contained payment card information or specific queries and the actions of the attacker did not meet the conditions for the triggering of an alert. While Marriott had a security incident event management system (SIEM) and a security operations centre (SOC) these were rendered ineffective by the lack of monitoring at source.

  • Control of critical systems (failure to implement server hardening as a preventative measure)

The ICO stated that it would have been appropriate for Marriott to implement a form of server hardening as a preventative measure, which could have prevented the attacker from gaining access to administrator accounts and preventing them from traversing across the network. In particular, the ICO considered that whitelisting (for example, in relation to IP addresses or permitted software) should have been deployed where appropriate on critical systems and systems which have access to large amounts of personal data.

  • Encryption

Whilst some information was encrypted by Marriott (for example where required for PCI-DSS compliance), encryption was not applied to other categories of non-payment related personal data. The ICO were particularly concerned that not all passport numbers were encrypted. The ICO did not accept Marriott’s suggestion that it would be impractical to implement more encryption than it had. In particular, the ICO suggested that encrypted personal data could have been accessed and decrypted in almost real-time by using unique identifiers to cross reference to the encrypted content.

It is interesting that both Marriott and British Airways submitted, due to similar reasons, that the ICO had applied the wrong fining tier (i.e. 4% for a contravention of Article 5(1)(f) as opposed to 2% under Article 32) although the ICO rejected these submissions and provided near identical reasoning for its rejection, which we have set out in our blog post analysing the British Airways fine (https://hsfnotes.com/data/2020/10/21/the-not-so-mega-mega-fine-ico-fines-british-airways-20-million-for-its-2018-data-breach/).

A note on due diligence

As widely noted, this case has highlighted the importance of data and cyber security due diligence in corporate transactions. The ICO has now shed some further light on what it expects from corporate transactions and the due diligence process, although not necessarily in a way in which we might have expected.

During its representations, Marriott raised that it was only able to carry out limited due diligence on Starwood’s data processing systems and databases as part of the acquisition process. Marriott also submitted that it is “not tenable to proceed on the basis that acquisition due diligence is a “seemingly endless” process”. Interestingly, the ICO acknowledges this in the Penalty Notice, particularly that there may be circumstances in which in-depth due diligence of a competitor is not possible during a takeover. However, it ultimately avoids the need to address this since it was not making any finding of infringement in respect of the period between Marriott’s acquisition of Starwood and the entry into force of the GDPR in May 2018. Instead, the Penalty Notice concerns the extent to which Marriott adequately managed the Starwood systems to protect personal data after the GDPR came into effect.

In any event, organisations should be aware that it is not possible to point to the limited due diligence process available to acquirers in a corporate transaction as an explanation for missing any hidden data vulnerabilities or breaches pre-acquisition. Instead, the ICO confirms that the “need for a controller to conduct due diligence in respect of its data operations is not time-limited or a ‘one-off’ requirement” and, given this ongoing duty, it is “no answer to claim that certain due diligence steps were, or only needed to be, taken in the period immediately after acquisition”. Significantly, the ICO is of the opinion that even if adequate due diligence had been undertaken at the point of acquisition, that would not have removed Marriott’s obligation to ensure, on a continuing basis, that it complied with the GDPR (once it came into force).

While actually performing low level technical due diligence on systems as part of an acquisition (i.e. of the sort that might detect such intrusions) is likely to be challenging for the above reasons, there are plenty of things that prospective purchasers can do to manage their risk. Due diligence questionnaires afford the opportunity to ask questions about the compliance, IT, security and other systems and controls that the target company has in place, and to tie warranties to those questions. Secure infrastructure would ordinarily be accompanied by a suite of design documentation, policies, security personnel, audit reports and the like, that evidence security best practices being in place. Where asking the right questions during due diligence, and following the chain of enquiry that results, exposes issues, often provision can be made for part of the purchase price to be held in escrow pending resolution.

What is next

Although significantly below the level set out in its notice of intent, this fine, along with the £20 million fine on British Airways, indicates that the ICO is taking GDPR penalties seriously and may be sign of things to come (probably at the 8 figure, rather than the 9 figure, range).

Marriott has stated that it does not intend to appeal the ICO’s decision, but makes no admission of liability in relation to the decision or the underlying allegations.

Miriam Everett
Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378
Andrew Moir
Andrew Moir
+44 20 7466 2773
Angela Chow
Angela Chow
Associate, Digital TMT, Sourcing and Data, London
+44 20 7466 2853
Elena Hogg
Elena Hogg
Associate, London
+44 20 7466 2590

The not so mega ‘mega fine’: ICO fines British Airways £20 million for its 2018 data breach

  • The ICO has fined British Airways £20 million for breach of the GDPR in relation to its 2018 data breach.
  • This is a significant reduction in the original proposed fine of £183 million.
  • In the monetary penalty notice issued to British Airways, the ICO has confirmed that the reduction of almost 90% was only partially influenced by the effects of COVID-19 on the financial position of British Airways.
  • In contrast, the vast majority of the reduction appears to come as a result of the ICO having taken into account BA’s representations following its notice of intent, combined with a change of approach by the ICO which meant less of a focus on turnover as the driving factor in calculating fines.
  • The ICO has also published details of the specific GDPR infringements committed by British Airways which have been limited to breach of the integrity and confidentiality principle in Article 5 and the security obligations in Article 32 GDPR.
  • The moral of the story appears to be that it can be commercially worthwhile for controllers to push back robustly against any notice of intent.


As we reported here, in July 2019 the Information Commissioner’s Office (“ICO”) published a notice of its intent to fine British Airways a staggering £183 million for infringement of the General Data Protection Regulation (GDPR) as a result of its 2018 data breach where the personal data of around 500,000 British Airways customers was stolen by hackers.

Importantly, this was a notice of intent and not a final concluded fine. The Data Protection Act 2018 sets a strict deadline of six months for the ICO to convert this into a fine, although this period may be extended if the ICO and the proposed recipient of the fine agree to an extension. Multiple times the ICO and British Airways took advantage of this extension mechanism so that the final Penalty Notice was only published on 16 October 2020, more than a year after the initial notice of intent.

At the time, no reasons for any of the extensions were offered by either side, although it was understood from International Airline Group’s (IAG, British Airway’s parent company) Annual Report and Accounts 2019, and has now been confirmed by the final Penalty Notice, that British Airways made extensive representations to the ICO regarding the proposed fine and that there were multiple further information requests. The impact of COVID-19 also likely had its part to play in the extension.

At the time of the initial notice of intent, the proposed British Airways fine was touted as the first ‘mega fine’ to be issued by a European data regulator since the implementation of the GDPR. The biggest data protection fine previously issued by the ICO was £500,000, the maximum possible under the old legislation.

The first GDPR ‘mega’ fine: not so ‘mega’: a reduction of almost 90%

The ICO finally issued its Penalty Notice to British Airways on 16 October 2020, fining British Airways £20 million. While still the largest ICO fine to date, this is a significant reduction of almost 90% from the original figure of £183.39 million.

Although the Penalty Notice refers in a couple of places to the original intended fine of £183.39 million, very little is said in the notice regarding why exactly, the final fine has been reduced by such a significant amount. Instead, the notice effectively appears to start from scratch in calculating the final level of fine, taking into account the following factors in accordance with Article 83 GDPR and the ICO’s Regulatory Action Policy:

  • Financial Gain: BA did not gain any financial benefit or avoid any losses directly or indirectly as a result of the breach.
  • Nature and Gravity: The ICO considered the nature of the failures to be serious, affecting a significant number of individuals for a significant period of time (103 days).
  • Culpability: Although the breach was a not an intentional or deliberate act on the part of BA, the ICO found BA to be negligent.
  • Responsibility: The ICO found BA to be wholly responsible for the breaches of Articles 5 and 32 GDPR.
  • Previous Actions: BA had no relevant previous infringements or failures to comply with past notices.
  • Cooperation: BA fully cooperated with the ICO’s investigation.
  • Categories of Personal Data: Although no special category data was affected, the nature of the data, in particular payment card data, was nonetheless sensitive.
  • Notification: BA acted promptly in notifying the ICO of the attack.

Taking into account all of these factors above, the ICO considered that a penalty of £30 million would be appropriate starting point to reflect the seriousness of the breach, and the need for the penalty to be effective, proportionate and dissuasive in the context of BA’s scale and turnover. So far, there is no obvious reason why the fine is so much lower than the notice of intent.

The ICO did not consider there to be any aggravating factors to apply in order to increase the penalty and further did not consider it necessary to increase the penalty in order for it to be ‘dissuasive’.

Turning to any potential downwards adjustment, the ICO considered a 20% downwards adjustment (£6 million) to be appropriate, taking into account various mitigating factors, including:

  • The immediate steps to mitigate and minimise any damage to data subjects;
  • BA’s prompt notification of the breach to data subjects and relevant regulatory authorities;
  • The broad press coverage as a result of the attached will have likely raised awareness with other controllers of potential risks; and
  • The adverse effect on BA’s brand and reputation.

Finally, the ICO also explicitly acknowledged that the impact of COVID-19 on British Airways was taken into account when determining the level of the final fine, although this only accounted for a further £4 million downwards adjustment and does not therefore account for the vast majority of the reduction.

Details of the GDPR infringements

In its final Penalty Notice, the ICO focussed on BA’s breach of Article 5(1)(f) GDPR – the integrity and confidentiality principle – and Article 32 GDPR – security of processing. The previous notice of intent, had also found BA to be in breach of Article 25 GDPR – data protection by design and by default – but this was dropped in the final Penalty Notice.

From a penalty perspective, it is also interesting that the ICO rejected BA’s claims that the maximum fine should be 2% because of the conflict between breach of Article 5 (attracting a maximum 4% fine) and breach of Article 32 (attracting a maximum 2% fine) meaning that the principal of lex specialis should apply with the specific provision of Article 32 overriding the general provision of Article 5. The ICO instead found that the two provisions were distinct even if they did overlap, although it is fair to note that it made no difference in the context of the level of fine imposed in the end (which was significantly less than both 4% and 2% of annual worldwide turnover).

With respect to its security obligations, the ICO found that British Airways had “weaknesses in its security” that could have been prevented with security systems, procedures and software that were available at the time. None of the measures would have entailed excessive cost or technical barriers for British Airways, with some available through the Microsoft Operating System used by British Airways. Some of the numerous measures British Airways could have used to mitigate or prevent the risk of the attack include:

  • limiting access to applications, data and tools to only that which are required to fulfil a user’s role;
  • undertaking rigorous testing, in the form of simulating a cyber-attack, on the business’ systems; and
  • protecting employee and third party accounts with multi-factor authentication, external public IP address whitelisting, and IPSec VPN.

The attack path that the hackers used in the ICO’s view exposed a number of failings on the part of British Airways. The hackers were able to gain access to an internal British Airways application through the use of compromised credentials for a Citrix remote access gateway. The hackers were then able to break out of the Citrix environment and could then gain broader access to the wider British Airways network. Once there, the attacker was able to move laterally across the network, culminating in the editing of a Javascript file on British Airway’s website. This allowed the attacker to intercept and exfiltrate cardholder data from British Airway’s website to an external third-party domain which was controlled by the attacker.

One particular area of focus for the ICO was British Airway’s practice of storing credentials within batch scripts. The ICO did not accept British Airway’s submissions that this “aided functionality” or was “standard practice” and stuck to its position that this was not acceptable and there were other secure ways to achieve the same objectives.

As a result, the ICO was “satisfied that BA failed to put in place appropriate technical or organisational measures to protect the personal data being processed on its systems, as required by the GDPR“.

What is next?

British Airways must pay the fine to the ICO or exercise its right to appeal to the First-tier Tribunal in the General Regulatory Chamber within 28 days of the Penalty Notice. Interestingly, the Penalty Notice does not refer to the availability of any further discount for prompt payment, with such discount usually being lost if the fine is appealed. This may normally suggest that BA has agreed to settle with the ICO, although the Penalty Notice is clear that BA does not admit liability for breach of the GDPR.

There is also the potential that British Airways could face a fine or reprimand under the Payment Card Industry Data Security Standard (PCI-DSS) in relation to its collection and processing of payment card data. PCI-DSS compliance is required by all organisations which accept, process, store and/or transmit debit and credit cards. However, fines under PCI-DSS are not publicly available so it is unlikely it will be public knowledge if a PCI-DSS fine is levied against British Airways.

In conclusion, this is perhaps not the first ‘mega fine’ or tough GDPR enforcement from the ICO that commentators were expecting, but it is still a step in that direction and with some interesting guidance regarding the way in which the ICO may approach the calculation of fines (and enforcement more generally) in the future.

Miriam Everett
Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378
Andrew Moir
Andrew Moir
+44 20 7466 2773
Chloe Kite
Chloe Kite
Associate, Digital TMT, Sourcing and Data, London
+44 20 7466 2540
Elena Hogg
Elena Hogg
Associate, London
+44 20 7466 2590


The Information Commissioner’s Office in the UK (the “ICO”) has published for consultation its draft statutory guidance setting out how it will regulate and enforce data protection legislation in the UK.

The document explains all of the ICO’s key powers (including information notices, assessment notices, enforcement notices and penalty notices). Perhaps most interestingly for organisations, it also sets out for the first time, the ICO’s approach to how it calculates fines under the GDPR, giving organisations a better sense of the level of fine to which they could be subject for GDPR non-compliance.

However, although the ICO has provided a table setting out it’s ‘starting point’ for the calculation of fines, there is nonetheless a large amount of discretion that the regulator can apply to adjust the fine both upwards and downwards, meaning that the process is not as transparent as it may at first seem.

Although the fine calculator is only in draft form at this stage, it is the first time that the process adopted by the ICO has been made public. Responses to the consultation are required by 5pm on Thursday 12 November 2020.

GDPR fine calculator

The ICO’s draft guidance sets out nine steps which will factor into the calculation of a fine for non-compliance with the GDPR, including seriousness, culpability, aggravating and mitigating factors, economic impact and dissuasiveness.

These steps will be applied to all GDPR fines, regardless of whether the so-called ‘standard maximum amount’ or ‘higher maximum amount’ applies. As per the GDPR, the higher maximum amount is €20 million or 4% of annual worldwide turnover (whichever is greater). The standard maximum amount is €10 million or 2% of annual worldwide turnover (whichever is greater).

The following three steps will be considered initially in order to enable the ICO to identify its ‘starting point’:


The factors to consider when assessing the seriousness of any infringement reflect those set out in the GDPR, including the nature, gravity, and duration of the failure; any action taken by the data controller or processor to mitigate the damage suffered by data subjects; the degree of cooperation with the ICO; and the way the breach became known to the ICO, including whether the data controller or processor notified the ICO of the failure.


When assessing culpability, the ICO will take into account the intentional or negligent character of the failure; specifically whether the organisation was intentional or negligent about its responsibility for the breach.


The ICO will review relevant accounts and obtain expert financial, or accountancy advice if required, to determine the amount of turnover (or equivalent for non-profit organisations such as the annual revenue budget and the financial means of individuals).

In circumstances where turnover or equivalent is minimal, the ICO will give greater weight to other factors such as dissuasiveness, particularly where there is a serious breach. Where there is a lack of cooperation in providing all relevant financial information, the panel will rely on the information available or otherwise give greater weight to factors such as aggravating features.

Starting point

Once the factors above have been assessed, the helpful table below sets out the ‘starting point’ for the fine, stated as a percentage of annual worldwide turnover, against which various other factors will be applied:

Once the appropriate starting point has been identified, the ICO will then apply the following other factors in order to adjust the starting point and reach the final level of the fine:

Aggravating and mitigating factors

The ICO will consider any aggravating and mitigating factors applicable to the circumstances of the case, such as financial benefits gained, or losses avoided, directly or indirectly, from the breach.

When determining the amount of any proposed administrative fine, the ICO will then adjust the starting point figure for each band accordingly, upwards or downwards, to reflect its assessment of applicable aggravating or mitigating circumstances. It will clearly record which aggravating and mitigating features it has taken into account and why and how it considers that these influence the proposed administrative penalty.

Financial means

The ICO will consider the likelihood of the organisation or individual being able to pay the proposed penalty and whether it may cause undue financial hardship.

Economic impact

The ICO will, where appropriate, consider any economic impact on the wider sector, or related regulatory impact of the proposed penalty beyond the organisation or individuals it is serving the penalty on.

Effectiveness, proportionality and dissuasiveness

The ICO will ensure that the amount of the fine proposed is effective, proportionate, and dissuasive and will adjust it accordingly.

Early payment discount

The ICO will reduce the monetary penalty by 20%, if it receives full payment of the monetary penalty within 28 calendar days of sending its final penalty notice. However, this early payment discount is not available if the controller decides to exercise its right of appeal to the First-tier Tribunal.

Miriam Everett
Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378


On 17 April 2020, the ICO published an opinion by the Information Commissioner (the “Commissioner”) on Apple and Google’s joint initiative to develop COVID-19 contact tracing technology (the “Opinion”, available here).


  • The Commissioner found the CTF to be aligned with principles of data protection by design and by default.
  • Controllers designing contact tracing apps that use the CTF should ensure alignment with data protection law and regulation, especially if they process personal data (which the CTF does not require).
  • The Commissioner raised concerns regarding individuals assuming that the CTF’s compliance with data protection principles will extend to all aspects of the contact tracing app – which is not necessarily the case.
  • Therefore, it should be made clear to any app users who is responsible for data processing, especially if the app processes data outside of the CTF’s limited scope.
  • Data controllers designing CTF-enabled contact tracing apps must be transparent with potential and actual app users on the type of information they will be processing.
  • Finally, when it comes to a user’s ability to disable Bluetooth, the Commissioner observed that with regard to contact tracing apps in general: “a user should not have to take action to prevent tracking”.

As set out in our previous blogpost (available here), contact tracing is one of the measures being contemplated or implemented by European governments (including in the UK and Germany) in order to be able to put an end to lockdowns while containing the spread of the virus.

The scope of the Opinion was limited to the design of the contact tracing framework which enables the development of COVID-19 contact tracing apps by public health authorities through the use of Bluetooth technology (the “CTF”).

It is also worth noting that this Opinion has been published in the midst of a heated debate on contact tracing technology and fears that it may be used for mass surveillance – in an open letter published on 20 April 2020, around 300 international academics cautioned against creating a tool which will enable large scale data collection on populations.

How does the CTF work?

The CTF is composed of “application programming interfaces“ as well as “operating system level technology to assist contact tracing”. The collaboration between Apple and Google will result in interoperability between Android and iOS devices of apps developed by public health authorities using the CTF.

When two devices with contact tracing apps come into proximity, each device will exchange cryptographic tokens (which change frequently) via Bluetooth technology. Each token received will be stored in a ‘catalogue’ on the user’s device, effectively creating a record of all other devices a user has come into contact with. Once a user is diagnosed with COVID-19, and after they have given their consent, the app will upload the stored ‘catalogue’ of tokens to a server. Other users’ devices will periodically download a list of broadcast tokens of users who have tested positive to COVID-19. If a match is found between the broadcast tokens and the ‘catalogue’ of tokens stored on each user’s device, the app will notify the user that he/she has come into contact with a person who has tested positive and will suggest appropriate measures to be taken.

How does the CTF comply with data protection laws?

The Opinion finds that, based on the information released by Google and Apple on 10 April 2020, the CTF is compliant with principles of data protection by design and by default because:

  1. The data collected by the CTF is minimal: The information contained in the tokens exchanged does not include any personal data (such as account information or usernames) or any location data. Furthermore the ‘matching process’ between tokens of users who have tested positive for COVID-19 and tokens stored on each user’s phone happens on the device and therefore does not involve the app developer or any third party.
  2. The CTF incorporates sufficient security measures: The cryptographic nature of the token which is generated on the device (outside the control of the contact tracing app) means that the information broadcast to other nearby devices cannot be related to an identifiable individual. In addition, the fact that the tokens generated by one device are frequently changed (to avoid ultimate tracing back to individual users) minimises the risk of identifying a user from an interaction between two devices.
  3. The user maintains sufficient control over contact tracing apps which use the CTF: Users will voluntarily download and install the contact tracing app on their phone (although this may change in ‘Phase 2’ of the CTF as discussed below). Users also have the ability to remove and disable the app. In addition, the process of uploading the collected tokens of a user to the app once he/she has tested positive by the developer requires a separate consent process.
  4. The CTF’s purpose is limited: Although the CTF is built for the limited purpose of notifying users who came into contact with patients who have tested positive for COVID-19, the Commissioner stresses that any expansion of the use of CTF-enabled apps beyond this limited purpose will require an assessment of compliance with data protection principles.

What clarifications are required?

The Commissioner raises a number of questions on the practical functioning of the CTF, especially in respect of collection and withdrawal of user consent post-diagnosis. It is unclear how the CTF will facilitate the uploading of stored tokens to the app. Although consent will be required from the user, clarity is needed on: (i) management of the consent signal by a CTF-enabled app and (ii) what control will be given to users in this respect. In addition, the Commissioner lacks information on how consent withdrawal will impact the effectiveness of the contact tracing solutions and the notifications sent to other users once an individual has been diagnosed.

Issues for developers

The Commission will pay close attention to the implementation of the CTF in contact tracing apps. In particular, the CTF does not prevent app developers from collecting other types of data such as location. Although reasons for collecting other types of user information may be “legitimate and permissible” in order to pursue the public health objective of these apps (for example to ensure the system is not flooded with false diagnoses or to assess compliance with isolation), the Commissioner warns that data protection considerations will need to be assessed by the controller – this includes the public health organisations which develop (or commission the development of) contact tracing apps.

Another issue raised by the Commissioner is the potential user assumption that the compliance by the CTF with data protection laws will radiate to all other functionalities which may be built into contact tracing apps. In this regard, the Commissioner reminds app developers that, in addition to assessing data protection compliance in relation to other categories of data processed by the app, they will need to clearly specify to users who is responsible for data processing – in order to comply with transparency and accountability principles.

Finally, the Commissioner stressed that data controllers, such as app developers, must assess the data protection implications of both (i) the data being processed through the app and (ii) data undertaken by way of the CTF in order to ensure that both layers of processing are fair and lawful.

What has the ICO said about ‘Phase 2’ of the CTF?

‘Phase 2’ of development of the CTF aims to integrate the CTF in the operating system of each device. The Commissioner notes that users’ control, their ability to disable contact tracing or to withdraw their consent to contact tracing should be considered when developing the next phase of the CTF.

With regard to user’s ability to disable Bluetooth on their device, the Commissioner observes in respect of ‘Phase 2’ of the CTF, and contact tracing apps in general, that “a user should not have to take action to prevent tracking”.

How does this Opinion affect the development of Decentralized Privacy-Preserving Proximity Tracing protocol?

The Opinion can be applied to Decentralized Privacy-Preserving Proximity Tracing (or DP-3T) protocol in so far as it is similar to the CTF. The Commissioner states that the similarities between the two projects gives her comfort that “these approaches to contact tracing app solutions are generally aligned with the principles of data protection by design and by default”.


This Opinion is an important step in the development and roll out of contact tracing apps in the UK. As mentioned above, contact tracing is one of the tools necessary for the UK Government to lift the lockdown measures while minimising the impact of a potential second wave of infections. This has an indirect impact on the private sector as it will affect how and when employees will be able to go back to work.

The fact that the principles on which the CTF is based are compliant with data protection laws is crucial to the successful roll out of contact tracing apps. In order for these apps to be effective, they must be voluntarily downloaded by a large number of mobile users. Given the concerns around letting governments accumulate data on the population under the guise of putting an end to the pandemic, trust is a determining factor in this equation. The fact that the Commissioner is approving the foundation for these contact tracing apps will certainly play a role in gaining the public’s trust and its acceptance to give up some privacy rights in order to put an end to the current public health crisis.

Miriam Everett
Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378
Hannah Brown
Hannah Brown
Associate, Digital TMT, Sourcing and Data, London
+44 20 7466 2677
Ghislaine Nobileau
Ghislaine Nobileau
Trainee Solicitor, London
+44 20 7466 7503

COVID-19: ICO publishes details of its regulatory approach during COVID-19 (UK)

The ICO has published details of its regulatory approach during the ongoing COVID-19 emergency; this is an approach which should reassure entities who are adapting to the economic and practical realities of operating in the current climate, as well as balancing their data protection obligations.  The UK regulator has continued to be reasonable and pragmatic, as outlined in our previous post in relation to response times to DSARs, and has stated that they are “committed to an empathetic…approach”.  Overall, the key takeaways from this guidance are that: Continue reading


Given the COVID-19 crisis, it is likely that data protection may no longer at the forefront of every controller’s mind, and rather, that business continuity has taken precedence. Acknowledging this shift and the need for companies to divert business as usual resources to their response to the crisis, the ICO has published two articles on its website, which are aimed at both controllers and data subjects more widely. Continue reading