Ready for your 1st Data Breach?

As per GDPR definition (under Article 4) a Personal Data Breach consists of

"... 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...";

therefore you may be certain that, no matter how "Secure" your Processing Activities are (Tools; Mechanisms and Processes), it is just a matter of time until you have one.

GDPR aims at ensuring Personal Data Security, Confidentiality and Privacy

Incidents will eventually happen, and some will be Data Breaches... the huge difference consists of the fact that if you have done "your homework", those will be limited in number and severity and you will be able to understand WHAT, WHY and HOW to mitigate and prevent them from happening again as well as properly report them as per the Legal Requirements.

So, let's go back to the GDPR definition of a Data Breach:

Compromised SECURITY - Security derives from the repositories in use, that host Personal Data; the Tools that aid in the Processing of it plus the Processes and Workflows; and the Communications infrastructure/ channels in use to share it.

The initial Corporate DPIA/ GDPR Compliance Project needs to address this context assessing not only the IT Landscape Security with the support of guidelines/ frameworks based on ISO 27001; 29157; other... but the way in which the company operates internally and communicates with its partners (Controllers/ Processors) and for that you need to address things such as Data Governance; other... even Business Continuity. And that means the DPIA should also contain "checkpoint elements" that derive from ISO 8000; 15489; 22301; other as applicable in your case.

But WHY ISO? GDPR does not say anything about ISO!

Well, yes... it does not! And I am not saying your company needs to become ISO Certified towards these "guidelines"... however, the ISO is a proven set of market standards and best practices, so why "reinvent the wheel"? Use the Audit Points/ framework, add it the context of GDPR and you are covered.

Destruction - If someone destroys by mistake (e.g. in a paper shredder) a document that contains a unique set of Personal Data/ information pertaining to one or more Data subjects (in the sense that there are no copies of that Data/ information)... that is a Data Breach... Likewise, if your CRM or other IT Tool has a severe incident and its Data Base becomes corrupt leading to the loss by destruction of Personal Data while no backups are available, that is also a Data Breach.

If you have done your initial assessment (Corporate DPIA/ GDPR Compliance Project) and used the ISO Audit Checkpoints, you have certainly raised potential risks and non-compliance points as well as required mitigation actions which significantly reduce the risk of having this type of incidents.

Let me give you some examples: you will have assessed that some IT Tool does not have backups, therefore if there is loss of information you have no way to retrieve/ restore it, hence you will define and set in place mitigation actions that ensure some sort of backup and restore capacity; you will also have defined some "document management" processes that will ensure anyone from the staff needs to do some "checks" before destroying paper-based information.

Loss - when one loses something... in this case, Personal Data/ information, the main risk derives from the fact that it becomes unaccounted for. Meaning, you are not able to know WHO has now access to it, and it only becomes worst (exponentially) as time goes by.

This is, in fact, one of the most critical points under a Corporate DPIA/ GDPR Compliance Project. The DPO must be very thorough in the internal assessment (as well as potentially towards some partners... Controllers/ Processors) of WHO moves around with information and HOW is it carried around (?!)

It is normal for people to save information locally stored in their "workstations"... a concept that nowadays implies laptops, tablets, and even smartphones. So, are they secure in case of loss? Should a local authentication "do the trick" or would it be advisable to have the equipment encrypted?... it certainly depends on the type and volume of Data carried around.

And what about pen drives and memory cards?... and "public" Cloud-Based storage drives?

Assess, document define mitigation actions and create Policies/ Operational Procedures informing/ training all staff members on those.

As the DPO, check all of this in detail... remember, (until we have AI as a fact) a machine will do whatever it is instructed to... whereas humans tend either to forget or get creative...

Alteration - another thing that constitutes a Data Breach consists of changing Personal Data where such change is either not supported by a Lawful Base or does not correspond to "reality".

Besides IT-related mistakes (which are not that common in this context), it is possible that a staff user may make a mistake and change some Personal Data. It is also possible that by accident or "honest mistake" someone gets Personal Data changed without a Lawful Base (having collected it from an "unauthorized source")... The only way you have, as a DPO, to ensure that such mistakes are mitigated is to assess the potentially critical points within existing Operational Workflows and define Processes/ Procedures that mitigate such risk having them informed (through training) to staff members.

This is one of the points that represent a significant risk and should be part of the Regular DPO Audits to the Departments for it purely implies the "human factor".

Unauthorized Disclosure - sometimes it is also the byproduct of an honest mistake, nevertheless still a Data Breach. A public school in the EU was fined before summer for having disclosed the students' addresses over its website public area... it was a mistake, nevertheless, anyone who visited that website would know that a give underaged student lives at a given address and that poses a significant risk to a child.

Again, the odds are that this will derive from human error and many times it derives from the fact that someone who has the role of "executing" something is just following instructions from someone else who either did a mistake or did not properly informed about HOW it should be done.

In this specific case, someone instructed the website developer to create a page where some information pertaining to grades would show up and the developer (who had been deemed not eligible to receive GDPR Basic Training) understood that all main student information should be published... so he did.

Nowadays many companies outsource non-core areas... such as web-development; now that is fine, nothing against it (by far). However, think not of staff and non-staff, but of the role that each "player" has in the Process and the inherent risk... it is better review the Operation Processes in detail and pay for the training of your outsourced developers (which by the way act as Processors) in GDPR Basics than to get a penalty right?

Access - one thing that exclusively depends on you dear DPO. Many companies have no established boundaries with regards to Customer information access by its staff members. Just a couple of examples:

• many are those cases where the guys from Logistics/ Distribution have access not only to the "address" and "order" of a given Customer but also other Personal Data like age; purchase backlog; expenditure over time; other... which is not relevant under the scope of their role in the company.
• Some medical clinics allow reception desk staff to access the medical records of patients.

Sorry to be the bearer of bad news but all of this configures a Data Breach.

So, as DPO WHAT should I do?

• Do you have an Incident Response Process and Team in place to address Personal Data Incidents and assess/ respond to them if a Data Breach?
• Have you been ahead of the GDPR Compliance Project?
• NO?! Have you audited it and checked the "findings"?
• Have the Mitigation Actions been implemented so far?
• Did staff get information and training on new relevant Policies and Processes/ workflow changes? (including the buy-in from Department Managers ?)
• Are there Data Processing Agreements in place with Processors and Controllers and do they mirror what must be crystal towards Personal Data Security, Confidentiality and Privacy assurance under individual/ common/ shared Processing activities?
• Last but not least... do you have a defined and working Regular Audits Schedule towards Departments/ Tools and Partners where you assess the accurate implementation of established Policies, measures, and contractual obligations?

That is WHAT you need to do.

Now remember that GDPR further defines with regards to Personal Data Breaches that:

• Recital 85 - "... if not addressed in an appropriate and timely manner, result in physical, material or non-material damage to natural persons such as loss of control over their personal data or limitation of their rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage ..."
• Recital 86 - "... The controller should communicate to the data subject a personal data breach, without undue delay, where that personal data breach is likely to result in a high risk to the rights and freedoms of the natural person in order to allow him or her to take the necessary precautions. ..."
• Recital 87 - "... It should be ascertained whether all appropriate technological protection and organizational measures have been implemented to establish immediately whether a personal data breach has taken place and to inform promptly the supervisory authority and the data subject. ..."

For further detail on HOW to Proceed upon being confronted with the event of a potential Data Breach, please refer to my other article https://www.dhirubhai.net/pulse/dpo-managing-incidents-vs-data-breaches-rui-serrano/