Chapter 14: Incident Response Management and Reporting – EU General Data Protection Regulation (GDPR): An Implementation and Compliance Guide


It is critical that organisations be prepared to respond to security breaches in respect of personal data. It has become a truism to say that, sooner or later, every single organisation suffers a data breach. Multiple surveys and reports demonstrate that most organisations are subject to multiple breaches in a year of varying sizes and impacts. The issue is not “if” but “when”. When there is a data breach, you need to have in place a response mechanism that enables you to respond quickly and effectively.

Under the Regulation, a personal data breach is not merely marked by the loss of the data to an outside party, but is more broadly defined:


‘personal data breach’ means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.213

Incident management is the process by which the ongoing impacts of such breaches are minimised. It entails recognising that an incident has occurred, responding to the immediate and long-term concerns, and tracking the incident to ensure that the steps taken are effective.


The GDPR has specific rules regarding when and how an incident must be reported to the supervisory authority and to the affected data subjects. The data controller is required to notify the supervisory authority of a personal data breach “as soon at the controller becomes aware that a personal data breach has occurred […] without undue delay and, where feasible, not later than 72 hours after having become aware of it”214.

While the organisation can avoid this requirement if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons”215, the incident management process may be unable to identify the risks with the immediacy necessary under the notification rules. As such, it’s good practice to make notifications by default in order to avoid accidentally breaking the law.

The notification needs to include several specific pieces of information, which can be submitted in stages where necessary216:

  1. The nature of the personal data breach, including the categories and approximate number of data subjects affected, and the categories and approximate number of personal data records concerned.
  2. The name and contact details of the DPO or other contact for further information.
  3. The likely consequences of the personal data breach.
  4. The measures taken or proposed in order to address the personal data breach, including measures to mitigate possible adverse effects.

It is advisable to include these elements in a reporting template to ensure that your reports to the supervisory authority are comprehensive and meet the requirements.

The Regulation also requires you to notify data subjects if “the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons”217. It should be noted that this is different from the requirements for notifying the supervisory authority, which only requires there to be a risk, not a “high” risk. The exceptions to the requirement for notifying data subjects of breach are218:

  1. If the controller has implemented measures, such as encryption, that mean the data cannot be read by unauthorised persons.
  2. If the controller has taken steps to ensure the high risk is no longer likely to materialise.
  3. If notifying the affected persons would involve disproportionate effort. In this instance, the data controller will need to make a public communication to inform the data subjects in an “equally effective manner”.

The breach notifications must be provided to data subjects “in clear and plain language”219 and “in close cooperation with the supervisory authority”220, and should include:

  1. The name and contact details of the DPO or other contact for further information.
  2. The likely consequences of the personal data breach.
  3. The measures taken or proposed in order to address the personal data breach, including measures to mitigate possible adverse effects.

Unlike notifications to the supervisory authority, using a standard notification is undesirable. A clear statement of what has happened and what you intend to do about it, along with the appropriate contact details, is much less likely to receive a negative response if it appears to have been composed specifically for the recipient rather than as a form letter.

Data processors must assist data controllers in meeting the breach notification requirements, as noted in Article 28, which requires that the processor “assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and information available to the processor”221, and in Article 33, which states that “the processor shall notify the controller without undue delay after becoming aware of a personal data breach”222.

Events vs incidents

In the parlance of information security, an information security event is an occurrence that indicates a possible breach of information security policy or failure of controls223, while an information security incident is an occurrence that indicates a probable breach of information security224. An information security incident is a subset of an information security event.

For example, getting an alert from an intrusion prevention system (IPS) is an information security event. If the alert says that the intrusion was stopped as intended, then it’s not even an event because the control worked as intended. However, if the alert says that the IPS failed to stop the intrusion, it is definitely an event but, because this is an expected possibility, an organisation typically has additional fall-back controls in place which are automatically triggered. If one or more of those controls are bypassed, the event might be upwardly classified to an incident. Incidents need to be investigated.

An incident management programme should make it clear how to distinguish between an event and an incident, and should also ensure that events are appropriately assessed to confirm whether or not they constitute an incident. Events will often be reported based on automated systems, emails from concerned employees, and so on. Each event might then be reviewed manually or with automated systems (depending on the nature of the event) to determine whether the event constitutes a threat to information security.

Types of incident

Information security incidents can come in a vast array of forms, ranging from physical disruptions to electronic intrusions. It’s easy to fall into the trap of thinking that you only need to worry about computer-based incidents if your data is stored electronically. If the dripping water of a leaking roof shorts out a server and the information cannot be recovered, then it would be an information security incident that has resulted in the loss of data. An incident that prevents access to personal data means that you cannot support the data subject’s right to accessibility or to have their data corrected.

Incidents are the result of a threat successfully exploiting a vulnerability, so your risk assessment should provide a good idea of the variety of incidents possible within your organisation. Not all incidents can be predicted. Some incidents will occur that are or appear to be unrelated to any identified risk. This doesn’t mean that the incident is harmless; it simply means that you have an additional data point to take into account at your next risk assessment.

