Welcome to the third in our series of GDPR posts exploring the practicalities of the GDPR in the client-agency relationship. In this edition, I’ll be delving into data breaches. Data security is a key theme within the GDPR and there are much stricter obligations on Data Processors and Controllers alongside guidance. We can split this into two parts – data security and breach notifications.
First up is data security. As I’ve touched on in previous posts, there’s a shared responsibility from the Data Controllers (clients) and the Data Processors (agencies) to ensure that data is stored, processed and handled securely. For Data Controllers (clients), it is important to only engage with Data Processors who can demonstrate not only compliance with the GDPR but also “security of processing” standards.
There’s a range of security actions to consider, including pseudonymisation of user data, security around processing systems and services, restoration of data following any incidents and evaluation processes.
Referring to our first post, processes and standards that are agreed between the client and the agency are key here. While they make up a small part of the overall working relationship between the client and the agency, they are crucial in achieving compliance.
Agreeing on these standards does not need to be an overly complex process. The Data Processor/agency will have standards surrounding data security – drawn from coding standards, encryption standards and OWASP.
Working in collaboration with the agency, the Data Protection Officer (and the Data Controller in general) can work to understand the standards in place and use these as the foundation for setting project-specific and account-specific processes and standards to enable current and future digital projects to achieve compliance.
Next up is the tricky world of breach notifications. With the murky waters of responsibility in the past, it was difficult to know who should be notifying who. The GDPR has clarified this considerably and it is easier to understand exactly what a breach is and who needs to do what.
Let’s start with the notion of the “personal data breach”. Under the GDPR, this is classified as a breach of security that causes the accidental or unlawful destruction, loss, modification, unauthorised access or unauthorised disclosure of personal data that is being held, transmitted or processed.
The notifications we need in place all hook into this definition of a “personal data breach”. There are some clear directions on what the Data Controller should do and what the Data Processor should do.
The most common relates to the supervising authority. They must notify the supervisory authority (e.g. ICO in the case of the UK) within 72 hours of becoming aware of the breach. If notification isn’t made within 72 hours, there has to be a very good reason. These notifications need to clearly outline the nature of the breach, provide contact details of the relevant people at the Data Controller (including the Data Protection Officer), describe the likely consequences of the breach and explain how you are going to resolve the breach.
The second is to your customers. This only applies when the breach in question is likely to introduce a high risk to the “rights and freedoms” of your customers. You need to communicate the nature of the breach and how you are going to resolve it as soon as possible.
There’s an exemption around this where notice is not required if the breach is unlikely to risk the rights and freedoms of your customers. It’s a big area of debate and creates a bit of grey area. The safest bet is to stick to your notifications.
For the Data Processor, their responsibility is to notify the Data Controller as soon as they become aware of the breach but they have no other notification or reporting obligation under the GDPR.
That covers the requirements of the GDPR but the question is how it should work in practice. Like with most things GDPR-related, the key is communication and collaboration. The Data Controller and Data Processor need to work together to put in place the processes and tools that will make those notifications as easy as they can be. This is going to include:
– Identifying the appropriate monitoring tools
– Identify processes for routine breach checks
– Establishing a documented procedure for the agency (Data Processor) to report breaches- complete with audit trail!
– Agreeing upon SLAs to cover notifications between the agency (Data Processor) and the client (Data Controller)
This is obviously just the tip of the iceberg and there are all sorts of other processes that the Data Controller is going to need in place. But hopefully, this gives you a starting point in at least ensuring alignment between yourself and your agency.
Hopefully, this has given you some ideas on the topics to cover with your client/agency for data security and breaches. In our next post, we’ll be diving into the concept of explicit consent.