Show original post 

When a major data breach catches the eye of the media, reporters are generally only fixated on the number of stolen or lost user profiles or the volume of personal data leaked. The Data Controller must take a far more thorough analysis of any such incidents, with the ultimate aim of ensuring its security practices are improved.

Article 33 of the regulation, which went into effect on May 25, 2018, sets a strict timeline for breach notification to the relevant Supervisory Authorities. It mandates that “the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority.” It is important to note that these are 72 hours, not 72 business hours.

Thus, in just 72 hours, that’s three (3) days, the GDPR requires an entity to gather the following information:

  • 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;
  • The name and contact details of the Data Protection Officer or other contact point where more information can be obtained;
  • The likely consequences of the personal data breach; and
  • 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.

Rightly so, this whole notification requirement will raise a lot of questions such as:

How will I be sure that my organisation’s security incident actually resulted in a breach of personal data?  

Should all personal data breaches be reported to the relevant Authorities?

Is it acceptable to postpone a breach notification in order to focus on remediation and prevent a problem from becoming worse?

Who within the organisation must report the breach?

I believe that in the wake of an alleged personal data breach, an entity should turn to the principle of the six Ws, ‘When? Who? Why? What? Where? How?’, and start thinking about answering all these core questions to establish key facts for effective incident response. The process of solving a ‘problem’ has a beginning, a middle and an end, thus a properly thought out incident response plan helps an entity in dealing with a breach in the most swift and adequate manner.

1. When – should a breach notification be submitted?

First off, there are no holidays when it comes to incident response, however it is worth noting that there is some flexibility in the reporting requirement. The GDPR states that if an entity misses the 72-hour deadline, it must include valid reasons for the delay once the breach is reported.  Moreover, in those instances where the entity is not in a position to provide the relevant Authorities with all the required information at once (e.g. a police or internal investigation is still ongoing or an involved Data Processor has still not provided all the necessary information) it may provide the information in phases without undue further delay. In fact, the Maltese Supervisory Authority has issued an online notification form whereby the reporting entity may select the type of notification it is submitting i.e. either a complete notification or a preliminary notification. Following the submission of a preliminary notification, entities have ten (10) working days from the date of submission, to follow it up with a completed notification.

Establishing a timeline of the activities which led up to the incident is all part of building a better picture of what truly happened. This is why it is important that an Incident Response Plan is not only developed and implemented but is also regularly tested. With such a documented plan, rather than feeling overwhelmed, an entity would be in a better position to strengthen business continuity and disaster recovery operations, as well as to minimise the impact of the breach.   

2. Who - must submit the report to the relevant Authorities?

With the extension of the territorial scope of the GDPR, the law leaves no doubt that reporting requirements are not only limited to companies established in the EU, but also to any company anywhere that processes personal data of data subjects who are in the EU. More specifically, when the processing activities are related to the offering of goods or services, or the monitoring of the behaviour of data subjects who are in the EU. This main change in the current European Union (EU) data protection jurisdiction model, solves one of the biggest problems in European Data Protection law i.e. the lack of jurisdiction over third country’s data controllers which are processing personal data of data subjects who are in the EU. A Controller (or Processor) not established in the EU is required to designate a representative in the EU where Article 3(2) applies. Such representative shall be established in one of the Member States where the data subjects, whose personal data are processed in relation to the offering of goods or services to them, or whose behaviour is monitored, are. In such cases, the breach notification should be made to the Supervisory Authority in the Member State where the Data Controller’s representative in the EU is established.

Moreover, the Regulation specifically states that the obligation to notify the relevant Supervisory Authorities lies with the Data Controller (“the controller shall without undue delay”) and not the entity’s Data Protection Officer (‘DPO’). In terms of notifying breaches, the DPO’s involvement shall be limited to providing sage advice and information to the Data Controller, however the ultimate decision whether a breach shall be notified or otherwise, resides with the Controller. Nevertheless, the DPO should always be promptly informed about the alleged existence of a personal data breach as s/he still plays a key role in assisting throughout the breach management and notification process, especially since the DPO is required by law to cooperate with and act as a contact point for the supervisory authority and for data subjects.

3. Why – did the personal data breach occur? 

In order to effectively remediate the breach, the Data Controller needs to create a detailed step-by-step outline of what exactly led to the breach. This information is essential for any external announcements which may need to be made, either as part of the breach notification to the Supervisory Authority, or any other public announcements.

Breaches can be categorised according to the following three information security principles:      
1. Confidentiality breach - where there is an unauthorised or accidental disclosure of, or access to, personal data e.g. infection by ransomware.           
2. Integrity breach - where there is an unauthorised or accidental alteration of personal data.
3. Availability breach - where there is an accidental or unauthorised loss of access to, or destruction of personal data which cannot be restored from backups, or there is a significant disruption to the normal service of an entity.

A breach can either concern confidentiality, integrity and availability of personal data separately or a combination of these.

