GDPR’s territorial reach: how far does it go?

Arjum MajumdarInternational businesses headquartered outside the EU but doing business in the EU need to know if EU data protection laws apply to them in order to avoid compliance problems and the possibility of significant fines.

The starting point is the territorial scope of the EU General Data Protection Regulation (“GDPR”). Virtually all European businesses will fall within the scope of the GDPR. However, the question as to whether the GDPR applies to an organisation outside the EU is not always straightforward.

On 23 November 2018, the European Data Protection Board (“EDPB”) – an independent European body that is composed of representatives of national data protection authorities – published guidelines to help shed some light on the GDPR’s territorial scope.

The guidelines were open for public consultation until 18 January 2019 and so they are not the final version. Therefore, the existing version of the guidelines should be applied in the meantime, albeit with a degree of caution, to provide some insight as to what sort of factors international businesses should be considering when determining the extent to which the GDPR applies to them.

In this article, we discuss the EDPB’s territorial scope guidelines and highlight key points.

Determining the territorial scope of the GDPR

The GDPR applies to the processing of personal data in the context of the activities of an establishment of an organisation in the EU, regardless of whether the processing takes place in the EU or not.

This is the “establishment test”.

However, the GDPR also applies to the processing of personal data of people who are in the EU by an organisation not established in the EU, where the processing activities are related to either:

  • the offering of goods or services (free or charged) to those persons in the EU (we shall refer to this as the “targeting test”); or
  • the monitoring of their behaviour where their behaviour takes place in the EU (and we shall refer to this as the “monitoring test”).

Therefore, in order for the GDPR to apply to your business, either the establishment test, targeting test or monitoring test would need to be satisfied.

The establishment test

The establishment test is essentially split into two sub-tests:

Establishment: The GDPR does not define “establishment”. However the Recitals, together with EU case law, clarify that an establishment implies “real” and “effective” activity – even a minimal one – exercised through “stable arrangements”.

The threshold for “stable arrangement” can be quite low, particularly in the context of online services (although this does not at all mean that mere access to a website in the EU constitutes establishment). In some circumstances, the presence of a single employee or agent in the EU may be sufficient where that agent or employee acts with a sufficient degree of stability.

Context of activities: To satisfy this test, there must be an inextricable link between the activities of the EU establishment and the processing of data carried out by the non-EU counterpart. If there is an inextricable link, then the GDPR will apply to that processing by the non-EU entity, whether or not the EU establishment plays a role in the data processing.

Therefore, non-EU organisations should assess each of their data processing activities and determine whether there are any potential links between the processing activity and the activities of any presence of the organisation in the EU.

If the above two tests are satisfied, then the GDPR will apply. This is regardless of whether the processing takes place in the EU or not.  Moreover, the residence or geographical location of the individual (whose data is being processed) is irrelevant.

The targeting test

An organisation with no establishment in the EU may still be caught by the GDPR if it meets the targeting test.

An organisation could be directly subject to the GDPR if it processes the personal data of individuals who are in the EU, where the processing activities are related to the offering of goods or services to those individuals.

The Recitals to the GDPR state that the “mere accessibility” of the business’ website, of an email address or other contact details or the use of a generally-used language in the country in which the business is domiciled would be “insufficient” in and of itself to conclude that the business is offering services to individuals in the EU.

The EDPB guidelines list a number of factors to take into consideration when determining whether goods or services are offered to individuals in the EU. These include the following activities (via the internet or otherwise):

  • the designation (or “singling out”) of the EU or at least one Member State of the EU by name;
  • launching marketing and advertising campaigns directed at an EU country audience;
  • paying a search engine operator for an internet referencing service to facilitate access to its site by people in the EU;
  • the international nature of the activity at issue;
  • the mention of an international clientele composed of clients domiciled in various EU Member States; and
  • the use of different languages or currencies.

Each activity on its own may not amount to a clear indication that the business offers goods or services to individuals in the EU. However, each factor should be taken into account to determine whether the business’ activities constitute the offer of services to individuals in the EU.

The monitoring test

An organisation outside the EU may also be caught by the GDPR if it is monitoring individuals’ behaviour where their behaviour takes place in the EU.