Cyber security incident response plans

Incident response is mandated in a number of standards and frameworks, several of which will be excellent tools for maintaining compliance with the GDPR. ISO 27001, ISO 22301 and the PCI DSS all require the implementation of a systematic incident management regime.

These standards lay out a set of core requirements and record-keeping measures to ensure that incidents are appropriately managed, but they give organisations the scope to develop a programme appropriate to their needs.

CREST, a non-profit organisation for information security penetration testing, has developed a three-phase cyber incident management process that is generally applicable to any organisation225. In its simplest terms, the process is:

  1. Prepare

    a.  Conduct a criticality assessment for your organisation.

    b.  Carry out a cyber security threat analysis, supported by realistic scenarios and rehearsals.

    c.  Consider the implications of people, process, technology and information.

    d.  Create an appropriate control framework.

    e.  Review your state of readiness in cyber security incident response.

  2. Respond

    a.  Identify the cyber security incident.

    b.  Define objectives and investigate the situation.

    c.  Take appropriate action.

    d.  Recover your systems, data and connectivity.

  3. Follow up

    a.  Investigate the incident more thoroughly.

    b.  Report the incident to relevant stakeholders.

    c.  Carry out a post-incident review.

    d.  Communicate and build on lessons learned.

    e.  Update key information, controls and processes.

    f.  Perform a trend analysis.

Developing your incident management based on this best-practice structure would ensure that incidents are treated both before and after they occur, and that any incident results in a better understanding of the incident and how to deal with it.

Many of the points covered in the CREST framework are also contained in ISO 27001. The “Prepare” phase, for instance, aligns with the risk management practices that ISO 27001 describes, and the “Follow up” phase can be incorporated into the review and continual improvement processes.

Incident management processes should be built into wider business continuity management systems to ensure that there is continuity and integrity of processes, and clarity around roles and responsibilities, when cyber incidents escalate to affect business continuity generally. The international standard for best practice in business continuity management systems is ISO 22301. There are two other standards in the ISO 27001 family that may be useful in structuring incident response processes: ISO/IEC 27031, for ICT business continuity and ISO/IEC 27035 for incident management.

Where CREST’s scheme is focused on cyber incidents, your organisation needs to be prepared for incidents of all kinds that could harm personal data. This includes incidents caused without human intervention (natural disasters, etc.), those caused by failure to act (such as oversights or poor processes), and not just incidents with a clear attacker or malicious intent. Despite this, the overall approach of the three CREST phases supports managing incidents of all types.

Key roles in incident management

Incident management should be supported by a range of individuals across the organisation. First, it needs to be supported from the top to ensure it is given the resources it needs and that people understand that the processes involved in preparing for incidents (including preventive measures) are not pointless or useless tasks. It should be clearly communicated that incidents can threaten the organisation as a whole and put everyone’s jobs at risk.

The people who will be implementing any preventive measures need to be on board, as do those who work with those measures. For instance, if an employee needs to lock a door each time they go through it, they should understand why and the consequences of failing to do so. The employee might not have implemented this measure, but they have to follow it consistently every day, even when it may initially appear to be onerous or wasteful.

Everyone within an organisation needs to understand their reporting obligations. If someone sees something odd, they need to know a) that it should be reported, and b) who they should report it to, even if that’s as simple as reporting it to their line manager. There should be a clear reporting structure in place so that events can be reported, escalated, investigated and responded to appropriately.

Critically – and hopefully self-evidently – an individual should be assigned to the incident management process. This should be an identified person who has the authority and responsibility to investigate events (or have them investigated), to report to senior management if an incident occurs, and to manage the organisation’s notification process.


Preparation is almost certainly the more important part of the whole process. Only sufficiently prepared organisations can mitigate the impact of incidents, recover quickly, and potentially even come out of an incident looking better than before.

The preparation phase of incident management is analogous to your risk management and DPIA processes. Given that incidents can arise suddenly and that a failure to respond almost always worsens the situation, your preparation should ensure that incidents can be identified quickly and responded to almost as quickly.

Your incident response plans should be tested and rehearsed to ensure that they are effective and that they can be activated swiftly. If testing shows that the plan is ineffective or slow, you have time to amend the plan that you wouldn’t have in the midst of dealing with an actual incident.


Getting the response phase right at the moment of activation is critical, and it is also when you are under the most pressure. Timescales are enormously important in incident management, so you will need to activate your responses as soon as possible to minimise damage. Just like in medical care, treating an incident promptly minimises the risk of long-term damage.

To identify incidents, you should have in place methods for reporting events and suspected incidents and then for performing “triage” to establish which need to invoke the incident response process. Many incidents will only be evident to a small number of people – the person who updates the website, for instance, might be the first to discover that the website has been knocked offline by a Denial of Service (DoS) attack. This person must understand how to report the occurrence and there must be a clear method to determine whether the reported occurrence designates an information security event or an information security incident.