In the event that the breach may have arisen at the end of the Controller’s Processor, the Processor shall be obliged not only to notify the Controller of the breach without undue delay, but also to “assist[s] the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor”. This is one of the reasons why a legally binding agreement should be drawn up with all your Data Processors i.e. in the event of a breach, the Processor shall be constrained (even within a stipulated amount of time within the Agreement) to furnish the Data Controller with all the required information in relation to the breach. Remember that, the controller retains overall responsibility for the protection of personal data; the fact that a breach may have arisen at the end of the Processor will not provide the Controller with an excuse for delay.

Similarly, where a processor is subject to Article 3(2), it will be bound by the obligations on processors, of particular relevance here, the duty to notify a breach to the controller.

4. What – is the resulting risk after the risk assessment is conducted?

Article 33(1) clarifies that breaches that are “unlikely to result in a risk to the rights and freedoms of natural persons” do not require notification to the supervisory authority. Moreover, Article 34(1) states that only “when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons” is the notification obligation to data subjects triggered. Thus, upon becoming aware of a breach, the Data Controller must carefully assess the risk on a case by case basis.

The severity of a personal data breach is defined as the “estimation of the magnitude of potential impact on the individuals derived from the data breach”. There are a myriad of impacts of a personal data breach on the data subject, including identity theft, fraud, discrimination, financial loss, reputational damage and significant humiliation.

The main criteria which should be taken into account while assessing the severity of a personal data breach are:

  • Data Processing Context: the nature, sensitivity, and volume of the data;
  • Ease of identification: how easy it will be for a party who has access to compromised personal data to identify specific individuals, or match the data with other information to identify individuals;
  • Severity of consequences for individuals;
  • The number of affected individuals; and
  • The circumstances of the breach (loss of confidentiality, integrity, availability of data, negligence or malicious intent, human or technical error).

The resulting risk should exhibit the level of severity of the breach, taking into account the impact to the individuals as follows:

  • Low risk: Individuals either will not be affected or may face a few inconveniences, which they will easily overcome without (e.g. time spent re-entering information).
  • Risk: Individuals may face significant inconveniences, which they will be able to overcome despite a few difficulties (e.g. extra costs, denial of access to business services).
  • High risk: Individuals may face significant or irreversible consequences, which they may be or may not be able to overcome albeit with serious difficulties (e.g. financial loss, loss of employment, discriminatory treatment, marginalisation, significant stress/anxiety).

Once the severity level has been defined this should be used by the Data Controller to determine whether it is legally obliged to notify solely the competent Authorities or even the relevant data subjects.

5. Where – should breaches be documented?

As part of the accountability principle which reverberates throughout the entire Regulation, even though the Data Controller, following a risk assessment, may take the final decision that a personal data breach should not be notified to the Supervisory Authority, it is still obliged to document all breaches comprising the facts relating to the personal data breach, its effects and the remedial action taken. Moreover, the Supervisory Authority may request to see such records either as part of the breach investigation or any other ad-hoc investigation. This breach register should at least include the following information:

  • Date of breach;
  • Number of data subjects affected;
  • Nature and description of the breach including the personal data compromised;
  • Consequences of the breach;
  • Remedial action taken;
  • Whether notification was made to the Supervisory Authorities and data subjects, if not, a justification thereof;
  • Whether the notification was delayed, if so, reasons justifying such delay.

Furthermore, where the Data Controller communicates a breach to the affected individuals, it should demonstrate accountability and compliance by retaining evidence of such communication.

Failure to adequately document a breach may lead to the Supervisory Authority to exercise its powers under Article 58 and/or imposing an administrative fine in accordance with Article 83.

6. How – should the Data Controller proceed after the submission of the Data Breach Notification Report?

Once a breach has been reported to the Supervisory Authority, it shall investigate the case to make decisions about any action it may take, and to carry out those actions if necessary. At this point one should highlight that not all infringements of the GDPR will lead to the rather alarming fines which we’ve been hearing about even before the entering into force of the Regulation. Apart from the power to impose administrative fines, Supervisory Authorities also have corrective powers e.g. the issuing of warnings, reprimands and orders. In simple words, in the case of ‘minor infringements’, the Supervisory Authority will only impose what is proportionate in relation to the breach reported.

 The fine or other corrective measure imposed will heavily depend on the:         

(a) the nature, gravity and duration of the failure;

(b) the intentional or negligent character of the failure;

(c) any action taken by the controller or processor to mitigate the damage suffered by data subjects;

(d) the degree of responsibility of the controller or processor, taking into account technical and organisational measures implemented by the controller or processor;

(e) any relevant previous failures by the controller or processor;

(f) the degree of co-operation with the Supervisory Authority, in order to remedy the failure and mitigate the possible adverse effects of the failure;

(g) the categories of personal data affected by the failure;

(h) the manner in which the infringement became known to the Supervisory Authority, including whether, and if so to what extent, the controller or processor notified the Supervisory Authority of the failure;

(i) the extent to which the controller or processor has complied with previous enforcement notices or penalty notices.

In conclusion, following any breach which the Data Controller may have experienced, it should take it as a learning opportunity to identify any other gaps, ensure the necessary safeguards are implemented and from now on stay on the right side of the GDPR. Such safeguards include but are not limited to:

  • Setting up an incident response plan;
  • Implementing independent and periodic audits of the Controller’s data protection, data security, and incident response processes; and
  • Informing and training staff accordingly on data protection and information security.