[GDPR] What to do in a breach

When it all goes wrong.

Since the introduction of GDPR enforcement into law this year (2018) the ICO has seen a massive increase (between May 25th and July 3rd 2018 they reported a 160 per cent rise alone compared to the same period in 2017) in the number of potential data breaches reported.

This shouldn’t be a surprise as prior to GDPR it was optional to report such events but for the first time with the legal obligation, we can finally start to see an idea of how many organisations out there fall victim. 

It’s also interesting to see the development of what people think when considering what is a data breach from just a year ago to today, for years certainly in the organisations I’ve worked it’s been a cybersecurity threat, the idea that the only way they could be breached was for a malicious hacking attempt and the risk considered was very low. 

Now when I ask people and there’s worry with risk identified ranging from emails address books, physical location security, reducing the amount of printed material, marketing the wrong person to which suppliers we can deal with and them as a supplier and the agreements they’ve had to sign. 

To me this change in thinking is obvious, people are now looking away from someone outside the company is the cause to internal and human error from staff (be it anything from the wrong interpretation on the law to accidentally disclosing information).

I feel as a DPO is that you shouldn’t go into this thinking that you can prevent a data protection breach or a near miss (where only luck prevented a breach). To do so would mean perfection that doesn’t exist, Everything about GDPR is risk assessment and mitigation, you put in steps that reduce the risk as much as possible, you cannot control the human element even with some fairly advanced training so risk will always exist that you need to be ready to deal with.

With that in mind, A big part of mitigating the risk is making sure you have a policy and plan that is understood throughout your company that takes place when there is a suspected breach, you also need to foster an environment where there isn’t any fear in reporting a problem, even providing anonymous or whistleblowing support protection if needed. It’s much better to have the issue with lost time from solving a problem that turns out to be fine than to be blindsided by an issue that has snowballed that could potentially end your business.

Data breach procedure

Start with the obvious – How do people report a possible breach to the organisation? 

It’s important to have a clear route to report for both third-parties such as your customers, partners, suppliers to report, be it through a clearly signposted form on your website, a listed email address or a phone number. For your staff you need to make sure the data protection officer in your business is an approachable, accessible and trusted person, you need to support them to make sure that the team know to report any risks, worries or questions to them and empower them to find ways of gathering that information anonymously if needed – While it’s important to find out how and why something happened don’t ever confuse this with the blame game. The blame game encourages distrust, slows down reporting or investigation and itself can cause breaches as people avoid asking the questions needed.

You need to be the boy scout.

Being prepared doesn’t need to be a secret war room with screens and a snap folder full of through plans labelled A to Z, with five die-hard members of your team ready to jump in front of the bullet. Don’t get me wrong that sounds like it could be fun and certainly do a lot should one of those particular events occur but it’s not where I would start. 

Create a generic overview of what should happen as soon as you’re aware of a potential breach.

Look at your business and write your policy; 

Who is leading the response?

It’s all well and true telling everyone and ringing the local church bells only for confusion and misdirection to follow. You need someone to lead and control and more often than not if you have a Data Protection Officer this needs to be them, It doesn’t matter how much other heads of department want to step in, you need to make sure that your name data crisis manager is known by all and respected and that even you allow them to run without influence.

What should the first actions of your leader be? 

Start with a damage assessment, and by damage, I don’t mean how is your company being externally perceived, that’s one for your marketing or communications team. For your crisis manager (or in our case the DPO) This early in the process your first thought shouldn’t be that you need to tell those affected instead you need to get everyone involved in understanding and fixing the breach into a room, you need to make sure you have relevant experts and the support around you to find out if a breach actually has taken place, perhaps its a near miss or even a false alarm. Even if you expect it to be a false alarm, make sure you put in the time, it’s important for you and your team to be seen as the beacon of doing things right, once things start to slip you start to increase the change of next time being all too real.

Your initial thoughts need to be around what has actually happened, don’t get distracted and make sure you get clear and honest answers from your team. Reassure them, now is not the time to worry or panic but it always isn’t the time to relax, so make sure you keep things moving. 

This process must start almost immediately after you’re notified there’s a breach, the law only gives you 72 hours to notify the ICO if you believe there has been a breach, and the ICO requires more than a one-line FYI, you’ll need to give them as many confirmed facts and fixes as possible. The best way of making sure you have this is to have a spreadsheet already laid out full of the basics (It’s important that you record as much detail as possible, be in in a spreadsheet or just on a notepad), the hows, whys, whens, the risk to personal data involved, and the plan you’re going to or have put in place to minimise that risk.

