Week 4 of 8 – Breach & Security Response

How does GDPR apply to your organisation?

This is week four of the GDPR walkthrough – we’ve already covered Legality & Consent, Data Mapping and running a Data Protection Impact Analysis and this week we are going to focus on what needs to be done ahead, during and after a breach. Your organisation will undoubtedly have response processes from security incident response to disaster recovery, so this week will make sure that those incorporate the additional requirements laid down by GDPR.

What are the expectations?

Unfortunately, Data Breaches have become commonplace for organisations, so GDPR emphasizes the need for well-documented incident response plan and breach management processes and the ability to demonstrate resilience as required.

The expectation is that Data Controllers take appropriate technical and organisational measures to ensure that processing is secure – in other words:

* design fit-for-purpose security considering the nature of the data

* assign and communicate information security responsibility within your organisation

* get the right security in place, underpinned by robust policies and procedures

* have a well-rehearsed incident response plan in place

In the event of a breach, then there are expectations on the Data Controller that GDPR stipulates:

1. The Supervisory Authority (the Information Commissioner’s Office in the UK) needs to be notified within 72 hours of the Data Controller becoming aware of the data breach. If it is not notified within that time, an explanation why needs to be given

2. The Data Subject whose data has been breached, needs to be notified ‘without undue delay’ of the breach along with the nature of the exposure and any recommendations that may need to be given to the data subject

How can your organisation meet these requirements?

It is clear that ISO27001 (Information Security Management System) will address a lot of the expectation of GDPR in this area. The implementation of a robust information security management system and certification will provide assurance to interested parties that data is being handled securely and the processes around the handling are mature and adequate. Of course, gaining ISO27001 certification is a project in itself, but setting that as a target and working towards it will address many areas of GDPR leaving you with a much-reduced set of actions to become compliant.

ISO27001 aside, if there is a security incident, then the question is what information was breached? If your organisation does not currently use one, consider a breach analytics package which offers the ability to respond quickly with knowledge of what records were accessed during the incident.

Another way of reducing risk and actually avoiding the need to report incidents altogether is to apply ‘pseudonymisation’ to the PII. Pseudonymisation is a procedure by which the most identifying fields within a data record are replaced by one or more artificial identifiers, or pseudonyms. As part of the Data Mapping exercise consider if the data really needs to be held in an identifiable format or if pseudonymisation can be applied. If there is a breach, then the severity is much reduced provided the process has meant the data cannot be attributed to an individual. On a related note, anonymisation is where data is irreversibly manipulated to prevent the identification of subjects, so is actually stronger in terms of securing the handling of PII and as such, anonymised data is not relevant for GDPR.

GDPR encourages these practices where possible and makes exceptions throughout for data that is pseudonymised or anonymised.

The communication processes need to be in place so that a channel is in place with the Supervisory Authority (SA) and the data subjects themselves in the event of a data breach. These processes need to be documented, communicated and rehearsed. The Data Protection Officer (DPO) will typically handle the communications with the SA if you have one in your organisation.

Summary of Breach & Security Response

The is no way around it, but getting the security and associated processes in place is fundamental to securing the PII. Having robust security will mean that the likelihood of a breach in much reduced, so demand for communication channels to the SA etc. will hopefully not be required.

But to make sure that all angles are covered, look at the following areas as part of your review of this section:

* Explore the implementation of ISO27001

* Look at pseudonymisation or anonymisation of as much of the PII as possible – if the data cannot be traced to an individual then it ceases to be PII

* Consider implementing a Breach Analytics system which can help identify what data is at risk to a breach, as well as what has been accessed in the event of a breach

* Develop, test and communicate the response plans including communications to the SA and to Data Subjects, bearing in mind the time limits laid down in GDPR

Need some help?

Having now followed half of the sections, the understanding of what is required should be starting to form. You will undoubtedly have recognised things you do well and things that need to be improved. If you would like to have that independently and formally ratified now or at the end of the 8 weeks, Intersys Compliance can run a gap analysis for you and produce a prioritised list of actions to get on with for each of the areas. Please drop Intersys Compliance a line for a chat or some guidance.

Next week – five of eight:

Next week we will focus on Securing the Supply Chain.

Any questions contact about this week or any other GDPR topic, please contact graeme.riley@intersyscompliance.com

Graeme Riley is an experienced Global CIO with extensive experience in IT Security and Data Protection. He is currently a Director at Intersys Compliance Ltd.