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 Digital, Culture, Media and Sports[1], 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,[2] 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.
Article 32 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,[3] there was no
legal obligation to notify the ICO or data subjects.[4]
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[5] (‘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 engaged only 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 timeframe
in order to assess what has happened and if the notification obligation arises.
The 72 hours runs from ‘awareness’.[6] 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’[7] 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 timeframe.
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 commences only 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.[8]
Telecom providers must notify the ICO
within 24 hours under PECRs.[9]
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 as 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.
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
continual 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.
[1] 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.
[2] Regulation (EU) 2016/679 (General Data Protection Regulation)
[3] ICO – Notification of data security breaches to the Information
Commissioner’s Office (ICO) – 2012-07-23
[4] Save for providers of public electronic communications services
under the Privacy and Electronic Communications (EC Directive) Regulations 2003
(2003/2426) (as amended).
[5] 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.
[6] The 72 hours includes public holidays, Sundays and Saturdays (Regulation
No 1182/71 on the rules applicable to periods, dates and time limits).
[7] WP29 Guidelines on transparency WP260 consider the issue of
disproportionate effort.
[8] The Network and Information Systems Regulations 2018 (2018 No. 506)
[9] The Privacy and Electronic Communications (EC Directive)
Regulations 2003; the European Commission Regulation 611/2013