The Recitals state that in order to determine whether a processing activity can be considered to monitor the behaviour of individuals, it should be ascertained whether the individuals are tracked on the internet. Tracking on the internet includes “potential subsequent use of personal data processing techniques which consist of profiling a natural person, particularly in order to take decisions concerning her or him or for analysing or predicting her or his personal preferences, behaviours and attitudes”.

The EDPB guidelines also say that while the Recital exclusively relates to the monitoring of behaviour through the tracking of a person on the internet, it considers that tracking through other types of network or technology should also be taken into account, for example through wearable and other smart devices.

The guidelines suggest that the use of the word “monitoring” implies that the business has a specific purpose in mind for the collection and subsequent reuse of the relevant data about an individual’s behaviour within the EU. The EDPB does not consider, on the other hand, that any online collection or analysis of personal data of individuals in the EU would automatically count as “monitoring”. It is instead necessary to consider the business’ purpose for processing the data and, in particular, the subsequent behavioural analysis or profiling techniques involving that data. The guidelines also set out a non-exhaustive list of the sort of activities which would constitute monitoring which includes behavioural advertising, online tracking through the use of cookies, CCTV, market surveys, geo-localisation activities and other tracking techniques.

Therefore, international businesses should review their website tracking activity and uses of automated analytical tools (such as cookies to track website usage). It is possible that these activities fall within the scope of the GDPR to the extent that the information collected is capable of identifying individuals.

What if the targeting test or monitoring test is satisfied?

The business would be required to designate an EU representative in accordance with the requirements of the GDPR. This person or company would act as the main contact for any questions and concerns regarding data protection in the EU. The appointment of an EU representative does not have the effect of creating an establishment and meeting the establishment test.

Controller or processor

The GDPR draws a distinction between a data controller – which determines the purposes and means of the processing of personal data (that is, the “how” and “why” personal data is processed) – and a data processor which processes personal data on behalf of, or on the instruction of, the data controller.

The EDPB guidelines emphasise the importance of this distinction, particularly when assessing the territorial scope of the GDPR. When determining whether the GDPR applies, the above three tests would need to be undertaken with each legal entity. A processor in the EU is not considered to be an establishment of a data controller based outside the EU. In such a scenario, the processor would be required to comply with its requirements under the GDPR (due to its establishment in the EU) but the controller would not.

The opposite also applies: if a controller is based in the EU and uses a processor outside the EU, the controller will be subject to the GDPR but the processor will not be. However, in this scenario, the controller would be required to ensure that its processor will meet certain requirements (including that there is a written agreement with GDPR-compliant clauses) which effectively means that the processor would be caught by the GDPR, albeit indirectly.

Conclusion

The EDPB draft guidelines do not contain all the answers and, for many businesses, the answer to the question “does the GDPR apply to us?” may still not be straightforward despite the guidelines.  It is possible that the guidelines’ shortcomings will be addressed in the final text. However, there is no guarantee that the final text will be any clearer.

In the meantime, international businesses need to adopt a systematic approach and review all of their data processing activities. In doing so, the above tests will then need to be applied to determine which of those activities might be caught by the GDPR. Where your business consists of a group of multiple entities, the tests should be applied to each entity within the group. Having done this, you can then move forward in determining which divisions of your business, if any, require a GDPR-compliance programme.

 

Arjun Majumdar is an associate in the commerce & technology team at City law firm Fox Williams LLP and can be contacted at amajumdar@foxwilliams.com 

Updated Guidance on Data Protection Impact Assessments (DPIAs)

Sian Barr

The Information Commissioner’s Office (ICO) has recently updated its guidance on conducting DPIAs following guidance and recommendations from the European Data Protection Board.

A DPIA is mandatory if you are carrying out processing which is likely to result in a high risk to individuals.  The GDPR requires controllers to go through a DPIA process if they plan to:

  • use systematic and extensive automated processing (i.e. profiling) with legal or other significant effects;
  • process special category or criminal offence data on a large scale; or
  • carry out large scale systematic monitoring of a publicly accessible place.

