DPO - managing "incidents" vs Data Breaches

The DPO must ensure the existence of a documented registry pertaining to all "events" and interactions that occur concerning Personal Data Processing (meaning collection; storing; access; processing and sharing).

Now, this does not mean that DPO must do it on his/ her own; there are IT tools operated by corporate staff; Legal and Accounting processes; and so on... yet they have been audited and documented under the GDPR Compliance Project and are now monitored by the DPO (both internally as also towards some "critical" Processors) under the scope of Personal Data Protection (regular audits and defined workflows in case of "events"), for that is on of his/ her tasks as the GDPR Compliance auditor ... and, if there are changes, probably a new specific DPIA must be done and also documented updating the existing Compliance Framework.

Not all "incidents" constitute a Data Breach... as well as not all "events" constitute an "incident".

When someone mentions the word "incident" related to Personal Data Protection and GDPR the natural "assumption" often leads to a Data Breach... however, not all "incidents" are Data Breaches.

First one has "events", in the sense of "new things that occur". Now it is not possible to list all the potential examples, therefore so just mentioning a limited number of scenarios:

• a new Customer submitting his/ her Personal Data, in which case it is an "event" that will be mapped/ registered in a documented manner by existing processes and tools operated by some staff or even automated and it is part of "normal" expected running operation;
• a Data Subject who exercises his/ her DSAR and in such case, the "event" becomes an "incident" because, although it is also something to be expected within the operational context, it is not part of the "standard" common daily Corporate Operation... "unique" yet not a Data Breach.
• a staff member lost/ had his/ laptop stolen... an "event" which again constitutes an "incident" for it is not a "normal" situation, however, does it immediately constitute a Data Breach?... well ... not necessarily (although it is easy to jump right on to say Yes).

Let's imagine this last example of a staff member who lost or had his/ her laptop stolen... such an "incident" will imply the need to trigger non-Personal Data related procedures such as the replacement mechanisms from the Purchasing Department + restoring mechanisms from the IT Department + contract update mechanisms from the Controllers Office and... Personal Data Protection (GDPR Compliance) related procedures, to begin with, having the DPO informed about such "incident" ... let's bear in mind that Personal Data Protection context means: Personal Data Security; Confidentiality and Privacy assurance which comprehends the potential risk towards the affected Data Subjects.

The DPO needs to have in place internal Processes and workflows (implemented by him/ her and operated by all relevant staff) that in such a case assure that the DPO will promptly have access to/ get feedback and audit the following points:

• The Corporate information context of that staff member - to which Personal Data does this person have access to under his/ her Corporate role and attributions/ responsibilities;
• Existing Corporate rules and guidelines adequacy - Data Governance (e.g. Data Quality, Enterprise Master Data; Information Management); information Security (e.g. encrypted laptop disc); Business Continuity; other... must all Personal Data be exclusively stored at File Server level or... can some or all be stored on local workstation drives and which was the case with this laptop... was it protected... even encrypted (?)... are they "sufficient" given the type of incident (?);
• Operational Compliance - Did the staff member observe such existing Data Governance Corporate Rules; had he/she got "proper" information and training on those (?);
• Existing Corporate Procedures - Which are the applicable existing mitigation procedures (Risk Management, Incident Management);
• Impact on Personal Data- WHICH was the Personal Data stored on that laptop (?);
• Exposure/ Impact on accessibility - WHICH were the credentials stored on that laptop and WHICH other Data Repositories may be at risk from having them compromised (?);
• Potential Risk Aggravation Factors - WHERE was the laptop supposedly lost (public place; another office space; other...) and WHOM else (3rd parties) know about the "incident" (?) and HOW much time has elapsed since the incident (?);

Now, the DPO is not Superwoman/ man, therefore the point is not for her/ him to get the feedback and start "running" (like crazy) in some direction... there is the need to have an "Incident Management Committee" defined in advance with the goal of swiftly addressing Personal Data related "incidents"; constituted by some "regular members" as well as "eventual ones":

• Legal (Corporate Lawyer);
• IT (CIO, CISO and CTO);
• The DPO;
• Head of Security/ Facilities (if there is one);
• Eventually will include the Area/ Department Managers (where relevant);
• Eventually Processor representatives (e.g. something happened within the scope of a specific SaaS tool in use, other...);

This is an "emergency reaction team", therefore the objective of this "Incident Management Committee" is then to:

