Data breach notifications by the numbers: Hard facts for your business case
There is an entire industry springing up around the EU General Data Protection Regulation and the requirement for data breach notifications. It is really not necessary to search hard to find a law firm, consultancy, product vendor or service provider who can help you solve the many faceted problems that the GPDR presents or assist you in formulating your data breach notification process – there are also no shortage of marketing teams only too willing to explain how they can help and what their solutions offer.
The reality is that as a compliance requirement there are two sides to the changes that are necessary under GDPR – things you want to do and things you have to do.
The Wants and Musts of GDPR Compliance
- WANTS: Those elements that can be turned into a viable business benefit or opportunity; for example the creation of a privacy culture and a fair use approach that wins the hearts and minds of customers and prospects or enable the business to perform better in some way.
- MUSTS: The things that are driven purely by compliance itself and hence derive a business case based on mandatory need with little further justification or value proposition.
Data Protection: The business case driver
Compliance drivers around data protection and privacy are a potentially rich area for the definition of business cases that provide all sorts of advantages to a forward-looking and entrepreneurial security function. It’s commonly recognised that good information security starts with good asset and information management – however, the reality of knowing what information you have, where it is held, who has access to it and when it might have been lost or gone astray are some of the harder problems that security managers have to deal with.
Under GDPR there is scope for greater interaction between the security function, the general counsel or internal legal/compliance team and the business to meet the compliance drivers with robust processes, intelligent technology and educated people like never before.
Below we identify some of the hard numbers and facts that can be used to derive these business cases.
Data breach notifications
From the ICO itself the figures around breach notifications for notifiable breaches (where there is a risk to individuals) are clear:
“A notifiable breach has to be reported to the relevant supervisory authority within 72 hours of the organisation becoming aware of it. The GDPR recognises that it will often be impossible to investigate a breach fully within that time-period and allows you to provide information in phases.
If the breach is sufficiently serious to warrant notification to the public, the organisation responsible must do so without undue delay.
Failing to notify a breach when required to do so can result in a significant fine up to 10 million Euros or 2 per cent of your global turnover.”
This encapsulates three of the main figures that are driving the GDPR industry; namely:
- Breaches must be reported within 72 hours
- The fines for failing to report can be up to EUR 10m
- Or they can be 2% of global turnover
In any business, fines of that nature are significant; even if the seriousness or mitigating circumstance mean that a maximum fine is not imposed. There is every reason to believe that fines will be significant – regulators have a duty to make them a deterrent – so a light-touch compliance regime is an unlikely outcome.
It is worth noting that not all breaches have to be notified to the regulator. However, the ones that don’t are likely to be ones that could be easily managed with limited impact anyway. As ever, the small number of tricky issues cause the majority of the problems.
We will return to the 72 hour window later in the blog, but first…
Fines for data breaches
To add to the above three figures on breach notifications is the really big ticket item in GDPR – the fines for data breaches themselves. This is almost the factoid that broke the Internet (as much as data privacy news ever could):
- The fines for certain breaches can be up to EUR 20m
- Or they can be 4% of global turnover
Clearly the maximum fines would be likely only in cases where the level of negligence and carelessness was extreme and the response was equally as inept. However, taking even modest estimates for the impacts on the larger companies within the FTSE should a major breach occur then you are looking at big numbers.
The 4% is of global turnover rather than profit. So in small margin industries where profits are, say 10-20% of turnover the 4% figure is a major, and market affecting, penalty to suffer.
How bad will data protection and breach fines actually be?
Will fines for breaches be as bad as predicted? It is an interesting question.
As noted above, regulators need to ensure fines provide a deterrent. However, where national interests might have come to the fore in the past, in the future this could be quite different.
The regulator (across the range of EU counties) that looks into and prosecutes a particular breach might not be the one in the country where the company is based or where the breach happens.
This is particularly true if citizens from other nations are affected or if one of the EU countries authorities has a particular interest. For example, a German Data Protection authority with particular expertise in financial sector breaches might end up investigating a data loss from a Spanish bank – and in this case might be less likely to tread softly and under be pressure from lobbying when deciding the fines.
In magnitude terms, and looking at the UK market only, Government figures (https://www.gov.uk/government/statistics/analysis-of-the-distribution-of-private-sector-enterprises-by-turnover) show that there are 365 companies with a turnover of over £1bn. Only one of these has to suffer a serious breach for a fine of £40m to be realised.
To put that into perspective fines last year in the UK totalled £880k (as reported in https://www.theregister.co.uk/2017/04/28/ico_fines_post_gdpr_analysis/) and would have potentially leapt to £79m under GDPR, but these figures are based on the same cases being reported under the new fine structure – breach notifications becoming mandatory is likely to lead to further additional reports. Hence even a small number of average sized GDPR fines will radically shift the economics of data protection enforcement.
Gone in 72 hours: The window for data breach notifications
As we alluded to above, one of the really significant numbers in GDPR is the 72 hour timescale for data breach notifications. To quote the regulation:
“… the controller should notify the personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the controller is able to demonstrate … that the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.”
There is a further demand that subjects themselves are notified “without delay”. Certainly there is a critical, and widely accepted, expectation that the report or notification made contains a reasonable understanding of what happened and the scale of effects.
Compare the handling of past breaches (e.g. Talktalk) where the initial information has been uncertain, incomplete and unclear – the coverage has been hugely negative in the press; with missing figures being replaced with guesses or worst cases (Talktalk weren’t able to say how many of their customer were affected, the press simply assumed it was all of them – some 4 million – it turned out to be 150,000 and only 15,000 where financial information was compromised).
72 hours is not a long time window
Now add the regulatory pressure to this and 72 hours doesn’t seem very long at all. It’s the amount of time contained within a bank holiday weekend or the duration of the annual UK Infosec Europe trade show for example.
The looming 72 hour deadline means that finding out what data was affected, how many people were involved, what fields or information were accessed, how much risk the individuals are facing, where the data has gone, how long the breach was in progress before it was detected (hopefully not too long), all become a set of facts that need to be established quickly and with certainty.
Arguably, assuming the worst and telling all your customers that they may have been affected by a breach when they haven’t is as bad as trying to reassure them they haven’t been affected when they actually have. Or even worse, simply saying ”we don’t know at this stage”.
How to spend your 72-hours
Time is going to be of the essence, and getting certainty quickly the priority. The table below details recommendations of things you do and don’t want to be doing in those 72 hours when the data breach notification clock is ticking.
|DO WANT TO BE DOING||DON’T WANT TO BE DOING|
|Retrieving query and data access records from databases and the network to find the number of records, the volume of data and the actual content of the breach.||Working out where you can get information from in the absence of database, systems or network logs.|
|Confirming the sensitivity of data quickly so an effective response plan can be put into action.||Trying to reverse engineer the data content exposure from an encrypted file transfer – possibly by dividing the size by the database record length, then accounting for compression (then realising that is basically guess work).|
|Invoking the pre-prepared and established process to communicate to customers/data subjects.||Trying to work out a way to contact 150,000 people quickly by email (which risks phishing) or phone, letter, the web site (which is down), social media (which is already awash with information – and not from you).|
|Saying “We are dealing with a breach and will be contacting all affected users directly… we apologise and are urgently working to put things right, you are not at risk of loss/theft/etc”.||Saying “We are not aware of any problems but have taken our website off-line while we investigate an issue” or “We don’t know”.|
|Calling in your incident response team/service provider under the retainer that is set up.||Googling “security incident investigators” – then trying to get them to come in tomorrow without a PO.|
Then trying to get a PO raised through procurement for an initial £100,000 when they say they won’t.
|Telling the regulator all the information (numbers, data, volumes, fields) and actions (notifications, investigations, communications) taken.||Telling the regulator there has been a breach and you are working on it, but will definitely be able to update them if they can wait a bit longer, you just aren’t quite sure how long.|
The 72-hour window for data breach notifications doesn’t need to be a full and final report of a completely investigated and resolved event, as that could take time to compile. However, once a breach is detected, the clock is ticking and stressed security teams will rapidly reach the point where a data breach notification and an initial level of defensible understanding is a necessity.
Typically cyber security incidents get detected in 146 days
The length of time it takes for a breach to be detected is a statistic that is becoming widely reported in the cyber security community. While different reports contain different figures (146 days comes from FireEye) they all say the same thing:
IT TAKES FAR TOO LONG
Even if the real figure was a tenth of the above estimate, or any of the equivalent figures from Verizon, Ponemon etc., it would be too long.
If we shave off a whole month, it is still far too long. If we double the team size and the technology budget and halve the detection window, it is still too long. You get the idea – the data breach notification window is tighter than any of those improved response times.
A data breach notification is a challenge that spans people, process and technology. Gathering data, analysing it, collating that which is relevant, archiving that which isn’t, presenting a clear picture to the security team is equally important as having good processes that work both under normal operational times and in times of incident or crisis, as well as having people with the right skills, training and knowledge to be able to understand the threats and work with the technology to escalate, resolve, contain, mitigate, remediate or recover.
Being number 1 at data breach detection and notification
This figure is an easy one to explain. There are all sorts of ways a breach can come to light. It can be through customers noticing strange behaviours, through fraudulent payments, through a publication of the stolen data on a public web site, through social media, a news story, a piece of third-party research, a whistle blower, or through anomalous network traffic, a web site outage, alerts generated via an IDS sensor or network security device, or application activity indicating retrieval of large volumes of records or data.
However, in whatever order these signs emerge you need, as a company, to be first to detect them. Number One.
See the Huntsman white paper on security analytics for more information on detecting security breaches:
If someone else spots the breach, or publicises it before you notice, or gets on the phone asking for a statement from the chief executive; it is hard to claim that your detective security controls were up to the job of monitoring your networks and systems. If there is going to be a problem, you want to be detecting it before anyone else does and have your data breach notification process underway.
With Data Breach there are 2 types of firms
Those who have had a data breach and;
Those who haven’t noticed.
Then, there are those who have had a breach in the past and learnt from it, and those who haven’t had one yet, but will have one in the future at some point.
These are rather depressing assumptions but widely accepted as being accurate. In either case – the absence of a breach thus far gives no indication that one isn’t possible, or even likely – and while having had a past breach to learn from should make the next resolution process slicker, the fact that you’ve been hit again will worsen the negative attention.
Conclusion: Data breach notifications are not the only driver
The figures that support security investment cases are complex and varied. There is a great deal in GDPR around the process, notification and response requirements as well as the timelines for data notification and the fines when there are breaches or administrative failures.
There are also wider industry figures around the delays in detection, the time to respond or the different categories of company, or sector and breach likelihood.
For additional data points the recent Forrester Research report draws together costs for many of the breach support services you might need to consider. This could be call-centres, complaint handling services, customer breach notification services, forensic investigators or other types of assistance. See:
However, for the time being, and certainly in the EU (and UK pre- and post-Brexit), the 72 hour window to notify the regulator and the sizes of fines in raw size (up to EUR 20m) or as percentage of turnover (up to 4%) seem to be the most prominent and attention grabbing numbers.