But, the three examples of high risk processing identified in the GDPR are not exhaustive.  The ICO’s newly updated guidance is helpful in determining whether those processing operations that do not fit neatly into one or more of the three categories above warrant a DPIA because they are high risk.

The ICO directs those who are assessing whether or not their processing is high risk to consider the guidelines on DPIAs (WP248 rev 01) adopted by the Article 29 Working Party and endorsed by the European Data Protection Board (the “European guidelines”).  The European guidelines contain nine criteria for assessing high risk processing operations, summarised here:

  1. Evaluation or scoring, including profiling and predicting, especially from aspects concerning the data subject’s performance at work, economic situation, health, personal preferences or interests, reliability or behaviour, location or movements.
  2. Automated-decision making with legal or similar significant effect.
  3. Systematic monitoring: processing used to observe, monitor or control data subjects, including data collected through networks or a systematic monitoring of a publicly accessible area.
  4. Sensitive data or data of a highly personal nature.
  5. Data processed on a large scale.
  6. Matching or combining datasets.
  7. Data concerning vulnerable data subjects e.g. children or employees.
  8. Innovative use or applying new technological or organisational solutions.
  9. When the processing in itself “prevents data subjects from exercising a right or using a service or a contract” e.g. screening or eligibility checks.

If your processing covers two or more of these criteria then the European guidelines state that a DPIA will be required in most cases but beware too that processing including only one of the criteria can also be high risk and require a DPIA.  The European guidelines also contain useful examples as to how the criteria can be used effectively.

The ICO guidelines then provide a further list of processing operations in respect of which the ICO requires a DPIA:

  • using innovative technology (in combination with any of the criteria from the European guidelines);
  • using profiling or special category data to decide on access to services;
  • profiling individuals on a large scale;
  • processing biometric data (in combination with any of the criteria from the European guidelines);
  • processing genetic data (in combination with any of the criteria from the European guidelines);
  • matching data or combining datasets from different sources;
  • collecting personal data from a source other than the individual without providing them with a privacy notice (‘invisible processing’);
  • tracking individuals’ location or behaviour;
  • profiling children or target marketing or online services at them; or
  • processing data that might endanger the individual’s physical health or safety in the event of a security breach.

The ICO has to a certain degree relaxed its own criteria for determining high risk processing, in that a DPIA is now only mandatory for the use of biometric data, genetic data or innovative technology when combined with one of the criteria from the European guidelines.

Finally, a brief reminder as to why it is important to make the correct decision when it comes to DPIAs: failure to carry out a mandatory DPIA may result in enforcement action, including an administrative fine of up to €10 million, or 2% of global annual turnover if higher.  So, it can’t be wrong to carry out a DPIA, the consequences can be serious if you are required to undertake a DPIA but fail to do so.

 

Sian Barr is a Senior Associate in the commerce & technology team at City law firm Fox Williams LLP and can be contacted at sbarr@foxwilliams.com

€50m fine for Google in France

Nigel Miller
Nigel Miller

On 21 January 2019, the French data protection authority, the CNIL, imposed an eye-watering €50m penalty on Google under the GDPR. Side-stepping the €20m maximum the CNIL issued a turnover related fine, highlighting that the maximum possible fine under the GDPR is €20m or 4% of global annual turnover, whichever is the greater.

The investigation was initiated as a result of complaints made within days of the GDPR coming into effect in May 2018. The complaints were from the associations None Of Your Business (“NOYB”) and La Quadrature du Net (“LQDN”), mandated by 10,000 people to refer the matter to the CNIL.

The case concerns personalised ads on smart phone devices using the Android operating system with a Google account. The regulator found two types of breaches of the GDPR. First, a lack of transparency, and second a lack of valid consent regarding the targeted ads.

Transparency

The requirement for transparency goes to the heart of the GDPR and applies to all processing.

CNIL looked at the information and process a user goes through when setting up the account. They found that the information provided by Google is not easily accessible. Essential information, such as the purposes of the processing, data storage periods and the categories of personal data used for the ads personalization, are disseminated across several documents. Specifically, information is not clear enough so that a user can understand that the legal basis of processing for the ads personalization is consent, and not the legitimate interest of Google.

