Legitimate Interests

Legitimate Interests – Lawful Processing of Personal Data

When processing personal data legally, organisations have six possible reasons or ‘bases’ to rely upon: consent, contract, legal obligation, vital interest, public task or legitimate interests. Most of these are unambiguous. Fulfilling a contract or protecting someone’s life for example. On the surface, ‘legitimate interests’ appears more open to interpretation. What will be considered legitimate? And whose interests will be taken into account? When all else fails, organisations often mistakenly look to legitimate interests as a base for processing that furthers their business interest. Seeing legitimate interests as a fall-back is misguided. In many respects it is just as stringent as any of the other possible bases.

Legitimate Interests - Legislation

The UK GDPR describes legitimate interests as “processing necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child”.

Legitimate interests is different to the other lawful bases as it is not centred around a particular purpose (e.g. performing a contract with the individual, complying with a legal obligation, protecting vital interest or carrying out a public task), and it is not processing that the individual has specifically agreed to (consent). Legitimate interests is more flexible and could in principle apply to any type of processing for any reasonable purpose.

Because it could apply in a wide range of circumstances, it puts the onus on you to balance your legitimate interests and the necessity of processing the personal data against the interests, rights and freedoms of the individual taking into account the particular circumstances. This is different to the other lawful bases which presume that your interests and those of the individual are balanced.

Three-part test

The ICO (UK data protection regulatory authority) interprets the legislation with a three-part test. The wording creates three distinct obligations:

  1. “Processing is necessary for…” – the necessity teste. is the processing necessary for the purpose?
  2. “… the purposes of the legitimate interests pursued by the controller or by a third party, …” – the purpose teste. is there a legitimate interest behind the processing?
  3. “… except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.” – the balancing teste. are the legitimate interests overridden by the individual’s interests, rights or freedoms?

Purpose test – what counts as a ‘legitimate interests’?

A wide range of interests may be legitimate interests. It could be your legitimate interests in the processing or it could include the legitimate interests of any third party. The term ‘third party’ doesn’t just refer to other organisations, it could also be a third party individual. The legitimate interests of the public in general may also play a part when deciding whether the legitimate interests in the processing override the individual’s interests and rights. If the processing has a wider public interest for society at large, then this may add weight to your interests when balancing these against those of the individual.

Examples

The UK GDPR does not have an exhaustive list of what purposes are likely to constitute legitimate interests. However, the recitals do say the following purposes constitute legitimate interests: fraud prevention; ensuring network and information security; or indicating possible criminal acts or threats to public security.

Therefore, if you are processing for one of these purposes you may have less work to do to show that the legitimate interests basis applies. The recitals also say that the following activities may indicate a legitimate interest: processing employee or client data; direct marketing; or administrative transfers within a group of companies.

However, whilst these last three activities may indicate legitimate interests, you still need to do some work to identify your precise purpose and show that it is legitimate in the specific circumstances, and in particular that any direct marketing complies with e-privacy rules on consent.

The necessity test

You need to demonstrate that the processing is necessary for the purposes of the legitimate interests you have identified. This doesn’t mean that it has to be absolutely essential, but it must be a targeted and proportionate way of achieving your purpose. You need to decide on the facts of each case whether the processing is proportionate and adequately targeted to meet its objectives, and whether there is any less intrusive alternative, i.e. can you achieve your purpose by some other reasonable means without processing the data in this way? If you could achieve your purpose in a less invasive way, then the more invasive way is not necessary.

The balancing test

Just because you have determined that your processing is necessary for your legitimate interests does not mean that you are automatically able to rely on this basis for processing. You must also perform a ‘balancing test’ to justify any impact on individuals. The balancing test is where you take into account “the interests or fundamental rights and freedoms of the data subject which require the protection of personal data” and check they don’t override your interests. In essence, this is a light-touch risk assessment to check that any risks to individuals’ interests are proportionate. If the data belongs to children then you need to be particularly careful to ensure their interests and rights are protected.

