Incident management in the GDPR world
The GDPR’s 72 hour mandatory Breach Notification places new restrictions or requirements on how an incident should be managed and reported. The 72 hours deadline for the first time puts a timer on incident management and especially those that result in an actual breach of personal data. From working with many major organisations, helping to produce, test, embed and deal with cybersecurity incidents, I know the 72 hour breach notification will be a shocking surprise. Many find it difficult to differentiate between a security event and an incident when to escalate who to escalate to, how to communicate, what to communicate. A breach invariably is a crisis-inducing event, the last thing you would want to do is to work out all the above in the midst of a major incident.
In my co-authored book Cyber Resilience Best Practices for AXELOS, I talked about the fact that it is no longer good enough to prevent incidents; organisations must also be prepared to be resilient to them. Incidents and breaches are inevitable fact of digital business.
This is why you should plan ahead and build your incident management strategy, plan and processes and be prepared for the inevitable breach.
GDPR 72 Hours Breach Notification
The 72 hours mandatory breach reporting for Data controllers is going to be challenging for many organisations. Whereas, Controllers have up to 72 hours to report the breach, Processors, must inform the Controller, without undue delay.
With the recent spate of late reporting, some up to four years late and involving millions of records. Organisations are still getting it wrong. How will companies cope with being transparent and reporting within 72 hours or even without undue delay within those 72 hours, they will have to investigate, resolve and come up with a tactical communications plan for affected data subjects and the Supervisory Authority. Seventy-two hours is not much but it cannot be used as an excuse to stop the notification. GDPR allows for a delay but this will have to be justified. An example I can think of is where law enforcement has advised you not to disclose the information to anyone, including the Supervisory Authority.
You will need to make an important decision between reporting an incident and also investigating and recovering. Not reporting a breach is no longer an option and a failure is likely to bring down the wrath of the Supervisory Authority (ICO in the UK) and the offended consumers themselves and thus affecting the very same reputation that organisations obfuscate to protect.
When is a breach not a breach?
Well, when it does not endanger the data subject’s privacy. Before reporting a breach organisations will want to be absolutely clear that:
- It is an actual breach of personal data.
- The data was not encrypted
- The data was not otherwise protected – e.g. pseudonymised or anonymised etc.
- The breach would result in a high risk for the rights and freedoms of natural persons.
Only then you have to report the breach to the Supervisory Authority.
Okay, now that we have established what and when a breach needs to be reported. Lets look at what preparation is needed to be able to answer the above questions and what to do if there’s a reportable personal data breach.
Well, to begin with, you need to be able identify, record, escalate and report a breach. All these steps point to a tried and tested incident management plan and a process that includes personal data breach notification.
Incident management plan and process
Here is an opportunity to revisit your incident management plan and process to make them fit for purpose. If you don’t have one then write, test and communicate an incident management plan. Ensure your Processors have done the same and are able to identify and report to you (the Controller) without delay as required by the GDPR in order for you to be able to meet your 72 hour reporting obligations.
If you have a plan, then you most probably will need to update:
- the timers and trigger escalation points to include the DPO and the Data Controller.
- the reporting to include the Supervisory Authority and the Data Subject
You will need to train people to communicate and seek advice where and when they need to. You will need to communicate but also negotiate with the Supervisory Authority on what information about the breach you can and should release. You need to hold on to certain information because 72 hours may not be sufficient time to close down complex incident. The incident could still be active and under investigation, therefore, you have to still consider what information you can release. Seek advice from the Supervisory Authority, be transparent with them. They are not here to just take your 4% global turnover away. They are more likely to be amenable if you are open and transparent with them.
So when does the Breach Notification clock start?
The clock starts from the point you have declared it as a personal data breach. Therefore, it is essential that you make the correct call and keep to the timings.
We have a breach, what do we do now?
Once a breach has been identified for sure, the clock will start ticking. You will want to document this point and the rationale behind declaring it as a personal data breach. This is where you would want to put your breach notification action plan into action. Starting with escalating to your:
- Data Controller,
- Processor (if involved),
- The DPO,
- Head of Legal
- Communications and PR department
A good communication plan is essential to control the fall-out. Oh, please don’t put your hapless CEO in front of the camera with an old CRT monitor in the background, even if it doesn’t belong to you! More later on this.
You will need to keep a record of each step of your incident investigation. Documented and time-stamped so that it can be produced as evidence if required. When a decision has been made that the incident has resulted in personal data breach you need to be prepared to notify the Supervisory Authority if required.
How do you meet the 72 hours notice?
The way I design processes is to walk back from the Notification point to the breach identification point, allocating time-slots to each action that needs to be carried out and the elapsed time.
In these intervening 72 hours you should:
- Identify your escalation points and inform all your internal escalation points.
- Update your documentation, plans, templates, press release etc.
- Recover from the incident and put in mitigations.
- Prepare or refine a short-term communication plan for media, Supervisory Authority and the Data Subjects.
If possible a medium and long-term plan to deal with any queries, action plan for dealing with the aftermath of the breach, designed based on the type, nature and impact of the breach. The plans should have input from Legal, Communications, DPO, Cyber Security, Data Controller and if any Data Processors involved in the breach.
Plan to inform the Data Subject
You will of course not only need to inform the Supervisory Authority but according to Article 34 also the Data Subjects “without undue delay”, unless the Supervisory Authority is convinced that the data was adequately protected, e.g. encrypted. Other extenuating circumstances such as if there are large number of subjects impacted may provide a reason not to inform the subjects.
You may have noticed a slight contradiction here as Article 33 states you do not have to report to the Supervisory Authority if the data was encrypted, here Article 34 is saying you have to convince the Supervisory Authority if do not want to inform the data subject of the breach.
Anyway, you should also plan to inform the data subject if you are informing the Supervisory Authority. You would not want them to find out from the ICO website or the media.
What do you need to tell the Data Subject?
You only need to inform the data subject if the there is likely to adversely impact their privacy as a result of the data breach.
This means you must carry out a risk assessment of what the likely impact will be. However, if you have previously carried out a DPIA, then you should already know what the impact would do. This is the whole rationale behind DPIA. It’s all making sense now, right?
In order to do this, you will need to be in possession of the full facts. The scale and nature of the breach, what data was exposed, what is the likelihood of exploitation of this data and what the impact it would have on the subject if it was exploited. The impact could be:
- Financial (e.g. loss of money, credit scoring form identity theft).
- Physical (e.g. physical danger of harm).
- Psychological (distress from reputational damage, the disclosure of confidential information such as medical illness or sexual orientation).
There may be other factors involved depending on what type of data was disclosed. Suffice to say, you will need to get this right and I would suspect most organisations would err on the side of reporting to be safe. Unless you are absolutely clear that there will be no privacy impact then the advice would be to inform the impacted data subjects without undue delay.
Why without undue delay? So that they can protect themselves from exploitation such as phishing scams, physical attacks etc. Please document any rationale and the process taken to reach these decisions.
How and what should you communicate?
As mentioned above, the GDPR does not require that you should contact each data subject directly. Depending on the size of the breach, it may not be possible “without undue delay” to contact everyone. For example, the Yahoo breach involved well over a billion records. It would not have been feasible to contact each and every one of them separately.
An initial approach may be to publish something on your website, social media or the general media followed by a more detail direct communication. On other occasions, it may be easier to contact small groups of individuals directly by email or letters. Indeed in certain circumstances, you may need to contact them in confidence, in advance of the news breaking.
Communication to subjects should detail:
- The nature of the breach.
- The likely consequences of the breach.
- Advice to the subject on how they can safeguard or mitigate any likely impact damage themselves.
- The contact details of the DPO.
However, it is advisable that organisations go well beyond their legal and fiduciary duty to limit reputational damage. This may include details of what remediation has been taken by the controller to limit the damage, a hotline for advice and reporting of any loss or damage, any goodwill payments such as free credit referencing/monitoring services and regular updates and support.
Author : Moyn Uddin GDPR-P, CISSP, CISA, CISM, CRISC, ISO27001 LA, TOGAF – is a certified GDPR and Cybersecurity practitioner. He as a security practitioner has written, tested, embedded many incident management plans and process and dealt with many incidents and data breaches. He is also the co-author of RESILIA – Cyber Resilience Best Practices from AXLEOS, published in 2014 and the author of the accompanying Pocketbook. He is also the lead author of the Cyber Resilience Best Practices training course for ITpreneuers
If you need any assistance with incident management, GDPR or cybersecurity please contact us.