Meanwhile, the processing operations are “massive and intrusive” because of the number of services offered (e.g. Google search, You tube, Google home, Google maps, Playstore, Google pictures…), and the amount and the nature of the data processed and combined.

Lack of a legal basis

The GDPR also requires a legal basis for processing. “Consent” is one of the possible legal basis and the GDPR significantly raised the bar for obtaining a valid consent.

The CNIL decided that the user’s consent is not validly obtained for two reasons. First, the consent is not sufficiently informed –  a lack of transparency is fatal to obtaining a valid consent.. Second, the collected consent is neither “specific” nor “unambiguous”. The user gives his or her consent for all processing operations together, whereas the GDPR requires that the consent is “specific” only if it is given distinctly for each purpose, i.e. a separate consent for each separate processing operation.

Google has said it will appeal the decision.

The case highlights the imperative of, as well as the difficulties in, obtaining a valid consent especially in the complex and mystifying world of targeted advertising where presentation of transparent intelligible information to a user in order to inform consent is challenging.

Nigel Miller is a partner in the commerce & technology team at City law firm Fox Williams LLP and can be contacted at nmiller@foxwilliams.com

Managing data breaches – notification and risk management

[This article was first published in Computers & Law, the magazine of the Society for Computers and Law]

It’s Friday, late afternoon. The phone rings. “We think we’ve had a data breach. What do we need to do?”.  The first thing is to cancel your plans. The clock is now ticking.

According to figures from the Department for Culture, Media and Sports[i], over four in ten of all UK businesses suffered a breach or attack in the past 12 months. This figure rises to more than two thirds for large businesses. The most common breaches or attacks were via fraudulent emails, then malware and viruses.

The Information Commissioner, Elizabeth Denham, has said that there is no data privacy without data security; data protection and cyber-security go hand in hand.

Data security requirements

Data security is addressed by the sixth principle under Article 5 GDPR[ii] which requires that personal data must be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’)”.

Under the accountability principle, the controller must also be able to demonstrate compliance with this principle.

Article 32 deals specifically with data security and, importantly, applies to both controllers and processors.

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk

The Article goes on to list examples of appropriate measures, including pseudonymisation (defined in Article 4(5)) and encryption. While these techniques fall short of being mandatory, they can “reduce the risks to the data subjects concerned and help controllers and processors to meet their data-protection obligations” (Recital 28). In the event of a data breach, if such measures had been implemented, the controller may not be required to notify the ICO or data subjects. Conversely, if such measures were not implemented, the risks will be much higher, the notification obligation cannot be avoided and there may be adverse consequences in terms of regulatory action and fines.

Data breach notification

Under the former Data Protection Act 1998, while the ICO recommended that serious breaches should be reported to the ICO[iii], there was no legal obligation to notify the ICO or data subjects[iv]. Because of the risk of adverse publicity and loss of goodwill in the event of a data breach, there was a tendency for organisations to prefer not to report. As a result, many data breaches went unreported.

One of the more impactful changes introduced by the GDPR, therefore, is mandatory data breach notification.

A personal data breach is defined in Article 4(12) as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.

The European Data Protection Board (EDPB) (formerly known as the Article 29 Data Protection Working Party) in their guidelines on personal data breach notification[v] (“the Guidelines”) define three types of breach:

  • “Confidentiality breach” – where there is an unauthorised or accidental disclosure of, or access to, personal data.
  • “Integrity breach” – where there is an unauthorised or accidental alteration of personal data.
  • “Availability breach” – where there is an accidental or unauthorised loss of access to, or destruction of, personal data.

Do you need to notify?

Under Article 33, there is an obligation to report a personal data breach to the ICO – unless the breach is “unlikely to result in a risk” to data subjects.

There is also an obligation to notify data subjects if the breach is “likely to result in a high risk” (Article 34) (emphasis added).

The GDPR explicitly says that notification to data subjects is not required if technical protection measures had been used to render the personal data unintelligible – such as encryption.

Accordingly, under the GDPR there is a legal duty to notify the ICO of the breach, even where the risk may not be “serious”, unless it can be said that there is no risk. However, there may be no obligation to notify data subjects if the risk is not “high”.