Reasonable expectations

Recital 47 of the UK GDPR says “the existence of a legitimate interest would need careful assessment including whether a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place. The interests and fundamental rights of the data subject could in particular override the interest of the data controller where personal data are processed in circumstances where data subjects do not reasonably expect further processing.”

The UK GDPR is clear that the interests of the individual could in particular override your legitimate interests if you intend to process personal data in ways the individual does not reasonably expect. This is because if processing is unexpected, individuals lose control over the use of their data, and may not be in an informed position to exercise their rights. There is a clear link here to your transparency obligations.

You need to assess whether the individual can reasonably expect the processing, taking into account particularly when and how the data was collected. This is an objective test. The question is not whether a particular individual actually expected the processing, but whether a reasonable person should expect the processing in the circumstances.

How do you apply legitimate interests in practice?

The ICO guidance states that organisations should undertake the three-part test and document the outcome, this process is referred to as a "legitimate interests assessment" (LIA). The length of a LIA will vary depending on the context and circumstances surrounding the processing. LIAs are intended to be a simple form of risk assessment, in contrast to a data protection impact assessment (DPIA) which is a "much more in-depth end-to-end process". A LIA is also a potential trigger for a DPIA. The ICO confirms that there is no specific duty in the UK GDPR to undertake a LIA, however, as a matter of best practice, one should be undertaken by organisations in order to meet their obligations under the UK GDPR accountability principle.

Once a LIA has been undertaken and an organisation has concluded that the legitimate interests basis for processing applies, then it should continue to keep the LIA under regular review. Where a LIA identifies high risks to the rights and freedoms of the individual, then a DPIA should be undertaken to assess these risks in more detail.

What else is there to consider?

The ICO also recommends that:

  • Individuals are informed of the purpose for processing, that legitimate interest is the basis being relied on and what that legitimate interest is. Organisations' privacy notices should also be updated to reflect this.
  • Where an organisation's purposes change or where it has a new purpose, it may still be able to continue processing for that new purpose on the basis of legitimate interests as long as the new purpose is compatible with the original purpose. A compatibility assessment should be undertaken in this case.
  • Organisations should be aware of individuals’ rights, for example, where legitimate interests is relied on as a basis for processing then the right to data portability does not apply to any personal data being processed on that basis.

Here to help

The concept of ‘legitimate interests’ as a basis for processing personal data predates GDPR. Many organisations are consequently aware of the concept. It should not, however, be taken for granted when organisations wish to further a business interest. As shown above, there are a number of obligations to consider, and therefore the basis should not be considered lightly or as a last resort.

If you have any questions on legitimate interests, data protection law more generally or on any of the issues raised in this article please get in touch with one of our data protection lawyers.


software as a service

Software as a Service (SaaS) - Some Key Aspects

Software as a Service (SaaS), instead of on-premises software licencing, continues to grow as a model. It is sometimes referred to as ‘on-demand software’, and was formerly referred to as “software plus services” by Microsoft. In a nutshell SaaS is a software licencing and delivery model in which software is licenced on a subscription basis and is centrally hosted by the provider. It exists on the cloud as opposed to being installed on the customer’s on-premises computing system. Read more about cloud computing in our blog.

Software as a Service is a growth area

SaaS has grown its share of the global enterprise software market from less than 2% in 2009 to 23% in 2019. By 2022, the global SaaS market is expected to be worth $140.63 billion. For customers, the service can offer greater access, convenience, and flexibility at a lower cost. And for vendors, it is easier, faster, and less expensive to roll out and sell to customers compared with traditional on-premises software development.

