There are very few organisations that at some stage in the business relationship will not encounter some form of personal data breach and the data controller will have to respond . Preparing for, and anticipating a breach, are the proactive parts. Encountering an actual breach is only the start. An active response must be diligent and prudent. This response must include an integral and strategic risk assessment, leading to mitigation of those risks in a timely manner. GDPR and data protection consultants, GDPRXpert.ie, have advised extensively on data breaches.
Art.12 GDPR defines “a personal data breach as a breach of security leading to the accidental or unlawful destruction , loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.” Recital 85, GDPR, warns that the breach may, if not addressed in an appropriate and timely fashion, result in physical, material or non-material damage.
Examples abound but include :
- financial loss (high risk);
- identity theft (high risk);
- damage to reputation (high risk);
- loss of confidentiality of personal data protected by professional secrecy;
- Fraud and other economic or social disadvantages.
There are three broad types of breaches first outlined by the Art. 29 Working Party. The Working Party was a European Union data protection advisory group, prior to the European Data Protection Board (EDPB) and the GDPR.
- The ‘confidentiality breach‘ where personal data are disclosed or accessed in an unauthorised or unlawful manner;
- The’integrity breach‘ where personal data are altered in an unauthorised or unlawful manner;
- The ‘availability breach‘where personal data are lost or destroyed in an unauthorised or accidental manner.
Looking at something like “accidental or unlawful destruction” of personal data will lead one to discover that here the data no longer exist . If the data are in existence at all, they no longer exist in a form accessible to the data controller. This is consistent with an ‘availability breach’.
In a “loss’” scenario the data controller lacks control of , or no longer has access to, the data or the data. Think of ransomware with data encrypted, or the loss of an encryption key. The personal data are no longer in the possession of the controller at all and so there is an ‘availability breach’.
With “alteration” of data the integrity of the data has been compromised, hence an ‘integrity’ breach.
“Unauthorised disclosure of, or access to, personal data” is most commonly seen where data are disclosed to recipients not authorised to receive such data and the result is a clear ‘confidentiality’ breach.
Whatever the type or form of breach, action is required in a timely fashion.
Under the GDPR two primary obligations are placed upon the controller;
(a)Notification of any personal data breach to the DPC, unless the data controller can demonstrate the breach is unlikely to result in a risk to data subjects;
and (b) communication of that breach to data subjects, where the breach is likely to result in high risk to data subjects.
GDPRXpert.ie, acting as outsourced DPO ,have conducted many data breach analyses . This experience leads to the solid conclusion that very few breaches are the same. However, one aspect that does not change is the breach notification procedure, as this is clearly set out in GDPR and Data Protection Act 2018.
First of all, let’s look at the procedure where the breach is to be notified to the DPC.
Data Breach Notification to the DPC
The controller is compelled to notify the DPC of a personal data breach unless the breach is unlikely to result in a risk to the rights and freedoms of a natural person. GDPR and data protection consultants GDPRxpert.ie can attest to the tricky subjective nature of the assessment of what is ‘unlikely’. Should the decision be that a risk is not unlikely, then the controller has to notify the DPC.
Notification to the DPC has to take place without undue delay and where feasible, no later than 72 hours once the controller has become aware of the breach. In a situation where the DPC is not notified within the 72 hour time frame, reasons for any delay must be given.
Accountability requirements under Art.5 (2) GDPR will kick in, meaning that the controller in the context of a data breach will have to demonstrate compliance with the other principles of data processing including Art. 5 (1) (f), ‘integrity and confidentiality’, i.e., “been processed in a manner that ensures appropriate security of personal data”…
On top of this, under Art.33(5) ,controllers must under Art.33(5) document all information relating to the breach so that the DPC can have evidence of their compliance with the notification obligations under Art.33.
A controller should be regarded as having become ‘aware’ of the breach when they have a reasonable degree of certainty that a security incident has occurred and compromised personal data. Don’t forget, that in order to comply with their obligations under the Article 5(2) (principle of accountability) , as well as the requirement to record relevant information under Article 33(5), controllers should be able to demonstrate to the DPC when and how they became aware of a personal data breach.
Controllers, as part of their internal breach procedures, should have a system in place for recording how and when they become aware of a breach.
Allied to this is the necessity for being able to show their methodology in assessing the potential risks posed by the breach.
Controllers need to show a coherent methodology to explain their decision making.
N.B. It does not mean the DPC will accept it as being sound or reasonable, but the controller will , in all likelihood be seen to have at least been acting in good faith.
The default position for controllers is that all data breaches should be notified to the DPC, except for those where the controller has assessed the breach as being unlikely to present any risk to data subjects.
The controller MUST show why they reached this conclusion.
Documentation should include the details of how the controller assessed the likelihood of risk and severity of risk to the rights and freedoms of the data subject.
In all situations of recognised breaches , even ones that do not require notification to the DPC, the legal onus is always on the controller to record at least the basic details of the breach, the assessment thereof, its effects, and the steps taken in response, as required by Article 33(5) GDPR.
(This is often forgotten by controllers and missed by many more. Be careful!!!)
To state the patently obvious ; to know whether or not the breach is one that should be notified to the DPC, the controller must first be aware of the data breach itself. Once aware of the breach, the clock is ticking. As we just touched on, before deciding on whether there is a need to notify the DPC concerning a breach, the controller must make an adequate assessment of the risks posed by the data breach.
This is not an exact science, but more a judgement process.
In this process there are some factors and particular aspects that demand scrutiny.
The assessment has to be set in the knowledge that there are risks that impact negatively not just on the right to data protection and privacy , but often many other rights such as free speech and freedom of movement.
Factors that controllers should take into account when engaging in such an assessment include, but are not limited to:
- the type and nature of the personal data (including whether it contains sensitive, or ‘special category’ personal data);
- the circumstances of the personal data breach;
- whether or not personal data had been protected by appropriate technical protection measures, such as encryption or pseudonymisation;
- the ease of direct or indirect identification of the affected data subjects;
- the likelihood of reversal of pseudonymisation or loss of confidentiality;
- the likelihood of identity fraud, financial loss, or other forms of misuse of the personal data ;
- whether the personal data could be, or are likely to be, used maliciously;
- the likelihood that the breach could result in, and the severity of, physical, material or non-material damage to data subjects;
- and whether the breach could result in discrimination, damage to reputation or harm to data subjects’ other fundamental rights.
Once the controller has made the risk assessment and concludes there is a need to notify the DPC, the notification must at least:
- describe the nature of the personal data breach, including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;
- communicate the name and contact details of the data protection officer (DPO) or other contact point where more information can be obtained;
- describe the likely consequences of the personal data breach and;
- describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.
To assist the DPC in assessing compliance with the requirement to notify ‘without undue delay’, as well as the principle of accountability, the DPC recommends that controllers include, in their initial notification, information on how and when they become aware of the personal data breach, along with an explanation for any delay, if applicable.
Where, and in so far as , it is not possible to give all the foregoing information at the same time , the information may be provided in phases without undue further delay.
Data Breach Notification to Data Subjects
As referenced earlier, there is also an obligation placed on controllers to notify the data subject of a data breach:
“where that personal data breach is likely to result in a high risk to the rights and freedoms of natural persons” ( Art.34 (1) GDPR).
Where the risk is immediate and needs to be mitigated prompt action is required in communicating with the data subject (See Recital 86).
The need to implement appropriate measures against continuing or similar personal data breaches may justify more time ( Recital 86).
Where there is a need a need for notification to the data subject Art. 34(2) mandates the communication must describe in clear and plain language the nature of the personal data breach and contain at least ( i.e. at a minimum) the information contained in points (b) (c) and (d) of Art. 33 (3).
Where a controller has not notified the data subject, the supervisory authority, having considered the likelihood of a high risk resulting from the breach, may either require the controller to communicate a breach or decide that any of the conditions (a) (b) or (c) of Art.34(3) outlined below have been met.
- The controller has implemented appropriate technical and organisational protection measures, such as rendering the data unintelligible to any person not authorised to access it, e.g. encryption;
- The controller has taken subsequent measures so that the high risk is no longer likely to materialise and ;
- It would involve disproportionate effort to communicate directly to every data subject. Here a public communication suffices.
In a case where the controller deems it necessary to communicate the breach to the data subject , the controller will also be communicating it to the DPC.
This is on the logical basis that if it is ‘likely to result in a high risk to the rights and freedoms of natural persons’, (must notify Data Subject) by implication, the same breach cannot be ‘unlikely to result in a risk to rights and freedoms’ ( also notify DPC).
If it is likely to pose a high risk then it can hardly be unlikely to pose a risk, which is lower than a high risk. Any ‘risk’, or ‘risk simpliciter’, as some like to call it, must be of a type that is lower than a ‘high risk’.
There is clearly a higher threshold for notification to the data subject.
Whilst there is no obligation on controllers to communicate a personal data breach to affected data subjects where it is not likely to result in a high risk to them, controllers are nevertheless free to communicate a breach to data subjects where it may still be in their interests or appropriate to do so anyway, in the context of that particular breach.
While the notification should be made to the data subject as soon as reasonably feasible, sometimes it may be advisable to delay notification.
A common example is where a controller is made aware a criminal investigation may be pending and early notification may prejudice such an investigation. In this scenario ,a delay on the advice of law enforcement authorities would be justifiable.
Once it becomes clear that any notification is no longer prejudicial to an investigation , the data subject should be promptly informed.
We have seen earlier that once the breach has been detected and the risks assessed the controller may be obliged to notify the DPC and the data subject.
This depends most of all on the conclusion reached after the risk assessment.
We also looked earlier at some factors to be taken into account when conducting the risk assessment.
The risk assessment has to be an objective assessment.
It must judge the severity and likelihood of the risks.
As part of the ePrivacy Directive , the EU Agency for Network and Information Security (ENISA) produced recommendations for a data breach severity assessment.
Within this, the severity of three different factors is to be considered.
Assessing the severity of the risk.
Factor A: The type of data that was breached can have a value of 1-4;
Factor Y: The ease with which a data subject can be identified is assigned a value of 1 or lower ;
Factor Z: The specific circumstances of the breach can have a value of 0.5 or lower.
No assessment modality has yet been adopted for the GDPR, but this method is a useful guide to help quantify Risk Severity.
Despite all this, any risk assessment remain more of an art than a science.
(Consequently, a key element of any data security policy is being able, where possible, to prevent a breach and, where it nevertheless occurs, to react to it in a timely manner).
Record Keeping Obligations.
Regardless of whether or not a breach needs to be notified to the supervisory authority, the controller must keep documentation of all breaches, as Article 33(5) explains: “The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article.” Therefore, controllers must bear in mind the onus is on them to ensure that they continue to document how any personal data breaches that arise are dealt with.
This is linked to the accountability principle of the GDPR, contained in Article 5(2). The purpose of recording non-notifiable breaches, as well notifiable breaches, also relates to the controller’s obligations under Article 24, and the supervisory authority can request to see these records. Controllers are therefore encouraged to establish an internal register of breaches, regardless of whether they are required to notify or not.
Whilst it is up to the controller to determine what method and structure to use when documenting a breach, in terms of recordable information there are key elements that should be included in all cases. As is required by Article 33(5), the controller needs to record details concerning the breach, which should include its causes, what took place and the personal data affected. It should also include the effects and consequences of the breach, along with the remedial action taken by the controller.
The old Art. 29 WP guidelines recommend that the controller also document its reasoning for the decisions taken in response to a breach. In particular, if a breach is not notified, a justification for that decision should be documented. This should include reasons why the controller considers the breach is unlikely to result in a risk to the rights and freedoms of individuals . Alternatively, if the controller considers that any of the conditions in Article 34(3) are met, then it should be able to provide appropriate evidence that this is the case.
(The conditions under Art. 34(3) are those that make notification to data subjects unnecessary, as seen above earlier)
Where the controller does notify a breach to the supervisory authority, but the notification is delayed, the controller must be able to provide reasons for that delay; documentation relating to this could help to demonstrate that the delay in reporting is justified and not excessive.
Where the controller communicates a breach to the affected individuals, it should be transparent about the breach and communicate in an effective and timely manner. Accordingly, it would help the controller to demonstrate accountability and compliance by retaining evidence of such communication.
To aid compliance with Articles 33 and 34, it would be advantageous to both controllers and processors to have a documented notification procedure in place, setting out the process to follow once a breach has been detected, including how to contain, manage and recover the incident, as well as assessing risk, and notifying the breach.
In this regard, to show compliance with GDPR it might also be useful to demonstrate that employees have been informed about the existence of such procedures and mechanisms and that they know how to react to breaches. It should be noted that failure to properly document a breach can lead to the supervisory authority exercising its powers under Article 58 and, or imposing an administrative fine in accordance with Article 83.
Much of the foregoing information is also available on this link at the DPC website.
The DPC has also recently updated a data breach notification form.
At the same site you will find useful tips on avoiding data breaches.
Here at GDPRXpert.ie we are GDPR and data protection consultants with vast expertise helping businesses first fully recognise, and then properly react to , data breaches .
GDPRXpert.ie are located in Carlow/Kilkenny and Mayo, offering a nationwide service.
Call 0858754526 or 0599134259 to discuss your particular need.
Patrick Rowland, GDPRXpert.ie