The GDPR is only engaged where there is a data breach involving personal data. A security incident involving corporate data or IP or disruption to systems, while potentially serious, will not require notification to the ICO if personal data is unaffected.

When to notify

The controller must notify the ICO “without undue delay and, where feasible, not later than 72 hours after having become aware of” the data breach.

There is, therefore, a very tight time-frame in order to assess what has happened and if the notification obligation arises. The 72 hours runs from “awareness”[vi]. However, it is not always clear when an organisation becomes aware. For example, if a junior member of the IT team is involved in a breach on a Friday pm, but does not report it to his manager until Monday morning, when did the period begin? If you identify an issue, but are not sure whether it is a “personal data breach” or not pending further investigation, the period kicks in once there is a “reasonable degree of certainty” that a data breach has occurred.

Turning a blind eye or not having systems to monitor for breaches is not an option. Recital 87 provides that technological protection and organisational measures should be implemented “to establish immediately whether a personal data breach has taken place”. It is possible, therefore, that you could be responsible for failure to notify a breach of which you were not actually aware, but of which you should have been aware had you implemented appropriate systems.

There is some limited flexibility provided by the “where feasible” qualification. However, if the notification is not made within the 72 hours, the controller must give reasons for the delay.

The GDPR recognises that controllers may not always have all of the necessary information concerning a breach within 72 hours of becoming aware of it. Article 33(4) provides that if it is not possible to provide all the information at the same time, the information may be provided in phases without undue further delay. Updates should then be provided to the ICO once more information becomes available.

Notification to data subjects

Even where notification to the ICO is required, it does not inevitably follow that the affected data subjects should also be notified. This depends on an assessment of the likelihood and severity of the risks presented by the breach and what the benefits of notification may be. Risks include identity theft, fraud, financial loss, damage to reputation and loss of confidentiality. Where the breach involves special categories of data, such damage should be considered likely to occur.

A key objective of notification is to help individuals to take steps to protect themselves from any negative consequences of the breach. For example, if there is a risk that bank details could be misused, notification might enable affected individuals to take steps to protect themselves by changing passwords.

Annex B of the Guidelines provides a non-exhaustive list of examples of when a breach may be likely to result in high risk to individuals. The Guidelines suggests that, if in doubt about notification, the controller should err on the side of caution and notify. Even where notification is not legally required, many organisations may consider notifying data subjects on a non-mandatory basis for transparency or to avoid data subjects finding out about the breach from other sources.

The GDPR states that communication of a breach to individuals should be made “without undue delay,” which means as soon as possible.

If communication to data subjects would “involve disproportionate effort”[vii], then controllers can notify them by some form of public communication.

Processors

Processors must notify their instructing controller if the processor suffers a data breach. Unlike the notification requirement on controllers, there is no fixed timeframe and a processor must notify the controller “without undue delay after becoming aware of” the breach. It is for the controller then to determine what if any notification requirement arises.

In data processing agreements with processors, controllers may want to be more specific about this time-frame. There is no particular logic to requiring the processor to notify within say 36 hours so that the controller can meet the 72 hour requirement, as the controller’s 72-hour-deadline only commences on receipt of notification from the processor. Fortunately, the EDPB have moved away from their former impracticable view that controllers should be deemed aware of the breach once the processor is aware.

Some processors may not want to accept a shorter notification requirement than is required of controllers. On the other hand, processors do not have to engage in any risk assessment – any breach is notifiable to the controller. However, the controller will want to ensure that processors provide sufficient detail about the breach to enable the controller to assess the risk and provide to the ICO the information required by Article 33(3).

Joint controllers

Pursuant to Article 26 joint controllers should set out in the arrangement between them which party will have responsibility for taking the lead on compliance with the breach notification obligations.

Data breach register

Under Article 33(5), controllers must document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. This documentation may be called for by the ICO in any enquiry as to whether the controller has complied with the notification requirements.

Data breaches need to be documented even where there is no requirement to notify the breach to the ICO. Where a decision is made not to notify a breach, while not specifically required, it is highly advisable also to document the reasoning behind the decision.

Failure to notify

The fines for failure to notify can be up to 10m EUR or 2% of global annual turnover, whichever is the higher. Even where there is compliance with the breach notification requirement it is possible that the breach could reveal an inadequacy of data security measures which could lead to a first tier fine in respect of inadequate security measures as a separate infringement.