Common characteristics of SaaS arrangements

  • The service software is not installed or stored on the customer's computer systems. The SaaS provider (or its subcontractor) hosts core SaaS software applications. While the customer may receive limited client-side software to aid connectivity to the provider's network, the customer accesses the provider's software remotely on the internet or another public, private, or hybrid public and private cloud network.
  • The SaaS services and infrastructure are managed by or for the SaaS provider and shared by multiple customers. Each SaaS customer accesses the service applications remotely from various client devices, but does not configure, manage, or control the underlying cloud infrastructure.
  • Service customization is limited. The software configuration is largely or entirely uniform throughout the provider's customer base.
  • The supplier maintains the service software and provides service support subject to service levels. SaaS agreement maintenance and support provisions typically specify service levels and standards for the provision of support. Service levels define how well the provider needs to perform and are often accompanied by service credits if the provider fails to maintain certain service level standards.
  • Service fees accrue and are payable on a recurring, periodic basis. Fees may be based on provider subscription rates, the volume of customer use, or both.

Is Software as a Service More Cost Effective?

SaaS deployments are more cost effective (at least initially) than on-premise installations. SaaS customers generally pay a flat monthly fee per user for the software. SaaS implementations are also cheaper because companies don’t have to buy additional hardware or infrastructure to make the software work, so there are no capital expenditures with SaaS. You also generally don’t have to hire consultants to get the software installed as you often have to with traditional enterprise software. (There are exceptions to that generalization. For details, see Stephanie Overby’s article, “The Truth About On-Demand CRM.”) SaaS customers like the idea of a low up-front investment and a predictable expense stream, even though the cost advantages of the SaaS model may be counter-intuitive after three to five years of monthly fees.

Commercial risks in Software as a Service

Suppliers have quite understandably been marketing the potential benefits of usage-based payment models offered as part of cloud services. However, this carries an upside risk for customers if their usage of the services exceeds their expectations and budgeting. One of the key risks here is storage. If customers pay extra for more storage, they need to be certain they have policies in place to control increases in storage of information and data. Businesses need to think clearly about how long they really need to keep information (there is a clear link to legal obligations under data protection).

The most common approach now is a committed term of 1 to 3 years when signing up to an enterprise SaaS service. Suppliers want to be able to recognise revenue in their accounts and customers want to have a good degree of stability in their ICT delivery arrangements.

The commercial and contractual models for cloud service provision transfer risks back to customers, as compared to the outsourcing business model. Customers need to be able to manage a range of service delivery arrangements and to cope with the integration demands arising from using multiple cloud services. Customers need to be self-aware regarding their own capabilities to manage these risks. This may involve changes to business processes and cultures that ensure cloud services are used as efficiently as possible.

Cloud service provision, through its emphasis on standardised and commodity ICT, mean that ICT delivery organisations must work within the constraints of a standardised service offering. Businesses need to design and adopt processes that make the best use of the cloud service as it stands. A number of the traditional outsourcing providers provide consultancy-type services to assist cloud services users in these activities.

Data escrow

Software as a service data escrow is the process of keeping a copy of critical software-as-a-service application data with an independent third party. Similar to source code escrow, where critical software source code is stored with an independent third party, SaaS data escrow applies the same logic to the data within a SaaS application. It allows companies to protect and insure all the data that resides within SaaS applications, protecting against data loss.

There are many and varied reasons for considering SaaS data escrow including concerns about vendor bankruptcy, unplanned service outages, and potential data loss or corruption. Many businesses either ensure that they are complying with their data governance standards or try to enhance their reporting and business analytics against their SaaS data.

SaaS in the financial services sector

Firms subject to regulation by the Financial Conduct Authority (FCA) also have to comply with FCA security requirements.  The FCA has jurisdiction over data security breaches committed by financial services firms and continues the policy of its predecessor, the Financial Services Authority (FSA), in this area. The FCA actively pursues firms that fail to have adequate systems and controls in place to protect their customers' confidential details from being lost or stolen. For example, in 2018 it fined Tesco Bank over £16 million for failures relating to a cyber-attack.

Under the regulatory regime applying to financial institutions, firms have a responsibility to assess the risks of data loss and take reasonable steps to minimise the risks of this loss occurring. In this context, reasonable steps are deemed to be those that are proportionate to the nature, skill and complexity of the operations taking place.

