GDPR – Who’s Responsible for Data Security and Breach Notifications in the Client-Agency Relationship?

Welcome to the next in our series of GDPR posts exploring the practicalities of the GDPR in the client-agency relationship. In this part, we’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.

Data Security

First up is data security. As we’ve touched on in previous posts, there’s a shared responsibility from the Data Controllers and the Data Processors to ensure that data is stored, processed, and handled securely. For Data Controllers, it is important to only engage with Data Processors that can demonstrate not only compliance with the GDPR, but also “security of processing” standards.

There’s a range of security actions to consider, including pseudonymization 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 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.

Breach Notifications

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 whom. 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 a “personal data breach”. Under the GDPR, this is classified as a breach of security that causes the accidental or unlawful destruction, loss, modification, unauthorized access, or unauthorized 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’s some clear directions on what the Data Controller should do and what the Data Processor should do.

For the Data Controller, they have two sets of notifications.

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 outline the nature of the breach clearly, 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 relates 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 field 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 mainly, but not exclusively:

• identifying the appropriate monitoring tools
• identifying 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 the tip of the iceberg, and there’s 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 that 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.

What I would love to know is how far you have got with the four bullet points above. Were there any key elements that you had trouble solving? Please share your thoughts on the points raised in this article and any of your experiences in the comments section below. The topic of GDPR is one that is dear to our hearts. Check out some of the critical points you should be addressing here.

DISCLAIMER: All data and information provided in this blog post are for informational purposes only. Kentico makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information contained herein. We recommend consulting with a lawyer for any legal advice pertaining to GDPR compliance.