In addition, under Article 82, any person who has suffered “material or non-material” damage has the right to claim compensation from the controller or processor for the damage suffered. Therefore, a data subject will be able to claim for any additional damage suffered as a result of their not having been notified of the breach when, if they had been notified in a timely way, they could have taken some steps to protect themselves.

Other notification obligations

Aside from the ICO, controllers and processors might also need to consider notifying other third parties such as the police (where there is evidence of criminal activity), professional bodies, and bank or credit card companies who may be able to assist in reducing the risk of financial loss to individuals.

FCA regulated entities will have a separate duty to notify the FCA on matters which may have a serious regulatory impact.

Under the NIS Regulations, operators in electricity, transport, water, energy, transport, health and digital infrastructure must notify the designated competent authority about any incident which has a significant impact on the continuity of the essential service, also within 72 hours[viii].

Telecom providers must notify the ICO within 24 hours under PECRs[ix].

Organisations with data / cyber breach insurance should notify the event to their insurers in case of any claims.

You may also need to consider if there are any contracts with third parties which require you to notify the third party if you, or a sub-processor, suffer a data breach. You may also need to consider the liability and indemnity provisions of those contracts a they apply to data breaches.

Data breach response plan

One of the most important internal policies to be implemented for GDPR purposes is a data breach or incident response plan. This will assist organisations swiftly to identify and respond to a data breach and ensure that staff within the organisation know how to recognise a breach and how to report it internally.

It will also set out who has responsibility within the organisation for managing a breach and the process to follow to contain the incident, assess the risks that could result from it and remedy any shortcomings in systems or policies.

As such, a data breach plan can be vital in helping to manage risk in the event of an incident.

Other risk management considerations

It is, of course, preferable to take steps to prevent a breach rather than to have to respond to one. The GDPR requires continuous evaluation of risk. It encourages use of encryption, pseudonymisation and anonymisation. It requires appropriate technical and organisational measures including internal policies to be in place having regard to the state of the art and also the costs of implementation. This includes systems to identify when a personal data breach has taken place. It requires personal data minimisation which reduces risk posed by processing superfluous data. It provides for data protection by design and by default. It requires organisations to regularly test, assess and evaluate the effectiveness of their technical and organisational data security measures. It requires organisations to have appropriate contracts in place with service providers. And it requires organisations to be accountable.

In the event of a breach, the notification requirement is only one element. There are potentially many other aspects to consider in terms of managing legal and business risk, including the following:

  • The incident response team should include communication and PR specialists in order to manage communications to affected data subjects, unaffected customers, the wider public, the media, shareholders and other stakeholders in a speedy and effective manner, and so as to minimise brand damage. Recent breaches have highlighted how important advance media training can be in preparing for an incident.
  • Take care not to rush to accept blame (liability) where that is or may not be due; in some cases organisations that suffer a data breach are victims and not necessarily at fault.
  • Where appropriate ensure communications are channelled via the legal team in order to preserve legal professional privilege over potentially sensitive materials that may affect liability for the breach.
  • If you have a data protection officer, the Guidelines recommend that the DPO is promptly informed about the existence of a breach and is involved throughout the breach management and notification process.
  • Where a breach involves a risk of identity theft, consider offering affected data subjects free credit monitoring services for a period.
  • It is important for organisations to be able to demonstrate an appropriate response to a data breach involving any of their staff; for example, if employee refresher training is needed, if updates to or additional policies or procedures are needed; or if disciplinary action should be taken in respect of an employee who did not follow the organisation’s policy.

 

Nigel Miller is a partner in Fox Williams LLP and is an SCL Fellow.

 

[i] The Cyber Security Breaches Survey 2018 was carried out for DCMS by Ipsos MORI, in partnership with the Institute for Criminal Justice Studies at the University of Portsmouth.

[ii] Regulation (EU) 2016/679 (General Data Protection Regulation)

[iii] ICO – Notification of data security breaches to the Information Commissioner’s Office (ICO) – 2012-07-23