With regard to a spreadsheet or best note-taking, We use an edited version of the template provided by the ICO broken up into two sections – Details of the breach and measures taken / to be taken

  • Detail of breach
    • Client Affected
    • Date of Breach
    • Data Breach Discovered
    • Support Ticket or Supporting Document if needed (e.g. additional notes)
    • No. of people affected
    • Nature of breach (pick most relevant)
      • Unauthorised Access
      • Disclosed in error
      • Lost Data/Hardware
      • Lost in transit
      • Non-secure disposal
      • Stolen Data/Hardware
      • Technical/procedural failure
      • Other
      • N/A
    • Description of breach
    • How you became aware of the breach
    • Description of data
    • Does this data include any special categories data (Yes/No)
  • Consequences of breach
  • Measures taken/to be taken
    • All individuals informed
    • Remedial action
    • Other regulators informed
    • Does the ICO need to be notified, if yes what is the date of notification?

Ahead of time, you should also already have a document laying out what you classify as low risk and high risk. With a selection of clear examples (even if these examples are generic). 

For example, two examples the ICO gives around volume and the risk of individuals suffering from harm are;

  • loss of an unencrypted laptop holding names, addresses, dates of birth and National Insurance numbers of 100 individuals would be reportable 
  • loss of a marketing list of 100 names and addresses (or other contact details) where there is no particular sensitivity of the service being marketed would not be reportable 

It’s important to have these examples as just because you have/had a clear head and a good understanding now or when putting together your response plan doesn’t mean you will when you’re investigating, it also means that you can quickly pass these definitions on for someone else in your team to find out and report back to you. 

At the end of this first phase which in reality shouldn’t take more than an hour and could well be summarised within a few minutes if your team or the initial report has all the facts, you should know one thing with certainty and the start of many more things in the rough. 

Have you had a confirmed data breach as defined under the GDPR? 

Yes or No.

If you haven’t then it’s important to remember you have a duty of confidentiality with your staff, partners, suppliers and customers which might have been breached with non-personal data and require it’s own non-GDPR response.

If you have then the journey’s just started. 

What next?

This is where Consequences of the action and ‘the measures to be taken/have been taken’ section of the spreadsheet in phase one. You know there has been a breach, you have a good idea why. Now you need to put into place a plan, or action that would prevent the same or similar breach occurring in the future. 

For us as software developers and marketers, it’s highly likely that any breach with us will be digital, more so again it’s likely that given our software powers hundreds of websites and that we act as the processor for those companies that the breach will again likely favour a breach of this. 

This means that it’s highly likely that the action required for us will revolve around two aspects, either a breach through software insecurity or human error caused by not following the procedure which in turn is most likely to cause software insecurity. So for us, the remedial action to fix the breach will revolve around a tested emergency software patch released and a full review of the procedure including staff training.

You need to have a fair idea of what your most likely breaches will be at a generic level so when the time comes you already have a fair idea as we need the process you’ll need to follow. 

Once you feel the data breach is contained and your data secure again, and no longer an active problem you can move onto recovery. Remember there is no bringing back data that has been exposed to the world, be that through code or by leaving unsecured data on a train, so your containment should really be around a plan to help protect those whose data was breached and putting in steps to prevent it from happening again.

Dependent on the level of breach you had and the time needed to investigate this phase could very easily last an hour or several days as investigations continue, a full understanding of the detail of the loss and cause is found and the suggested fixes and implementation of fixes come forward.

Time to tell.

Your DPO and their appointed team during the investigation will now need to decide whether to notify:

  1. affected data controllers; 

It’s important to remember if your business like ours as a digital agency developing websites and digital campaigns is on behalf of other companies using their data then you need to define if you believe the breach was big enough to warrant informing them. In an open and honest partnership, this should always be the case however small the breach.

  1. affected data subjects
    If your deal directly with the end customer and you believe the breach has a risk to their personal data freedoms, risk from identity fraud and the loss of the data will cause them stress then you need to contact your data subjects. If you go through another data controller first then you need to leave this part to that data controller but it’s important you work with them to help them put together their response. 
  2. the police;
    Does your breach have any criminal or malicious intent aspects? Even for scenarios, you feel you can’t chase any further, be it an employee or a third party you should inform the police to cover all basis. If you believe the breach of the data may well have a strong risk to the welfare/wellbeing such as a risk to the life of someone then this is another reason to contact the police. If you’re unsure then dial 101 (non-emergency number)
  3. the ICO; 

The important thing to remember is that not every breach needs to be reported to the ICO, but every breach must be recorded in your logs should the ICO wish to investigate further.