• Assess within 24 hours of the incident WHAT happened and HOW it did, plus WHICH Personal Data and access credentials were involved (if any), plus still what seems to have been the route cause (just an unfortunate incident or one that resulted from someone having not observed Corporate Guidelines); note accessing/ validating and detailing the route cause is something that will take place up to the very last minute of the 72 hours (in case of a Data Breach);
• Define and report to the Corporate Board of Management/ CEO/ General Manager, within 48 hours of the incident, if the incident configures a Data Breach; in which case the route cause and impact towards the affected Data Subjects must be "crystal" as well as the potential consequences for the company, plus potential mitigation actions that will minimize the impact of the incident and recommendations on how to prevent it from occurring once again;
• Get the Corporate Decision - The Corporate Board of Management has then 12 hours to reach a decision, meaning if it accepts the findings from the "Incident Management Committee" or not;

After the "Incident Management Committee" gets back the Corporate Decision, the DPO will then:

• If the Corporate Decision agrees with the existence of a Data Breach, prepare the formal Reporting towards applicable Supervisory Authorities and affected Data Subjects with support from Legal and any other relevant areas (e.g. IT; Departments; Partners) and send it. If the "Incident Management Committee" found there had been a Data Breach and the Corporate Decision is contrary to it, then the DPO must present his/ her objection to such decision to the Board of Management.
• Formally close the registry and document the Corporate Decision and incident backlog;
• Define the actions and a schedule for the implementation of the necessary mitigation actions (raised during the "incident management process");

Final Notes

1. Where the incident has taken place at a Processor'/ Co-Controller', the process remains only the trigger will be a message from that partner and to have it properly working the existing Data Processing Agreement between the parties must clearly define the way to ensure mutual awareness towards Personal Data related incidents.
2. Now, the one that usually creates a "big fuzz"... is the DPO obliged to submit the Data Breach notification even where the Company decided not to?

Now, Article 38 - Position of the data protection officer, reads that:

"... (3) The controller and processor shall ensure that the data protection officer (...) shall not be dismissed or penalized by the controller or the processor for performing his tasks..." - so the DPO needs not to be afraid of consequences which derive from performing his/ her role as per required by law.

Article 39 - Tasks of the data protection officer, reads that:

"... (a) to inform and advise the controller or the processor (...) of their obligations pursuant to this Regulation (...) (b) to monitor compliance with this Regulation (...) including the assignment of responsibilities..." - so, the DPO must have the controller/ processor aware of WHAT happened as well as reinforcing their awareness towards their obligations and responsibilities.

Where GDPR refers to the word "liability" it reads:

"... (79) The protection of the rights and freedoms of data subjects as well as the responsibility and liability of controllers and processors (...)

(80) Where a controller or a processor not established in the Union (...) the controller or the processor should designate a representative (...) act on behalf of the controller (...) The designation of such a representative does not affect the responsibility or liability of the controller or of the processor under this Regulation (...)

(146) The controller or processor should be exempt from liability if it proves that it is not in any way responsible for the damage (...)

Article 82 (2) Any controller involved in processing shall be liable for the damage caused by processing which infringes this Regulation. A processor shall be liable for the damage caused by processing only where it has not complied with obligations of this Regulation specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller..."

This is, in fact, a matter that is open for interpretation - should the DPO report the Data Breach regardless of the Corporate Decision (?)

In one hand, if the DPO (even an internal one, therefore a staff member) goes against the Corporate Decision/ instruction and reports a Data Breach, while doing so, he/ she is observing the main purpose of GDPR which is to ensure the Security, Confidentiality, and Privacy of natural Persons with regards to their Personal Data Processing by the company. Therefore any actions taken by the company against the DPO is likely to not prevail in a court of law as long as the company is established in an EU member state (DPOs from the U.S., Canada, other geographies do not benefit from this "legal umbrella").

All the other herein mentioned GDPR articles clearly define that liability lays with the Company (Controller/ Processor) and not any staff member or "provider" if not a Processor/ Co-Controller (which the DPO is not, even if DPO as a Service); therefore, the DPO is, in fact, free to choose if he/ she should or not report a Data Breach where the Company has informed him/ her its decision not to submit such report.

The only thing the DPO must ensure is to have documented his/ her "advise" and the received feedback.

Now, as responsible professionals, I would expect a DPO not to have a linear course of action over such a case scenario, meaning having it depending exclusively on the potential effective risk towards the Data Subjects which derives from the "type" of Data Breach at hand.