[iv] Save for providers of public electronic communications services under the Privacy and Electronic Communications (EC Directive) Regulations 2003 (2003/2426) (as amended).

[v] Guidelines on Personal data breach notification under Regulation 2016/679 (WP250rev.01) adopted on 3 October 2017. As last revised and adopted on 6 February 2018.

[vi] The 72 hours includes public holidays, Sundays and Saturdays (Regulation No 1182/71 on the rules applicable to periods, dates and time limits).

[vii] WP29 Guidelines on transparency WP260 consider the issue of disproportionate effort.

[viii] The Network and Information Systems Regulations 2018 (2018 No. 506)

[ix] The Privacy and Electronic Communications (EC Directive) Regulations 2003; the European Commission Regulation 611/2013

Focus on fines

Nigel Miller
Nigel Miller

Since the GDPR came into force on 25 May 2018 the ICO has carried out a number of audits on organisations as well as a number of “advisory” visits. These do not necessarily lead to regulatory sanctions but sometimes they do.

Reportedly, since the GDPR came into force, there has been a 160 per cent rise in the number of complaints made to the ICO on the same period in 2017. This is a result of the build up to the GDPR which has heightened individuals’ awareness of their data rights.

In terms of fines, it is too soon after the GDPR came in for GDPR level fines to come down the line as these can take some months to be awarded after the initial complaint. Currently, the UK ICO is issuing fines under the old law where the initial complaint preceded 25 May 2018. Under the old law the maximum fine was £500k.

Under the GDPR, companies can be fined €20 million (£16.5m) or 4 per cent. of their worldwide turnover, whichever is the greater.

Examples of fines over the last month include:

September:

Equifax Ltd –  maximum fine £500,000 for failing to protect the personal information of up to 15 million UK citizens during a cyber-attack in 2017. The ICO investigation found that, although the information systems in the US were compromised, Equifax Ltd was responsible for the personal information of its UK customers. The UK arm of the company failed to take appropriate steps to ensure its American parent Equifax Inc, which was processing the data on its behalf, was protecting the information.

Everything DM –fined £60,000 for sending 1.42 million emails without consent.  Between May 2016 and May 2017, the firm used its direct marketing system called ‘Touchpoint’ to send emails on behalf of its clients

Bupa Insurance Services Limited (Bupa) – fined £175,000 for failing to have effective security measures in place to protect customers’ personal information.

Oaklands Assist –  fined £150,000 for making thousands of nuisance direct marketing phone calls.

October:

Heathrow Airport fined £120,000 for failing to ensure that the personal data held on its network was properly secured.

Boost Finance – fined £90,000 for millions of nuisance emails about pre-paid funeral plans.

It is reported that the ICO intends to fine Facebook the maximum £500k following the investigation launched in 2017 over the use of data for political campaigns. Were the breach to have happened after 25 May 2018, the ICO would have been able to issue a fine of up to 4% of Facebook’s annual worldwide turnover (reportedly meaning a maximum fine of £479m).

How fines are assessed under GDPR

Fines are regarded as an important tool for the supervisory authorities who have said they will not shy away from issuing fines or only use fines as a last resort.

The Regulator has said that fines under the GDPR are to be “effective, proportionate and dissuasive”.  Fines may be imposed in response to a wide range of infringements. Each case is to be assessed individually.

Factors to be taken into account in assessing fines are:

  • the nature, gravity and duration of the infringement;
  • the number of data subjects involved;
  • the categories of the personal data affected (e.g. special categories, directly identifiable data, data whose dissemination would cause damage/distress to the individual);
  • is it is an isolated event or symptomatic of a more systemic breach or lack of adequate routines in place;
  • if data subjects have suffered damage, and the level of the damage;
  • action taken to mitigate the damage suffered by data subjects;
  • the intentional or negligent character of the infringement, and the degree of responsibility of the controller or processor taking into account technical and organisational measures implemented;
  • any relevant previous infringements by the controller or processor;
  • the degree of cooperation with the supervisory authority;
  • whether, and if so to what extent, the controller or processor notified the infringement;
  • any other aggravating or mitigating factor applicable to the circumstances, such as financial benefits gained, or losses avoided, directly or indirectly, from the infringement.