Security Incidents and Personal Data Breaches

Personal Data Breaches and Security Incidents: yes, they happen. This time we talk about those moments for which you think you are prepared and trained. In contrast, my professional experience suggests that, generally speaking, entities are never prepared sufficiently for a security incident.

 

Quick References and Terms

Primarily, I would like to mention the document I use here as reference:

  • Guía para la notificación de brechas de datos personales (link here). It’s in Spanish; so, if you need help, don’t hesitate to write us an email: we are your Privacy Manager in Spain, Europe.

Subsequently, some definitions.

  • Security Incident: A series of unexpected events that involves an attack at one or more sites. (Source: ISACA glossary).
  • Personal Data Breach: 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. (Source: art. 4.12., GDPR).

Therefore, every personal data breach is a security incident. Conversely, not every security incident is a personal data breach. You know, just like Zack once said: “Every thumb is a finger, but not every finger is a thumb”.

 

Things went wrong: what to do now

Let’s assume that a security incident affected also the personal data processed by our entity. Firstly, we need to assess the depth of the breach. Registering the following fields could be a good start:

  • Register starting and ending date. It is important to ensure that we respect the 72-hour term mentioned in art. 33, GDPR.
  • A description of what went wrong. At least, populate the information with what we know so far.
  • How we get aware of the breach.
  • Who reported to whom.
  • Date and hour of the breach (not, it is not the same information referred above. For any doubt, call us).
  • Processes affected.

And these are only the first basic steps. Let’s go deeper.

 

Personal Data accessed

After the mentioned first step, it is very useful to evaluate the type of data accessed. Ask yourself these questions:

  • First, who was processing the personal data? Your entity as a controller? Or were the data processed by a processor?
  • Then, the type of personal data compromised: health data, financial data, credentials?
  • Also, the population, roughly calculated, of the personal data accessed.
  • Additionally, register the plausible consequences for the data subjects.
  • Finally, the technical and organizational measures you put in place to contain the damage.

 

To Notify or Not To Notify

In similar fashion of a Hamlet-influenced privacy professional, it is now time to decide if you must notify the personal data breach to the competent privacy authority… or not.

It all depends on the question: is there a risk to the rights and freedoms of natural persons?

For spreadsheet fans, the question (Q1) could be written (sort of…) this way:

“If(AND(Q1=”Yes”);”Must Notify”, “No need to notify).

When do you need to notify also the data subjects affected? According to the art. 34, GDPR: “When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons…”

Are you still insecure about the risk calculation? Well, we have the right tools for you. Don’t be shy and contact us.

Personal Data Breach

Personal Data Breach