Although the obligations of a financial institution are no different whether data is stored in a cloud or not, the cloud presents certain challenges in managing third-party suppliers who are responsible for handling such data within a cloud environment. At the centre of this is who has access to the data. It is easier to establish in more traditional models of service provision where the data is and who has access to it at any given time. This is more of a challenge in cloud service provision models.

The FCA has issued guidance to clarify the requirements on firms when outsourcing to the cloud and other third-party IT services. It sees the cloud as encompassing a range of IT services provided in various formats over the internet. This includes, for example, private, public or hybrid cloud, as well as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

Here to help

SaaS is ubiquitous and any business looking to use or deploy IT solutions today will encounter it. The COVID-19 pandemic has accelerated the already fast-paced adoption of cloud computing by everyone from start-ups to multinationals. A key issue for customer and supplier is ensuring that the correct contractual and commercial agreements are in place to safeguard value for money but also that the software meets the specific needs of the customer. Software development for companies used to be highly bespoke and whilst SaaS creates opportunities for speed of access and off-premises maintenance, it also has the potential to leave a customer the victim of over-standardisation i.e. one-size fits all software solutions that don’t meet the customer’s business needs.

EM law specialises in technology and contract law. Get in touch if you need advice on a SaaS agreement or have any questions on the above.


International Transfers of Personal Data

International Transfers of Personal Data - What Are The Rules?

International transfers of personal data have been shaken up in recent memory. Most obviously Brexit has placed the EU and UK in separate data protection regimes rendering any transfer between them international, meaning they are now subject to new conditions. Additionally, data transfers to the US have been disrupted by the judgement in Schrems II. This landmark case led to the striking down of the EU-US Privacy Shield which enabled free flow of data to certain US-based organisations. For more information on the impact of Brexit read our blog.

Where does it all lead? It is easy to be overwhelmed by the complexity of the legal and political implications of these developments. However, as most organisations are realising, the simple solution continues to be Standard Contractual Clauses (SCCs). After an introduction to international transfers, this blog will focus on the use and future of SCCs. Which for the majority of organisations will be the most practical data transfer mechanism.

General principle for data exports to non-UK countries

International transfers of personal data to a country outside the UK (third country) may only take place if the controller and the processor comply with certain conditions. A transfer of personal data to a third country may take place if:

  • the UK has decided that the third country ensures an adequate level of protection

or

  • the controller or processor has provided appropriate safeguards; enforceable data subject rights and effective legal remedies for data subjects are available.

Third countries with adequate levels of protection

The UK has “adequacy regulations” in relation to the following countries and territories:

  • The European Economic Area (EEA) countries. These are the EU member states and the EFTA States. The EU member states are Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden. The EFTA states are Iceland, Norway and Liechtenstein.
  • EU or EEA institutions, bodies, offices or agencies.
  • Gibraltar
  • Countries, territories and sectors covered by the European Commission’s adequacy decisions (in force at 31 December 2020). These include a full finding of adequacy about the following countries and territories: Andorra, Argentina, Guernsey, Isle of Man, Israel, Jersey, New Zealand, Switzerland and Uruguay. In addition, the partial findings of adequacy about: Japan – only covers private sector organisations. Canada - only covers data that is subject to Canada's Personal Information Protection and Electronic Documents Act (PIPEDA). Not all data is subject to PIPEDA. For more details please see the EU Commission's FAQson the adequacy finding on the Canadian PIPEDA.

International transfers of personal data - adequate safeguards

If the third country has not been granted an adequacy decision then organisations can rely upon adequate safeguards. Schrems II has added an additional burden - before you may rely on an appropriate safeguard to make a restricted transfer, you must be satisfied that the data subjects of the transferred data continue to have a level of protection essentially equivalent to that under the UK data protection regime. This can be done by undertaking a risk assessment, which takes into account the protections contained in that appropriate safeguard and the legal framework of the destination country (including laws governing public authority access to the data). This assessment is undoubtedly complex in many situations. The ICO intends to issue guidance on this topic in due course.

