Evaluating Security Breaches

I observe that many organisations and companies still experience difficulties with recording, evaluating and reporting security breaches to their local Data Protection Authorities (DPA).

It is my observation, from reviewing many security breaches, most challenges arise from differences in understanding among colleagues and various departments of the same organisation on what a security breach is and how severe it can become for a data subject (aka. a person, who's personal information you process).

Another obstacle can arise from an online security breach form, that can be difficult to understand and fill in.

To make this process easier for Data Controllers (aka. your organisation) and to create a common language and framework of evaluation for the people, who have to review and report the security breaches - I propose this simple visual template for your organisation. It is inspired by my own template, that I use for reviewing incoming securing breaches at Danish DPA - Datatilsynet.

Using the template

Template is a A4 one page, that you can print to do the discussion and evaluation together in teams. It is an advantage, if the team consists of the DPO (Data Protection Officer), IT-security specialist and representative of the department that experienced the security breach.

Download the template from this article here English version and at the end Danish version.

Process

Step 1. Practicalities

Start by writing the case number and which department or departments are involved. This will tell you if you have involved relevant people in the evaluation of the security breach.

Step 2. Dates

Then record all relevant dates.

• Date of discovery of the security breach - when you realised that the breach has occurred.
• Date of the beginning of the security breach - when it actually started. It is quite often long before you actually discovered it.
• Date when the security breach was stopped by your organisation.
• Duration of the security breach (days or months or years). Duration is mesured from "date of the beginning" (not date of discovery, as a common minstake) and untill the the date, when the breach was stopped.

Step 3. Type and extent

Write down the type of personal information (general, confidential og sensitive information) and the amount of the persons affected by the security breach. Note what kind of persons affected by the security breach, for example adults or under-age minors. Define what type of the breach it is: Is it accidental or unlawful unauthorised transfer, transmission, disclosure, destruction or alteration of personal information?

I normally use 2 icons to help me visually structure information. The first icon with a person and 2 arrows represent the type of personal information that was affected. The second icon with 3 persons indicates the amount and cathegories of persons affected. You can develop your own symbols to help your colleagues better remember and evaluate situations.

Step 4. Technology involved

Identify what type of technology involved in the security breach. It could be server, that was hacked. An e-mails sent to a wrong person or without proper encryption. A computer that was stolen.

Here you also can describe whether the security breach occurred due to malware, lack of patching or any other kind of technical issue or a human error.

Step 5. Data Processor involved

If a Data Processor involved in the security breach - mark V in the yes-box and write down the name of the processor. If no data processor involved mark V in the no-box.

Step 6. Description

In your own words try to describe, what has actually happened and discuss with your team. The more detailed is the description, there better evaluation will be. It will also help you fill in the report to your local DPA with the adequate amount of information and details.

It is my professional experience that the more detailed is the description of the breach in your submission to the DPA - the more mature your organisation appear, which also influences how DPA reviews your report and how severe or mild it's final decision will be.

Step 7. Consequences

After you put all details in your description, you can make an evaluation of the consequences of the data breach. The important point here (and the most common mistake most organisations make) is that you should focus on the consequences for the person (and not your company). You should make a risk assessment to determine what kind of material and immaterial damages a person (or many persons) can experience as a result of your security breach. Consider immediate and long term consequences for the person.

Here you write down whether the breach resulted in loss of:

• Confidentiality
• Integrity or
• Availability

of personal information and how does it affect the person or persons.

A common mistake (nr 1.) that many organisations make here, is an assumption that the consequence for the person is non excistant, because the probability of misuse of personal information is evaluated very low. In this instance it is important to note, that probability and consequence of a risk are two independant of each other values. For example, your organisation har experiences a ransomware attack. You evaluate that probability of misuse of personal information of your customers is low, because you anticipate hacker were after money and not personal information. However, if the CIA of personal information was compromised, it could have devastating consequences for persons. Therefore, the risk is hign.

Another common mistake (nr 2.) is assumption that risks for the person are low, because the organisation has already stopped the breach. In this instance you should evaluate the actual consequences and the potential consequences. The risk to the CIA of personal information and to the persons is therefore evaluated based on what potentially could go wrong - because that is the basis for security measures, that your organisation should consider implementing to prevent similar security breaches.

Therefore here, you have to consider the overall risk (nr 1.) and the potential risk (nr 2.) to the person, when discussing this point with your colleagues. This is a crucial step in determining the severity and consequences of the security breach to the people, who's personal information your organisation processes.

This topic is very dear to my heart - so I will have to make a separate article on this topic of risk assessment, with a visual teplate off course ??.

Step 8. Technical and organisational measures

When discussing the security breach with your colleagues, make specific evaluation of what technical and organisational measures you have initiated and implemented to stop this particular breach. The more detailed you are in your report to DPA on this particular point, the better can DPA determined if you have put adequate measures in place.

Then make specific evaluation of what technical and organisational measures you will put in place as a result of this security breach, so that it wont happen again in the future. The more detailed you are in your report to DPA on this point, the better can DPA evaluate, how serious you take this breach and how responsible you are in managing it.

Step 9. Notifying the persons

After you have evaluated the risks to the persons, you have to make a decision on notifying them of the breach. If you decide to notify the, mark the date of the notification.

If you evaluate that notification is not necessary - then write down, why you have determined so. This step is often dismissed, but I would encourage you and your organisations to consider it properly, as attitude of your organisation toward notification of the persons/public of your compliance with data protection rules shows your responsibility (Art 5.).

There are a couple of common mistakes to avoid here. First is the misconseption, when companies choose not to inform people, because they already have implemented the measures to stop the security breach. In this situation, you have to look at the actual and potential risks to the CIA of the personal information, and not base your decision on how fast your organisatio is able to react to threats

Second misconseption is when many organisations choose not to notify persons of the security breach, if notification is too cumbersom, it is technically impossible to identify all persons etc. In this instance, many organiations use the inconvenience as an excuse not to notify persons. The right approach here is application of Article 34, part 3 c) - a public announcement.

Conclusion

This evaluation is not a substitute for a systematic registration of security breaches in your organisation, but it is a useful tool for creating common understanding among your colleagues what a security breach is and all the information that is relevant for registering, evaluating and reporting a security breach.

This visual template can help you remember ALL RELEVANT aspects of the security breach, so that you won't forget any vital details, when reporting it to your local DPA.

Feedback

If you find this template useful, have ideas for improvement or suggestions for other useful templates for your data protection and information security work - please don't hesitate to reach out to me here on LinkedIn. If you have modified this template and added other (for your organisation) relevant fields - please let me know. I would love to see it used and improved.

Danish version