Almost every business relies on a network of suppliers to develop, deliver and maintain its products and/or services. Working with third-party processors, such as a payment processor or CRM provider, will help streamline workflows and allow you to serve customers with ease.

However, as this supply chain grows, more people outside of your organisation will have access to your customers’ personal data. As a data controller, it’s your responsibility to ensure both you and your processors take the same approach to GDPR compliance.

If not, your processor(s) will become a weak link in your supply chain, putting you at risk of a data breach. In this blog, we’ll uncover how third-party relationships work under the GDPR and the consequences of non-compliance.

What Is a Third Party under the GDPR?

The term ‘third party’ refers to a ‘natural or legal person, public authority, agency or body other than the data subject, controller, processor and persons who, under the direct authority of the controller or processor, are authorised to process personal data.’ (UK GDPR, Article 4 (10).

Under this definition, a third party refers to an external company that handles personal data for a separate and distinct purpose outside the controller’s original basis for processing.

For the purposes of this blog, we are referring to third-party processors. These are data processors who work on behalf of a data controller and have their own obligations.

How Do Third-Party Relationships Work?

In our data processor vs controller guide, we discussed how compliance requirements can change depending on your level of involvement.

A third-party processor doesn’t have as much autonomy as the controller. The controller decides what information is processed and the lawful basis for doing so. As such, the controller must hold themselves and their processor accountable when fulfilling their GDPR obligations.

As outsourcing always comes with some form of risk, a controller and processor would have to agree to a Data Processing Agreement. The contract will include details such as:

• The subject matter and length of the processing
• The purpose of the processing
• The type of personal data
• The categories of data subject
• The controller’s responsibilities and rights

Several other clauses or terms must be included, which the ICO covers in detail.

Who Is Responsible for a Data Breach, a Controller or a Processor?

In most cases, the data processor is responsible for a data breach, either because of non-compliance or a reason outside their control. What the processor is liable for, however, will depend on the terms set out in your Data Processing Agreement.

After an investigation by the ICO, the processor may be subject to administrative fines and penalties. They may also be liable to the data controller for a breach of their contract. This is also the case if a sub-processor had caused the breach.

If you, the controller, didn’t have a contract in place, you too will be liable for non-compliance. Setting a contract is just one of your responsibilities as a controller, and failure to comply puts you at risk.

A controller-processor contract doesn’t give controllers immunity. Yes, they safeguard your business, but it’s not enough to lay the blame entirely on the processor. As a controller, your role is to hold processors accountable. What this means is that the issues leading up to the breach could’ve been avoided had the controller taken more responsibility.

Need GDPR Support? Speak to Our Data Protection Consultants

As a data protection consultancy, we can help your business simplify your compliance requirements, whether you’re a data controller or processor.

Contact our team to learn more about our data protection services today.