Controllers and processors may provide adequate safeguards by:

  • A legally binding agreement between public authorities or bodies.
  • Binding corporate rules (agreements governing transfers made between organisations within a corporate group).
  • Standard data protection clauses in the form of template transfer clauses adopted by the Commission.
  • Standard data protection clauses in the form of template transfer clauses adopted by the ICO.
  • Compliance with an approved code of conduct approved by a supervisory authority.
  • Certification under an approved certification mechanism as provided for in the GDPR.

Is the restricted transfer covered by an exception?

If you are making a restricted transfer that is not covered by UK ‘adequacy regulations’, nor an appropriate safeguard, then you can only make that transfer if it is covered by one of the ‘exceptions’ set out in Article 49 of the UK GDPR:

Exception 1. Has the individual given his or her explicit consent to the restricted transfer?

Exception 2. Do you have a contract with the individual? Is the restricted transfer necessary for you to perform that contract?

Exception 3. Do you have (or are you entering into) a contract with an individual which benefits another individual whose data is being transferred? Is that transfer necessary for you to either enter into that contract or perform that contract?

Exception 4: You need to make the restricted transfer for important reasons of public interest.

Exception 5: You need to make the restricted transfer to establish if you have a legal claim, to make a legal claim or to defend a legal claim.

Exception 6: You need to make the restricted transfer to protect the vital interests of an individual. He or she must be physically or legally incapable of giving consent.

Exception 7: You are making the restricted transfer from a public register.

Exception 8: you are making a one-off restricted transfer and it is in your compelling legitimate interests.

International transfers of personal data - Standard Contractual Clauses

You can make a restricted transfer if you and the receiver have entered into a contract incorporating standard data protection clauses recognised or issued in accordance with the UK data protection regime. These are known as ‘standard contractual clauses’ (‘SCCs’ or ‘model clauses’).

The SCCs contain contractual obligations on you (the data exporter) and the receiver (the data importer), and rights for the individuals whose personal data is transferred. Individuals can directly enforce those rights against the data importer and the data exporter.

ICO guidance on Standard Contractual Clauses

The commentary on the ICO webpage on Standard Contractual Clauses (SCCs) after the transition period ends provides guidance on what the ICO expects from UK controllers in relation to restricted transfers, i.e. when they are seeking to export personal data from the UK to entities located in countries which do not provide an adequate level of data protection. As shown above, the SCCs represent one of a number of "appropriate safeguards" available to enable such transfers to take place. SCCs are often the most practical method for organisations when it comes to data transfers.

The ICO guidance states that UK controllers can continue to use the existing EU SCCs. The guidance goes on to state:

"You are able to make changes to those EU SCCs so they make sense in a UK context provided you do not change the legal meaning of the SCCs. For example, changing references from the old EU Data Protection to the UK GDPR, changing references to the EU or Member States, to the UK, and changing references to a supervisory authority to the ICO.

Otherwise you must not make any changes to the SCCs, unless it is to add protections or more clauses on business related issues. You can add parties (i.e. additional data importers or exporters) provided they are also bound by the SCCs."

ICO versions of the SCCS

The versions of the SCCs the ICO has created contain suggested changes. These are only suggestions but if you wish to deviate from these suggested changes they should be consistent with the principles set out in the above guidance extract and the guidance generally, i.e. it needs to make sense in a UK context and not change the legal meaning of the SCCs. The ICO versions act as a starting point therefore, making changes only where strictly necessary to make them make sense.

Schedule 21 of the Data Protection Act 2018 details the types of changes that can be made to the EU version for use by a UK controller but it does also seem to allow for use of the EU version as they are, without amendment, unless disapplied by the Secretary of State or the Information Commissioner (see paragraphs 7 and 8 of Schedule 21).

Exporting from both the UK and the EU