When an incident has been identified, the situation should be investigated to determine the cause and response objectives defined. In the event of a DoS attack, a response objective might be to get the website back online within four hours. You might even have a number of simpler objectives to make sure that all steps in the response are carried out before moving on to the recovery.

With defined response objectives based on an understanding of the incident, you can take the first step of direct action against the incident: containment. This might involve blocking an attacker from their point of access into your network, stabilising disrupted systems, or otherwise preventing further immediate damage.

You also need to make an early decision as to whether or not the incident is one that needs to be reported to your supervisory authority. Pre-determined severity levels, combined with clarity about roles and responsibilities and a rehearsed and tested reporting procedure are essential components for ensuring that the right decisions about breach reporting are made within the time frames permitted by GDPR.

Once the incident has been contained, you can take steps to eradicate the cause of the incident. These steps should include measures to ensure that the incident does not happen again and to eliminate the incident’s capacity to cause harm, e.g. removing a weakness in a web application so that it cannot be exploited. In some cases, the costs of this stage will exceed the costs of the incident, so other solutions to reduce the impact of future incidents should be considered.

Throughout the incident response process, you should be gathering and preserving evidence to provide a clear picture of what happened and why your organisation was unable to prevent the incident. Part of your incident management programme should involve making sure you understand your legal obligations with regard to forensic evidence. In the UK, for instance, the Computer Misuse Act and the Regulation of Investigatory Powers Act – among others – have various requirements relating to the preservation of evidence.

The final step in response to an incident is to recover your systems, data, connectivity, and any other process or resource that has been disrupted by the incident. Your incident response plans should include appropriate contact details for major infrastructure and resources, lists of preferred suppliers, and so on. You should also establish a set of processes for recovering data from backups, isolating and scrubbing malware infections, and any other pertinent actions.

Follow up

The follow up phase of incident management ensures that your organisation applies the lessons it has learned and that the response is appropriately reviewed for effectiveness. While there are fewer time constraints than the response phase, it is important to ensure that the follow up is conducted while the incident is still fresh in people’s minds and while the gathered evidence is still valid.

The first stage of following up is a thorough investigation of the incident. Without the pressures and time-sensitive operations necessary in the response phase, you can spend more time determining the precise details of the incident, and can apply more rigorous methods of analysis. CREST recommends:

  • Problem cause analysis, using:

      failure mode and effects analysis (FMEA), or

      current reality tree (CRT) methods.

  • Root cause identification, using:

      the five-whys approach,

      why-because analysis (WBA), or

      cause-and-effect (fishbone) diagrams.

  • Quantifying the business impact of the incident.

Whatever method you use, your aim is to positively identify the perpetrator or primary cause of the incident.

After you have concluded investigations, the incident should be reported to the appropriate stakeholders. In many cases, this will include customers and partners, but may extend to official authorities, law enforcement, suppliers, industry bodies, or other organisations in the same industry, sector or geographical region. You will need to establish how much detail it is necessary to include in the report, what information should be protected or redacted, and whether you need to provide assurance of the security of personal data or the effectiveness of controls.

The organisation should conduct a thorough post-incident review to establish the effectiveness of the incident management programme with regard to the incident, its cause, impact, and the success of the response. Much like a management review under ISO 27001, the post-incident review should have a number of defined inputs and outputs to support improving the incident management programme.

The organisation will also need to document, incorporate and clearly communicate the lessons learned. If a process is changed because of something learned in the incident, but the occurrence and purpose of the change is not made clear, there is a risk that it won’t be correctly followed the next time the process is invoked. If this process is part of a preventive measure, then the efforts to examine and learn from the previous incident are effectively wasted.

Following an incident, all of your key information on incident management, the controls you have in place and your various other documentation will need to be updated. For instance, if you found that one of your suppliers responded too slowly while you were trying to recover, you’ll need to find a better supplier. If you have identified a more effective configuration for your intrusion prevention mechanisms, that will also need to be documented so that it can be maintained.

The conclusion to following up an incident should be performing a trend analysis of the incident, including trends across your market and sector. If, for instance, cyber criminals gain access to new technologies that provide greater attack capabilities, you need to know about it so that you can predict what the developments will be in six months, a year, and so on. This part of the follow up phase shouldn’t be a one-off event: you should continue examining incident trends so that you can update and amend your controls and responses accordingly.


213 GDPR, Article 4, Clause 12.

214 GDPR, Recital 85.

215 GDPR, Article 33, Clause 1.

216 GDPR, Article 33, Clause 3 - 4.

217 GDPR, Article 34, Clause 1.

218 GDPR, Article 34, Clause 3.

219 GDPR, Article 34, Clause 2.

220 GDPR, Recital 86.

221 GDPR, Article 28, Clause 3 f.

222 GDPR, Article 33, Clause 2.

223 ISO/IEC 27000:2016, Clause 2.35.

224 ISO/IEC 27000:2016, Clause 2.36.

225 Cyber Security Incident Response Guide,