Data breach notification requirements: 7 ways the GDPR could ruin your day
The looming EU GDPR requirements around privacy, data breach notification and data protection (along with the equivalent UK legislation that will inevitably mirror EU regulations after Brexit), are causing bow waves through IT delivery, cloud hosting, security, compliance and privacy across organisations of all types and sizes. How bad will a data breach notification actually be?
One of the reasons for this is the size of the fines that could be incurred. The maximum fine for a data breach is €20m or 4% of global turnover which is a large enough figure to get the board of any company to take notice.
There are also requirements around the “right to be forgotten”, the onus on having consent to process data and the potential joint liability between a data owner/controller and a data processor when a breach or failure happens (previously processors weren’t liable, only the controllers, so the effects were often limited by the contracts in place).
Data breach notifications are coming – Be Informed
One of the main talking points, comparing the pre- and post-GDPR world is around the need to notify the authority (in the UK this would be the Information Commissioner’s Office, ICO, www.ico.org.uk) when there is a data loss, breach or other issue.
This requirement is, without a doubt, a big change to the way data and privacy breaches are handled. However, it is not without precedent – in the UK for example telecoms companies have had some breach notification obligations for a while and in the US many states have a law requiring them to inform people whose data they have lost or leaked.
It is worth noting that while the EU regulation will apply directly and should be consistent across the EU (and UK), different authorities in member states may have subtly different policies, objectives and motivations in how enforcement happens.
In any case, while GDPR is not something to panic about, and the rules are intended to be “proportionate” according to the ICO; there are topics that are genuinely worrisome for businesses and security teams.
1. Whether to notify or not
It is not true that all breaches must be notified, instead there is a criteria for notifications to be made. To quote Article 33 you don’t have to notify the authority if:
“the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons”
So there will be cases where the extent of the data, or the nature of the business, or the content involved can be deemed “not risky”. Hence a business could, as now, decide to handle things internally and potentially more quietly should the impacts not be too severe.
One difficulty is that the above criterion is highly subjective. Does a business play safe and report any situation where they might need to, or can they make assumptions that mean they don’t have to – possibly assumptions which might turn out to be incorrect but are still defensible. Would a privacy officer feel that a breach should be notified but be overruled by more senior management who disagree?
Take a dating site – one that aims to find relationship matches for single people; a data breach of users and email addresses might be deemed to be unlikely to cause embarrassment. As a dating site/database of people who want to meet someone, there’s no harm, or shame, or stigma. However, if those names and email addresses include people that turn out to be married (as in the more specific case of Ashley Madison) then suddenly for those individuals you have issues with a higher degree of impact and risk.
The general guidance in any regulatory situation is to be prompt, truthful and complete in reporting issues – so this will be an important decision point in the incident handling process where the right balance must be achieved. The challenge of handling these notifications, if they become overdone, could be onerous and we must be watchful as a society that we don’t suffer from “data breach notification” fatigue.
2. Gone in 72 hours – The data breach notification window
The 72 hour window to send notifications is, by any measure, a tight deadline. See The 72 hour GDPR challenge.
It is unlikely that your local regulator/authority/commissioner is going to expect a fully detailed incident investigation within that time window – but gathering the data, analysing it and forming an opinion as to whether to notify or not is a piece of work in its own right.
The decision as to whether you need to notify the authority and what to say is unlikely to be a decision taken by a front-line security operations analyst who might be able to rapidly decide that an issue should be routed to the firewall team, or to HR, or to the web team. For GDPR data breaches, even with a defined playbook or set of (hopefully objective) criteria, there is going to be a need to discuss and consult based on collected and available information – and quickly!
If we refer once more to the Regulation text:
It is easy to see that while not all of the information might be available within 72 hours to populate your data breach notification, there does need to be some initial awareness, conclusions or possibly educated guesses and likely hypotheses as to:
- The number of people/records affected;
- The type of information involved (does it include passwords, credit card numbers, sensitive personal information, identity verification information);
- The consequences – which will depend on (a) the answer to the above question (b) the motivation of the attacker and (c) the degree of public exposure the information has had;
- Note, the word “likely” has a different meaning to “possible”. The Ashley Madison breach reportedly led to divorces and suicides. If a life is on the line it raises the stakes in any investigation
- What the organisation is doing about it and how it will minimise the effects.
The worrisome nature of the 72 hour figure is not one to underestimate; breach detection and response is typically measured in months, weeks and days – not hours. As such, mobilising the right people and focussing them on questions that relate specifically to the data breach notification as part of the initial incident response is important, particularly when there could be competing priorities like bringing affected systems down, getting restored ones back up, resetting user passwords or answering other less pressing questions such as, “Whose fault this was?” or “Why did you allow this to happen?”.
3. Knowing what to say on data breach notifications
One challenge that forms part of the incident resolution process is finding out what information was actually affected, and hence the people concerned and the scale of risk faced.
In some cases the breach emerges as a result of thousands of names, credit cards numbers and passwords being posted on the web somewhere. This gives you both the breadth and depth of the data loss (in theory) but it isn’t always that straightforward.
Consider a medical insurance database (or generic data set). There will be information on customers, but also most likely former customers. S ome of this will be sensitive (at various levels) and some non-sensitive (effectively already public).
For example, there are different severities for different types of data associated with the people in the database that you will want to ascertain before you make a data breach notification – partly to understand the severity :
4. Monitoring for data protection issues is more involved than you might think
The reality of both the “what happened?” diagnostics process and the “what do we do about it?” response highlights the criticality of information from monitoring of systems, networks, applications and users.
The value of an historical record, for both detection and diagnosis – and having it in an easily accessible, central place – cannot be underestimated. Attackers may obfuscate their attacks by destroying local logs, compromised systems may not be accessible, malware might render systems unusable and insiders may have covered their tracks very effectively.
Additionally, it is not uncommon to find that local systems or specific monitoring technologies may only hold diagnostic or log information for a short period of time before it is rotated out or purged, or they may provide a subset of the network flow and system activity information rather than a full record in its entirety.
A good example of this is a network packet capture solution – the network trace(s) pertaining to an attack might be highly valuable to see what the initial access was, where it came from, what commands or accounts were used, what database queries or attack strings were involved and – crucially – what volume of data left the network or was accessed. Clearly an information source that is of value!
It may be that the network itself is the only source of information on the size or scope of a breach if database query or file access logs can’t give the answers needed. Network session information (even if obfuscated) might give a clue as to the data volumes and hence number of records – in particular if the attack was noticed promptly and the data flow interrupted mid-way through.
If a data file/database compresses at a set ratio of 40% (on average) and there was an intercepted data loss of 8Gb (compressed and encrypted) then you are talking about a 20Gb total data volume. Work back from that with the size of an individual record and there may be an initial estimate of the number of affected subjects or customers.
These calculations all require monitoring of a variety of data sources ahead of time, before and during an attack– otherwise trying to work out what happened afterwards won’t be possible.
5. Notifying the data protection authority AND affected data subjects
As well as notifying the authority itself there is a need to notify affected data subjects “without undue delay”.
Assuming the investigations above have resulted in a list of (potentially) affected people then there is the task of communicating with them and deciding what to say. As data breach notification laws or regulations have been in existence in some sectors and jurisdictions already there are often services available that can be called upon to assist with this.
If the number of people affected reaches into the thousands or millions then this might be the best way to handle the notifications, the questions and any response.
To give a rather ironic example, given their own recent data breach, here are the services one provider offers in this space:
Difficulties abound in handling communications with large numbers of, often upset, people. For instance:
- Emailing them (especially if you want them to reset passwords) can expose customers to phishing attacks;
- Telling all of them they “might have been affected” just in case makes the breach sound much more significant and widespread even if the reality was actually more modest;
- Trying to put information on a web site means that everyone knows the situation, not just your customers;
- Giving people a helpline number to ring risks making you look even less professional if people ring it and find there is no information or (even worse) they can’t get through due to call volumes.
In short, no part of this process is easy. Even if you have actually decided what you are going to say, what advice you are going to give and what promises, discounts, compensation or insurance cover you are prepared to offer.
Feedback from past breaches seems to imply that a breach handling service is one of the better ways to deal with the scale problem – most companies just don’t have a facility to communicate en masse with every customer/data subject at the same time and in a short window.
It also seems to be accepted good advice to tell people that they will be written to or contacted if they were affected with details of what the impacts are, what to do and to be reassured that you will “fix things” – this both slows down the hyperbole, takes the sting out of criticisms of slow response and constrains the burden of dealing with individual questions or angry callers to the switchboard trying to ascertain if their data is part of the affected subset.
The chosen approach needs to be flexible enough to deal with a range of scenarios. It also needs to be accompanied with internal guidance for staff so they know the process and what to say.
6. Social media will be ahead of the data breach notification game.
Social media can work fast, it is also unconstrained by the truth, widely used as a discussion and news channel and likely to operate more noisily and actively than your more measured and cautious diagnostic processes, messaging decisions and PR sign off steps.
Social media is a great medium to communicate with customers or to push out reassuring, apologetic or advisory messages. For a company affected by a breach, while all the investigation and notification is going on internally, the public channels need to be observed as well. The data breach notification to the relevant authority must be accompanied by this more customer/data subject centric message.
Ensuring that sentiments and opinions about the breach are being factored into the communication messages for potentially affected subjects and that failings in call-centre operations that get reported are followed-up and can be responded to, gives you a fighting chance of heading off the negative frustrations.
This might not be required directly by GDPR, but the overall handling of the breach and level of public/media outcry is a facet of the response that you will want to be on top of in parallel with the regulatory requirements. Being slow to notify people when public opinion is racing ahead can only make the handling look ineffectual.
It is likely that the effective use of social media will be one way to justify reductions in fines and mitigate the exposure risks as part of an effective communications strategy. Hence this is a complex dimension of the breach notification process that is crucial to consider.
7. Motivations of attackers: Deliberate data theft or accidental data loss?
Is the breach deliberate or accidental? The answer may well be key to the scale of the problems a breached organisation faces. An attacker who steals information with the aim of making money, or extortion or causing embarrassment might be a completely different prospect to the effects from an accidental leak of data to the public. However, the secondary motives around stolen, lost or misplaced data might only become apparent once it has been posted on-line or flagged as such when further parties gain access to it.
Data captured and hosted on an Internet forum or dark web site might be accessed by a range of people with various motives, or could be used to spawn phishing or social engineering attacks. Additionally, where passwords are involved, and given the frequency of password reuse; there could be other sites and systems that suffer knock-on effects of breaches that happened elsewhere.
A breach caused by a clever, determined, motivated attacker might be easier to explain or justify where effective (but circumvented) risk controls could be demonstrated to have existed. Certainly this scenario is arguably more defensible than sloppy network defences or poorly secure web code allowing a low-sophistication dump of the entire customer database.
The motivations of the attacker and any impacts from stolen credentials, credit card details or medical/sensitive information will depend more on the data content and the ingenuity with which it can be exploited, rather than the skills or motive of the original data thief.
In any of these cases, the data breach notification you make is going to have to present some understanding of both the original attack and the potential future implications. The route of compromise and the likely future impacts will shape the response and, in all likelihood, any fine incurred.
Data protection – Tools for Assessing Your Risk
In this post, we have explained 7 ways in which data breach notification proves challenging.
The reality is that breaches won’t happen (hopefully) too often, but these considerations need to be thought about ahead of time and the necessary processes, training, technology and planning must be undertaken now so that the breach and associated notification process is as risk-free as possible. The requirement for data breach notification and the timescale make for some very different challenges when conducting an incident response.
If you need some reassurance around your level of risk, or if this blog post has convinced you that data breach notifications are a big deal and you need to start justifying some investment, the Huntsman Security GDPR Risk Tool is worth using to get some answers as to the possible size of the problem you might face when you lose some data, get hacked or suffer from an insider threat and are trying to pull your first data breach notification together. It is free to download from the link below.