Ideally, if personal data is to be exported from both the UK and the EU to a jurisdiction not deemed adequate by both the UK government and the European Commission, the exports from each of the UK and the EU should be treated separately as, while virtually identical, the EU GDPR and UK GDPR are completely separate regulatory regimes. If SCCs are chosen as the appropriate safeguard, the safest option would be to have the data exports from the UK and the EU to be covered by different sets of clauses (or potentially, depending on risk, to use the EU SCCs with an additional set of amendments for the UK version).

This point is underlined in the original European Commission decision of 2004 which states each set of SCCs as a whole forms a model, so data exporters should not be allowed to amend these sets or totally or partially merge them in any manner. To meet the data transfer requirements under the UK GDPR and the EU GDPR, if a controller wants to use SCCs, they cannot be adapted beyond what has been recommended by both the ICO and the guidance from the EC on their use.

Retrospective?

It is important to point out that, looking retrospectively, if the EU SCCs were entered into prior to the end of the transition period, they will continue to be valid for restricted transfers under the UK GDPR. There will not be a need to replace the EU SCCs contracted before 1 January 2020 with updated UK SCCs.

New Standard Contractual Clauses

On 12 November 2020 the EU Commission published standard contractual clauses for international transfers of personal data to third countries under the General Data Protection Regulation ((EU) 2016/679) (GDPR). This was a draft implementing decision and Annex. The Commission has previously indicated that these clauses would be finalised before the end of 2020 although, as they require the opinion of the EDPB and EDPS, and consultation with member states under the comitology procedure, they will now come into force in 2021.

The Commission notes that the clauses are a modernisation of the previous clauses, designed to better reflect the use of new and complex processing operations involving multiple parties, complex processing chains and evolving relationships. They are designed to be flexible and allow for a number of parties, including for parties to accede to the clauses later ("docking clause"). They are drafted in a modular approach with general clauses followed by options for different processing circumstances.

Key points of interest include that the clauses:

  • Can be used by controllers and processors, including those not established in the EU but that are caught by the GDPR and cover both controller to controller and controller to processor options. They can also be used for EU processor to non-EU controller transfers and processor to sub-processor transfers, both of which are new options.
  • Can be included in a wider contract and additional clauses and safeguards can be added provided these are not contradictory or prejudice the rights of data subjects.
  • Should include rules for liability and indemnification between the parties and are enforceable by data subjects as third-party beneficiaries against the data exporter or importer.

What does this mean for the UK?

Under the UK-EU trade and co-operation agreement, the UK is obliged to not exercise certain powers under its own data protection legislation including producing its own SCCs during the four to six month extension period (starting on the 1st January 2021 – for more info see our blog). The ICO intends to consult on and publish new UK SCCs during 2021. With Brexit, the ICO and Secretary of State must keep the transitional arrangements for SCCs under review, and both are now able to issue new SCCs. It may be that at some point the EU SCCs will cease to be valid, for new and/or existing restricted transfers from the UK.

The extent to which the ICO, who are reviewing the new EU SCCs, are influenced by the new EU model clauses will come to be another example of how the two regimes wish to either spilt or merge. Given that the UK has already granted countries in the EU an adequacy decision (and seem to hope to get one in return), it is not overly speculative to suggest that the new EU SCCs will, in some form or another, be incorporated into UK data protection law. However, as noted above, this will not be possible until after the four to six month extension period the UK currently find themselves in.

Here to help

International transfers of personal data is a complex area of law and in a state of transition. As suggested above the most practical solution for a lot of organisations will be the use of SCCs but that’s not to say your transfers cannot be enabled any other way (see above). The extent to which organisations will have to review their positions will be based upon whether or not the EU grants the UK an adequacy decision and the extent to which the ICO incorporates the soon to be published new EU standard contractual clauses into their own. In any event organisations need to be on the lookout for when these new clauses come into force in both the EU and UK.

If you have any questions on Brexit and data protection, data protection law more generally or on any of the issues raised in this article please get in touch with one of our data protection lawyers.


Adtech

Adtech - ICO report into adtech and real time bidding

