The document discusses data breaches and relevant laws. It notes an increasing number of data breaches and introduces key laws around data security - the GDPR and NISD. The GDPR requires organizations to implement appropriate security measures to protect personal data and report breaches. It applies broadly to any group processing EU citizens' data or offering goods/services to them. The NISD focuses on essential services and digital service providers, requiring security and reporting of significant incidents. Non-compliance can result in large fines and litigation. Proper precautions such as response planning and legal advice are recommended.

1. Data breaches and the law
A practical guide
Georgie Collins and Dan Hedley, Irwin Mitchell LLP

2. Background
• Incidence of data breaches appears to be increasing
• UK ICO reported 19% increase between Q2 and Q3 (Q4 stats coming)
• British govt annual “Cyber Security Breaches Survey” 2018 show up to 4 in 10
businesses suffering some kind of breach or attack in the 12 months leading up to April
2018
• Roughly 20 million personal records leaked in March 2018 alone
• Including the employees of the Dutch Data Protection Authority!
• Troy Hunt’s “Have I Been Pwned” has a database of 1.7 billion compromised
usernames across hundreds of sites
• OSS vulnerabilities often play a significant role
• Apache Struts (Equifax), OpenSSH (Heartbleed), Exim (CVE-2018-6789)

3. Who it applies to What it applies to
GDPR Anyone with establishment in EU
Anyone offering goods or services to
people in EU
Anyone monitoring the behaviour of
people in the EU
“Personal data” i.e. information relating
in some way to identifiable living
people
NISD “Operators of essential services”
“Digital Service Providers”
All network and information systems
Why this matters – the law
Preventing and reporting security breaches been mandatory for a while in some sectors, but two new laws apply
much more widely

4. • “Personal data” must be kept secure
• Breaches of security must be reported
• Extra-territorial effect
• Applies directly to data processors too
• Pushed through supply chain contractually
GDPR, security and breach reporting

5. “personal data” = “any information relating to an identified or identifiable natural person
(‘data subject’); an identifiable natural person is one who can be identified, directly or
indirectly, in particular by reference to an identifier such as a name, an identification
number, location data, an online identifier or to one or more factors specific to the physical,
physiological, genetic, mental, economic, cultural or social identity of that natural person”
• NOT the same thing as “PII” – PII is a subset of personal data
• Includes pseudonymised data like info associated with retargeting cookies
• Includes e.g. Windows 10 telemetry, IMEI number of mobile phone, IP addresses
(sometimes)
GDPR – what we mean by “personal data”

6. • Applies if processing takes place in the context of the activities of an
establishment in a member state (regardless of data or data subject
location).
• ALSO applies if NO establishment in a member state BUT:
• Offering goods or services to data subjects located in member states
(no payment required)
• Monitoring behaviour of data subjects in member states
• Applies directly to processor too
• Subset of controller obligations, incl. security and breach reporting
GDPR – who it applies to

7. The principle:
• “Personal data shall 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”
The detail is in article 32 (next slides)
GDPR – security obligation

