This article summarises
WP250,
guidance from EU regulators WP29 on breach notification to supervisory authorities
and data subjects under the GDPR (Arts.33-34). The Annex highlights some areas
where the guidance may increase confusion about technical security matters. For
some specific problems under WP250, please see my IAPP article.
Overview
Be
prepared – unsurprisingly,
WP250 urges controllers’ and processors’ advance
implementation of incident response plans for handling personal data breaches (PDBs).
·
Scope – plans should cover allocating internal
operational responsibilities (with processes to funnel incident-related info to
the right people), detecting/establishing PDBs, incident management including appropriate
internal escalation/reporting, containment/recovery/ remediation, assessing
likely risk to individuals (see later – likelihood of no risk, risk or high
risk) and other actions, notably making any necessary notifications to the
supervisory authority (SA) and
affected individuals, to which SA, etc. All this should happen “soon after” the
initial alert, save in “exceptional cases”. It’s “useful” for GDPR compliance
to show employees were told about these plans and know how to respond.
·
DPIA – a prior data protection impact assessment
might have considered potential risks from PDBs, but each actual PDB requires specific risk assessment.
·
DPO – any data protection officer should be
involved in PDB notifications and subsequent SA investigations.
·
Lawyers – not mentioned in WP250 (why would it?),
but involve ASAP data protection/ security lawyers (ideally, covered in the
plan) to help preserve legal privilege for forensic reports etc. in case of future
claims/litigation/regulatory sanctions, and advise on notifications, damage mitigation
and fines reduction.
·
Security
measures (Art.32) must
include measures to “detect, address and report a breach in a timely manner” (also
Rec.87). If encrypting, consider “quality” [algorithm strength, key size?],
implementation, outdatedness; change “default keys” [default admin passwords?],
etc. If a DPIA suggests particular security software, but a vulnerability
becomes known, reassess the software “as part of an ongoing DPIA”. Take backups, as
well as encrypting whenever possible.
·
Potential
“double whammy” – organisations
can be fined for not notifying personal data breaches, and for inadequate security measures: “…they are two separate
infringements”.
·
Triple
whammy? – SAs can order controllers to notify individuals (Arts.34(4), 58(2)(e)). Disobey
on pain of a 4%/€20m fine (Art.83(6)).
·
Good
encryption good – organisations
can escape notifying, not only individuals, but maybe even SAs, of PDBs affecting
encrypted data, as the breach is “unlikely” to result in risks to individuals,
e.g. losing a securely-encrypted mobile – but only if the encryption applied was appropriate, properly
implemented, and not e.g. using an outdated algorithm.
·
Prompt
investigation vital – plans
should enable prompt investigation of incidents to determine whether any PDB
occurred and, if so, remediate and notify. Otherwise, regulators may assume earlier
“awareness” of breaches (and possible Art.33 infringement). Therefore,
controllers must act on “any initial
alert” (from whatever source), not ignore them.
·
Awareness – a “short” period of
investigating an incident is allowed before controllers are considered “aware”.
But as soon as your processor is “aware”, “in principle” you’re aware (and your 72-hour
notification clock begins running) from that same point in time!
·
PDBs
at processors – Art.33(2) already
requires processors to notify their controllers. However, WP250 recommends specific
arrangements: controller-processor contracts’ mandatory terms on processors
assisting controllers with breach notification (Art.28(3)(f)) should specify
how processors should notify controllers.
·
Notifying
“without undue delay”
·
Regulators
consider processors should give “immediate” notification of PDBs to all their
affected controllers, with further info in phases when available.
·
If controllers
notify affected individuals (when that’s required) “without undue delay”, that
means “as soon as possible”, or as soon as “reasonably feasible”.
·
Don’t
forget Rec.87: what’s not “undue delay” in one situation may be in another,
depending on the PDB’s nature, gravity, and consequences/adverse effects for
individuals.
·
Not
knowing precise info, e.g. exact numbers of individuals affected, is no excuse
for delayed notification.
·
If an
incident affects multiple individuals similarly, strictly each is reportable. However, WP29 will accept a meaningful “bundled”
notification covering similar personal data breached in a similar manner over a
short period, whether after or within 72 hours.
·
Processors
can notify for their controllers – if the controller-processor contract authorises it. But controllers
retain legal responsibility. So, they might not want to delegate notifications
to processors.
·
Notify
what? – under WP250:
·
Art.33(3)’s
“categories” of data subjects means e.g. children/other vulnerable groups, disabled
people, employees, customers; categories of records means health data,
educational records, social care info, financial details, bank account numbers,
passport numbers etc.
·
Describing
“likely consequences” includes indicating risk categories: identity theft,
fraud, financial loss, threat to professional secrecy. Focus on adverse
effects.
·
Provide
approximate numbers if still unknown, then details later.
·
If more info will follow, WP250 recommends
telling the SA so. However, “The
supervisory authority should agree how and when additional information should
be provided” seems unrealistic (and isn’t required by the GDPR). SAs
shouldn’t dictate how quickly forensics investigators must discover info, investigators
should be allowed to take whatever time they need to do their jobs properly.
·
Provide
more info than Art.33(3) specifies, if desired.
·
“Shop the processor?” – Processors may want controller-processor
contracts to require controller notifications to be accurate and fair (some
controllers may just blame processors even if unwarranted?), and give processors
some say/role in controllers’ notification processes!
·
SAs can
request further info.
·
One
purpose of notifying SAs within 72 hours is for advice on whether to notify
individuals (see below).
·
Notify,
de-notify… – update the SA
on ascertaining that the incident was contained and no breach occurred. There’s
no penalty for reporting something that transpires not to be a breach. Overall,
WP250 may drive organisations to notify SAs of all incidents within 72 hours “just
in case”. Will overwhelmed SAs “take back” some of WP250 in a year…?
·
Notifying
individuals if “likely” “high risk” – must be considered independently of SA notification. Exceptionally, notify
individuals before SAs.
·
A “description”
of measures to address/mitigate (Art.34(2)) may include:
·
E.g.
that “after having notified the breach to the relevant supervisory authority,
the controller has received advice on managing the breach and lessening its
impact.”
·
Where
appropriate, specific advice to individuals to protect themselves e.g.
resetting passwords where access credentials were compromised.
·
Provide
more info than Art.33(3) specifies, if desired.
·
Notify affected
individuals directly; if that involves “disproportionate effort”, use public
communication or similar: email, SMS, “direct message”, website banners/notification,
post, prominent print ads (a press release/corporate blog alone isn’t good enough).
WP250 recommends using several channels (but not one compromised by attackers!)
·
Alternative
formats/languages may be needed.
·
Consider
consulting the SA on appropriate notification content/channels.
·
“Get-outs”
from notifying individuals:
·
Controllers
must be able to demonstrate they meet a “get-out”, including as risks change
over time.
·
Potential
2%/€10m fine if individuals aren’t notified when the SA thinks they should be.
·
Breached
data being “unintelligible” to unauthorised persons is said to include
“state-of-the-art” encryption – suggesting that outdated/poor encryption won’t be enough to avoid notification.
·
Steps
to ensure “high risk” is no longer likely – include identifying and acting
against whoever accessed data before they could “do anything with it”.
·
“Disproportionate effort” – e.g. where contact
details were lost in the breach or never known. “Technical arrangements” could make on-demand information about the breach
available to individuals that the controller can’t otherwise contact.
·
Risk assessment – vital following
awareness of breach. Knowing likelihood
and potential severity of impacts on
individuals helps (1) containment [mitigating risks to individuals? Cf.
breach containment], and (2) determining whether/who to notify. Risks are
higher with greater severity and/or likelihood. “If in doubt, the controller should err on the side of caution and
notify.”
·
“High
risk” – is where the breach
may lead to physical, material or non-material damage, e.g. discrimination,
identity theft/fraud, financial loss or reputational damage. Damage “should be”
considered “likely” if breached data are “special category” or criminal
convictions/offences data.
·
Factors include:
·
Breach type e.g. confidentiality or loss; nature
(name/address vs. adoptive parent’s address), sensitivity (more sensitive is
higher risk), volume of data, number of affected individuals (greater data
volume/number, higher risk; but, “a
small amount of highly sensitive personal data can have a high impact on an
individual, and a large range of details can reveal a greater range of
information about that individual”). Combined data’s more sensitive than
one “piece” (e.g. health data plus identity documents/credit card details).
Stopped deliveries (holidays) may indicate vulnerable homes. A little highly sensitive
data can be very impactful; a large “range” of data, very revealing.
·
Identifiability
– how easily can someone accessing compromised data identify individuals e.g.
by matching with other info? Much depends on context, public availability of
related details, etc. Pseudonymisation not just encryption can reduce
identifiability.
·
Severity
of consequences – affected by nature of data e.g. special categories;
vulnerable individuals; whoever accessed data (if known, e.g. disclosed in
error, or otherwise trusted to return/destroy data, cf. actors with
malicious/unknown intentions). EU security agency ENISA’s severity assessment methodology may be useful when formulating response
plans. Longer-term consequences have greater impact.
·
Characteristics
of individuals/controllers – e.g. risks may be greater with children/vulnerable
individuals; and with medical controllers with health data (cf. newspaper
mailing lists).
·
Cross-EU
breaches – notify the lead SA.
Ideally, indicate which other Member States’ individuals are affected and
notify SAs there too.
·
Accountability
and record-keeping – controllers
must document even unnotifiable breaches (Art.33(5)), e.g. an internal breach
register (or in general processing records, provided all breach info is easily
extractable on SA request) – including cause, what happened, affected data,
effects/consequences, remediation implemented. 2%/€10m fine (and regulatory
orders) possible for not documenting breaches. WP250 recommends recording
reasons for post-breach [“incident”?] decisions, justifications for not
notifying (including why it’s considered unlikely to result in a risk, proof of
meeting any “get-outs”), reasons for delayed notification, proof of
notifications to affected individuals.
·
Breach
notification under other laws
– other requirements may also apply e.g. EIDAS Regulation, NIS Directive,
professional duties and (though not mentioned) financial services regulation.
To conclude, I
believe that, given WP250, in practice organisations will be taking the
approach of “If in doubt, shout it out!” There’s no penalty for crying wolf,
but there is for not notifying when regulators consider you should have.
Will regulators
change their minds if they get “too many” notifications, many of which may be
about only minor breaches? We shall see.
Dr W Kuan Hon, Director, Privacy, Security &
Information, Fieldfisher, licensed under CC-BY
(please link to this article). This article represents Kuan’s personal opinions
and are not necessarily shared by any organisation with whom Kuan may be
associated.
Annex – Other
technical security issues
WP250 could exacerbate
misinformation about security issues, if it remains unchanged. In particular, it
seemingly refers to everything as “breaches”, but it should address incidents
and breaches separately.
Examples are below.
|
WP250 |
Comment |
|
WP250 p.6 outlines · · · |
Permanent loss/destruction, including accidental or unauthorised deletion or, for securely encrypted But clearly, and Accordingly, “or |
|
“Furthermore, it should be noted that although a loss of availability |
DDOS attacks, interfering with authorised users’ availability, are often used as a smokescreen to distract IT/security staff, enabling A DOS/DDOS attack, alone, does not normally affect confidentiality. |
|
“The focus of the notification requirement is to encourage |
It depends on the type of incident. An organisation can “recover” |
|
“WP29 also explained this would similarly be the case if personal |
Hashing involves a “one-way” scrambling of data using an algorithm. It The main exception is keyed hashing of messages (HMAC). But the aim Furthermore, it’s unclear what “similarly” would “be the case” here – |
|
“Consequently, if personal data have been made essentially |
This WP250 sentence confuses the issues. Unauthorised access to data affects confidentiality (not integrity or Encryption address confidentiality, while backups address integrity A breach involving properly encrypted data may not even be a Having backups does not To avoid confusion, this sentence should probably read, “unauthorised |
|
“Furthermore, it should be noted that if there is a breach where |
It depends on the nature of the breach. Sometimes intruders just This WP250 sentence doesn’t specify what kind of incident it envisages, unfortunately. Unauthorised access to securely-encrypted data (with no key access), The reference to “no backups” makes sense only if the breach involved |
|
“A breach that would not require notification to the supervisory |
Again, this confuses confidentiality and integrity. Inaccessibility to an attacker depends on the encryption key If the mobile did not contain the controller’s sole copy of the data, Therefore, the last sentence should instead read, “Provided the |
|
“Identification may be directly or indirectly possible from the |
Why is identifiability considered relevant to availability breaches? |
– “Depending on the circumstances, it may take the controller some time to
establish the extent of the breaches and, rather than notify each breach
individually, the controller instead organises a meaningful notification that represents
several very similar breaches, with
possible different causes. This could lead to notification to the
supervisory authority being delayed by more than 72 hours after the controller
first becomes aware of these breaches.”
Cf. “However, to
avoid being overly burdensome, the controller may be able to submit a “bundled”
notification representing all these breaches, provided that they concern the same type of personal data breached in the
same way, over a relatively short space of time.”
The italicised words
contradict each other – “different” is the opposite of “same”. It should
probably read “possibly similar causes”.
Annex B is meant to
provide “a non-exhaustive list of examples of when a breach may be likely to
result in high risk to individuals and consequently instances when a controller
will have to notify a breach to those affected.” However, most (not all) the
examples in Annex B simply state, “if…”, and/or “…depending…”. This approach seems
circular. Annex B would be more helpful if WP29 explained which situations it thinks
is a “risk” or a “high risk”, rather than referring back to “if”, etc.
Otherwise, Annex B only gives examples of some possible types of incidents or breaches,
without providing guidance on when
notification should be made to SAs and/or individuals. E.g.:
·
Example ii – report “depending… and if the
severity… is high”, and “If the risk is not high…”.
·
Example iv – report to SA “if there are potential
consequences”, report to individuals “depending on the nature…”
·
Example v – “if there is a high risk”, etc. etc.
P.26 “However if it is later compromised” would be clearer
if it read “However if the key is later compromised”.