On 22 January 2021, the Information Commissioner’s Office (ICO) announced its resumption of an investigation into real time bidding (RTB) and adtech. The investigation had been put on hold by COVID-19. Simon McDougall, ICO Deputy Commissioner, commented in a statement that the “the complex system of RTB uses people’s sensitive personal data to serve adverts and should require people’s explicit consent, which is not happening right now.”

The ICO will continue its investigation with a series of audits focusing on digital market platforms. It will issue assessment notices to specific companies over the coming months, so that it can gauge the state of the industry.

What is adtech?

Adtech (short for advertising technology) is the umbrella term for the software and tools that help agencies and brands target, deliver, and analyse their digital advertising efforts. If you have come across the terms "programmatic" or "omnichannel," then you may already know a little about what ad tech does.

Programmatic advertising, for instance, buys target audiences instead of time slots: Think about buying ad space that reaches a particular demographic wherever it is instead of buying a prime time TV spot and hoping the right people are watching.

Omnichannel marketing reaches target consumers across all channels -- mobile, video, desktop, and more -- within the context of how they've interacted with a brand (those first seeing an ad will receive a different message from those who have engaged with that brand a number of times). Adtech methodologies seek to deliver the right content at the right time to the right consumers, so there's less wasteful spending.

What is real-time bidding?

Real-time bidding (RTB) is an automated digital auction process that allows advertisers to bid on ad space from publishers on a cost-per-thousand-impressions, or CPM, basis. CPM is what you pay for one thousand people to see your ad. Like an auction, the highest bid from relevant ads will typically win the ad placement.

ICO report

On 20 June 2019 the ICO issued an update report into adtech and real time bidding. Whilst not official ICO guidance, the report identified areas in which the current real time bidding system for programmatic advertising breaches data protection and e-privacy law. In particular the report highlighted:

  • Processing of personal data is taking place unlawfully at the point of collection with adtech companies relying on legitimate interests for placing and/or reading cookies (rather than obtaining the consent the Privacy and Electronic Communications Regulations (PECR) require). Also, adtech companies are unable to demonstrate that they have properly carried out the necessary legitimate interests tests and implemented appropriate safeguards.
  • Processing of special category data is taking place unlawfully as explicit consent is not being collected.
  • Adtech companies may not be carrying out the data protection impact assessments (DPIAs) required.
  • Privacy information provided to individuals lacks clarity whilst also being overly complex. The consent frameworks examined by the ICO (including the IAB Europe Transparency & Consent Framework) ensure neither transparency and fair processing for GDPR purposes generally, nor free and informed consent for GDPR and PECR purposes.
  • The profiles created about individuals are extremely detailed and are repeatedly shared among hundreds of organisations for any one bid request, all without the individuals’ knowledge. These practices risk breaching the requirements for data minimisation and the storage limitation principles.
  • Adtech companies are inconsistent in their use of technical and organisational measures to secure personal data and do not sufficiently consider how the law applies to international transfers which take place during real time bidding.

Progress so far

In January 2020, the ICO's Executive Director for Tech Policy and Innovation published a blog about progress so far (Adtech - the reform of real time bidding has started and will continue). He noted the ICO's continued concern about the issues already raised but added that the Internet Advertising Bureau (IAB UK) and Google are starting to make the changes needed.

The IAB UK has agreed a range of principles that align with the ICO's concerns, and is developing its own guidance for organisations on security, data minimisation, and data retention, as well as UK-focused guidance on the content taxonomy. It will also educate the industry on special category data and cookie requirements, and continue work on some specific areas of detail (IAB UK sets out actions to address ICO’s real-time bidding concerns, 9 January 2020). Google will remove content categories, and improve its process for auditing counterparties. The ICO also endorses Google's proposals to phase out support for third party cookies within the next two years. Other UK advertising trade bodies will also produce guidance for their members.

Moving forward