8. Article 32:
1. 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, including inter alia as appropriate:
(a) the pseudonymisation and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
(c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or
technical incident;
(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for
ensuring the security of the processing.
2. In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by
processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to
personal data transmitted, stored or otherwise processed.
GDPR – security obligation

9. ICO “Checklist” for article 32:
GDPR – security obligation
We undertake an analysis of the risks presented by our processing, and use this to
assess the appropriate level of security we need to put in place.
When deciding what measures to implement, we take account of the state of the art
and costs of implementation.
We have an information security policy (or equivalent) and take steps to make sure the
policy is implemented.
Where necessary, we have additional policies and ensure that controls are in place to
enforce them.
We make sure that we regularly review our information security policies and measures
and, where necessary, improve them.
We have put in place basic technical controls such as those specified by established
frameworks like Cyber Essentials.
We understand that we may also need to put other technical measures in place
depending on our circumstances and the type of personal data we process.
We use encryption and/or pseudonymisation where it is appropriate to do so.
We understand the requirements of confidentiality, integrity and availability for the
personal data we process.
We make sure that we can restore access to personal data in the event of any incidents,
such as by establishing an appropriate backup process.
We conduct regular testing and reviews of our measures to ensure they remain
effective, and act on the results of those tests where they highlight areas for
improvement.
Where appropriate, we implement measures that adhere to an approved code of
conduct or certification mechanism.
We ensure that any data processor we use also implements appropriate technical and
organisational measures.

10. • From 2014 guidance published by the ICO, the UK data privacy regulator (emphasis added):
“It is ... important that any software you use to process personal data is subject to an appropriate security
updates policy ... you must also ensure that no relevant components are ignored. This is a common risk
where responsibility for updates is split between multiple people, or where third-party libraries or
frameworks are used.”
• The UK ICO at least has fined people specifically for failure to do this.
• E.g. Gloucester City Council, Equifax (ongoing)
• & under GDPR, fines potentially get much much bigger …
• Reminder: 67% of applications scanned by Black Duck in 2016 contained unpatched OSS vulnerabilities.
GDPR – security and patch management

11. • Controller – to regulator UNLESS unlikely to result in a risk to rights and freedoms
• 72 hours unless not “feasible” (basically, have a v good reason)
• Time runs from “awareness” that a breach has occurred “with a reasonable degree of certainty
• WP29 guidance – controller’s time runs from when processor tells it
• Processor – to controller
• Without undue delay – means “as soon as possible”
• Controller – to data subjects IF high risk to rights and freedoms
• Without undue delay
• This is “going public” – not always required but requires careful planning
• Information to be provided to regulator includes
• Nature of the breach (i.e. how it happened, who affected etc.)
• Likely consequences of the breach
• Mitigation and remediation measures
GDPR – breach response

12. • From a security perspective, covers a lot of the same ground
• BUT it applies based on activities and characteristics of ENTITY, not characteristics of
affected DATA
• “Operators of Essential Services”
• “Digital Service Providers”
• If GDPR-compliant, prob. most of the way there BUT devil is in the detail esp. notification
requirements
• Micro and small business exception for digital service providers
• Additional regulators – to be determined by member states
• OES – by sector
• DSPs - ICO
NISD – What does it add to GDPR?

13. • By sector and threshold
• Sectors and entity types specified in the directive – energy, transport, banking and finance, healthcare, water, digital
infrastructure (TLD registries, DNS providers, IXPs)
• Importance thresholds left to individual member states
• If you’re not designated, doesn’t apply
• But not limited to own systems, DSPs services OESs also caught & guidance is that OESs should push through their supply
chain more generally
• Security – outcome-based, similar to GDPR language
• “appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network
and information systems which they use in their operations”
• “appropriate measures to prevent and minimise the impact of incidents affecting the security of the network and
information systems used for the provision of such essential services”
• Govts issuing guidance e.g. the “14 principles” in the UK – draft published as annex to NIS implementation consultation
response.
• Reporting of incidents – “without undue delay” for incidents “having a significant impact on the continuity of essential services”
• Expectation is that sector regulators will issue guidance on reporting thresholds
Operators of essential services

14. • Not brilliantly defined in the directive!
• “Online marketplace”
• “a digital service that allows consumers and/or traders … to conclude online sales or
service contracts … that uses computing services provided by the online marketplace”
• “Online search engine”
• “a digital service that allows users to perform searches of, in principle, all websites or
websites in a particular language on the basis of a query on any subject … and returns
links in which … related … content can be found
• “Cloud computing service”
• “a digital service that enables access to a scalable and elastic pool of shareable computing
resources”
Digital service providers - definitions

15. • Security again similar to GDPR
• “identify and take appropriate and proportionate technical and organisational measures to
manage the risks posed to the security of network and information systems which they use in the
context of offering [digital services as defined previously]”
• Must take into account security of systems and facilities, incident handling, BCDR, monitoring,
auditing and testing, and “compliance with international standards” (ISO27001?)
• “measures to prevent and minimise the impact of incidents affecting the security of their network
and information systems on the [digital services as defined previously] offered within the Union,
with a view to ensuring continuity of those services”
• Must notify competent authority “without undue delay” of “any incident having a substantial impact on
the provision of [their service]”
• There is a draft implementing act kicking around the Commission giving more detail
Digital service providers – security and incident notification

16. • Legislation is technology neutral
• OSS is not a special case and is not treated differently
• Regulators don’t care whether you got pwned because of a vuln in your £multi-
million SAP application, or in some random free MIT-licensed library.
• Compliance is self-assessed at the time, retrospectively re-assessed by regulators post
breach
• They will ask: Was the vuln known? Was a patch available? Should you have patched it?
Why didn’t you?
• It is for the breached party to show that its security was compliant
• “My vendor screwed up!” / “But it was free!” will not fly
• Unlikely that 3P vendors will take much if any liability for OSS
Relevance to OSS management

17. How does it get into org:
• From vendor, due diligence and ongoing dialog as to patch and
security management
• Contractual? Sometimes. Starting to see in regulated industries e.g. finance
• Clarity as to who is responsible for what is key
• Patching reporting and SLA?
• COOPERATION ON BREACH
• From own code base, check-in processes and scanning tools
• Other sessions covering this in some detail!
Relevance to OSS management

18. UK ICO
• Largest fines - Talk Talk fined £400,000 & £100,000, Carphone Warehouse £400,000
• Marketing campaigns and cold calling low level fines
• Imposition of undertakings eg WhatsApp
• Uber investigation
France DPA (CNIL)
• WhatsApp investigation
• Facebook Inc and Facebook Ireland fine €150,000
Netherlands DPA
• Airbnb ceased processing BSN’s (unique numbers used to identify individuals).
Approach of EU authorities to Data Breach

19. Right to claim compensation
GDPR makes it considerably easier for individuals to bring private claims against data controllers and
processors. In particular:
• any person who has suffered "material or non-material damage" as a result of a breach of GDPR has the
right to receive compensation (Article 82(1)) from the controller or processor. The inclusion of “non-
material” damage means that individuals will be able to claim compensation for distress and hurt feelings
even where they are not able to prove financial loss.
• data subjects have the right to mandate a consumer protection body to exercise rights and bring claims on
their behalf (Article 80). Although this falls someway short of a US style class action right, it certainly
increases the risk of group privacy claims against consumer businesses. Employee group actions are also
more likely under GDPR.
Individuals also enjoy the right to lodge a complaint with a supervisory authority (Article 77).
The new landscape

20. • Potential for very large fines, maximums assessed by turnover, get used to fines in the
millions not thousands
• NB turnover of “undertaking” - in EU law tends to mean an economic unit, not legal
person, so potential for measurement by reference to whole group
• The importance of mitigation
• Consider how Equifax and Uber would be dealt with under GDPR
• Reputational damage and impact on share price (e.g. Equifax, Uber, TalkTalk)
• Class actions by data subjects and shareholders (e.g. Morrisons and Cambridge
Analytica)
• Prospect of class actions led by charities and campaign groups
• Regulatory intervention (e.g. Cambridge Analytica)
The GDPR litigation landscape

21. • Regulated industries - sanctions and enforcement
• Negligence claims – against organisation and/or individuals
• Liability of Directors – breach of duties
• Vicarious liability of organisations for acts of employees
• Breach of contract
• Breach of confidence
Other legal risks arising from a data breach

22. The old adage: “It’s not a question of ‘if’ but ‘when’. Bad things happen.
• Revisit Article 32
• Anticipate worst case scenario, not a mildly inconvenient scenario
• Breach response plan: review, test and repeat (again and again)
• The importance of appointing external advisors now not when you are up against a
72 hour breach notification deadline
• Make legal privilege and confidentiality part of your plan (including with advisors);
keep an inner circle
• Prepare standard notifications and comms (internal and external) to adapt to an
incident
Being ready for a breach and its aftermath

23. Georgie Collins
+44 (0) 207 421 3997
georgie.collins@irwinmitchell.com
Dan Hedley
+44 (0) 1293 742 717
daniel.hedley@irwinmitchell.com