GDPR (17) What you need to do in the event of a data breach – incident management

22 December 2017

In the previous instalments of this blog we explained how you can take appropriate measures to ensure the personal data that you process is properly protected. You need to understand the potential risks, you need to take various measures to reduce the risks or remove them if possible, and if you engage subcontractors you need to ensure that they organise matters as well as you do. However, things can still go wrong. This instalment looks at what you need to do in such situations.

A data breach is a situation in which confidential data are lost, are wrongly changed, are made public, or fall into the wrong hands. The GDPR requires that the controller, who is responsible for the processing of personal data, must report any data breaches that could constitute an infringement of the privacy of data subjects without unnecessary delay to the data protection authority. If there is a serious risk of damage, the data subjects will also have to be informed.

Before considering whether a data breach has to be reported to the Privacy Commission, I will first focus on incident management. After all, your primary obligation as a controller or processor of data is to prevent incidents and minimise the impact of any incidents that do occur.

First of all, you have to spot incidents at the earliest possible stage. There are many network tools that can reveal abnormal behaviour in the network, detect viruses or malware, or apply content filtering, which you can use for this purpose. That said, alert employees are also capable of spotting infringements. It is therefore crucial that staff training or awareness campaigns are organised on a regular basis, to ensure everyone is clear about what constitutes an abnormal or worrying situation. It is also important that all employees know who needs to be called upon when an incident occurs.

Second, you must take steps as soon as possible to end the incident or limit its impact. All employees have to comply with a number of rules. If they come across information in a place where it does not belong, they have to delete it or notify someone in charge. This information may be found on physical carriers or in files located in the network. If they encounter unescorted strangers in a secure zone, they have to raise the alarm, and so on. When monitoring alerts point to hacking or an infected system, system engineers will need to examine the system as soon as possible and may have to shut it down as a preventative measure.

In cases of doubt, it is best to stop processing operations and block transfers of processed data until it is certain that a problem exists and the degree to which the processed data have been affected is known. By doing this, you can often ensure an incident does not ultimately become a data breach. As long as wrongly processed data are not disseminated or disclosed, no infringement is deemed to have occurred, and hence there is no impact to deal with. In that case, strictly speaking there is no data breach.

Next, an analysis of the facts can be started, if necessary in parallel with the above. This will establish the true cause of the problem. You can then think about making improvements to the organisation, systems, applications and the way employees work in order to prevent a reoccurrence. The analysis will also consider the potential or actual impact, whether the confidentiality and integrity of the data is at risk, whether any of the data are personal data, and the possible consequences of the infringement. In many cases, establishing the amount of data, and therefore the number of people, affected by the incident will take some time. Moreover, whether an actual risk of an impact exists, and in particular the potential extent of the damage, is not always immediately clear.

You need to be able to answer the above questions before you can decide whether the data breach has to be reported to the Privacy Commission or the data subjects. Whether you need to do this, and, if so, when, will be the subject of the next instalment of this blog.

In addition, all incidents must be logged in your internal records. All incidents must be analysed – actual data breaches as well as near misses. The resulting information is crucial for evaluating the existing procedures and guidelines and for checking whether the measures taken provide adequate protection against the possible risks.  The causes of an incident must be recorded, as must the planned remedial actions. Following up incidents according to a fixed plan will systematically improve your organisation’s security.

In extreme cases, a data breach may have disastrous consequences. An organisation may be confronted with huge communication problems if highly sensitive information about a large number of data subjects is leaked. In some cases, the data breach is known to people outside the organisation and the press is already aware of it. In such situations, it is useful to be able to fall back on pre-prepared crisis communication scenarios. If your organisation has taken out cyber security insurance, your insurer might be able to help you with this.

Where there are suspicions that criminal offences have been committed, you must also ensure that a legal file is compiled swiftly. It is sometimes necessary to make a quick backup of the situation at the time the incident was discovered, or set aside log files, before the relevant data disappears or are changed by steps taken to resolve the incident. Obviously, this will sometimes mean going against what needs to be done to limit the existing problem quickly. If the police or courts are involved, you must also never lose sight of what you can, and cannot, do when acting on your own authority, particularly if your role is that of processor. In that case, you need to involve the controller at the earliest possible stage. If the authorities require that you hand over information, you will still be under an obligation to the controller to protect this information insofar as possible, and you must ensure that you do not divulge any data (e.g. relating to other data subjects) that is not required for the purposes of the investigation.

These steps should be well-documented so that everyone within the organisation is aware of them and acts accordingly. It will also help you demonstrate that you take your obligations under the GDPR seriously.


Viktor D’Huys is the ICT manager of Group Joos. He is responsible for matters including data security and the coordination of the GDPR project. He is a Certified Information Security Manager (CISM certified by the ISACA) and has been awarded the CIPP/E (Certified Information Privacy Professional/Europe) credential by the IAPP (International Association of Privacy Professionals).

If you have any questions or comments, please write to us at