Due to sensitivity of the work, the ICO will publish its final findings, once it has concluded its investigation. In the meantime, Mr McDougall advises organisations operating in the adtech space to urgently assess how they use personal data, in particular their compliance with obtaining individuals’ consent, reliance on legitimate interests, deployment of data protection by design and default and use of data protection impact assessments.

Using legitimate interests as a legal basis in adtech

Relying on legitimate interests may be more workable than obtaining consent for the large number of behind the scenes ad tech companies involved in buying, selling and serving advertising. Using legitimate interests rather than consent means that there is no obligation to keep consent records and, perhaps less importantly, that data portability rights (a user’s right to be able to move data between suppliers) are not triggered.

However, the ICO states in its online guidance "When is consent appropriate?" that "If you need consent under e-privacy laws to send a marketing message, then in practice consent is also the appropriate lawful basis under the GDPR". The ICO Adtech Update expands on this:

  • Trying to apply legitimate interests when GDPR-compliant consent has been obtained would be unnecessary and could confuse individuals.
  • Where an individual has given consent they would expect processing to cease when they withdrew consent. However, an entity relying on legitimate interests might seek to continue processing in this scenario, which would be unfair.

The ICO Adtech Update also makes the point that reliance on legitimate interests for marketing activities is only possible if organisations are able to show that their use of personal data is proportionate, has a minimal privacy impact, and individuals would not be surprised or likely to object. The ICO considers that the processing involved in real time bidding (RTB) cannot meet these criteria and legitimate interests cannot be used for the main bid request processing. The ICO does not rule out use of legitimate interests for other purposes, such as a demand-side platform supplementing a bid request with additional information.

Data protection impact assessments (DPIAs)

Controllers should carry out a Data Protection Impact Assessment (DPIA) before beginning processing that is likely to result in a high risk to the rights and freedoms of individuals (Article 35, GDPR). The ICO has published a list of processing operations likely to result in such a high risk, for which DPIAs are mandatory. The ICO Adtech Update confirms that Real Time Bidding, as used in adtech, involves several such processing operations. The ICO draft Direct Marketing Code states that the type and volume of processing that you can undertake in the online world, and the risks associated with that processing, mean it is highly likely that a DPIA will be required before processing begins.

Data minimisation

The GDPR requires that personal data collected must be limited to what is necessary in relation to the purposes for which it is processed. The ICO Adtech Update states that the creation of detailed profiles, repeatedly updated with information about individuals' online acitivities, is disproportionate for the purposes of targeted advertising. It is also intrusive and unfair, in particular as individuals are often unaware that the processing takes place and the privacy information provided does not clearly inform them what is happening.

Data integrity and confidentiality

Under the GDPR personal data must be stored securely. The ICO Adtech Update noted that real time bidding often involves sharing personal data with adtech companies in non-EU jurisdictions, resulting in international transfers. Further participants have no real control over the other adtech companies with whom data is shared. Contractual controls are insufficient; appropriate monitoring and technical and organisational controls are also required.

Accountability

Data controllers must be able to demonstrate their compliance with the GDPR. The ICO Adtech Update notes that the complexities of the adtech ecosystem mean that many adtech companies will find it difficult to understand, document and be able to demonstrate how their processing operations work, what they do, who they share any data with and how any processors are vetted and controlled; and how they can enable individuals to exercise their rights.

Accuracy and storage limitation

Other GDPR requirements include that data must be accurate and kept up to date and that personal data must be kept for no longer than is necessary. The ICO Adtech Update highlights the fact that because of the vast number of adtech companies involved in real time bidding it is difficult to ensure compliance with these principles. The ICO Cookie Guidance states that it is necessary to check that the duration of any cookies is appropriate; any default durations should be reviewed.

Here to help

Adtech has revolutionised the marketing industry and was firmly in place before the introduction of GDPR in 2018. It is now the ICO’s aim to bring this boom industry in line with UK data protection law. If you have any questions on adtech and data protection, data protection law more generally or on any of the issues raised in this article please get in touch with one of our data protection lawyers.