Supply Chain Breaches

Published 14 noviembre 2022

The Hazards

In the modern world, most organisations rely on a complex network of suppliers and vendors in order to provide products, systems and services. This is particularly the case with sub-contracting and outsourcing business models which require multiple parties to work together in order to achieve the desired outcome. At the risk of stating the obvious, any chain is only as strong as its weakest link. Ensuring the integrity and resilience of each link within the supply chain can sometimes be a challenge for risk managers.

The National Cyber Security Centre (NCSC) created a series of 12 principles designed to assist parties in understanding supply chain risks and establishing effective control and oversight of their supply chains. Typical examples of supply chain threats include those posed by reliance on third party software providers, website builders, thirds party data stores and attacks designed to target particular companies or industries (or “watering hole attacks”).

One of the more highly publicised incidents impacting an organisation that was connected with thousands of clients, principally in the education and charities sector, was experienced by Blackbaud, a US based software company and not for profit technology company. Blackbaud’s stated mission of helping social good companies do more gave rise to the company providing tools such as Raiser’s Edge fundraising software and CRM systems, marketing tools, financial support and more.

In May 2020, Blackbaud’s cyber security team identified that a ransomware attack had been in progress, potentially impacting millions of customer details stored on their systems. Basic personal identifier information, special category data including financial information, credit card details, social security numbers and name/password combinations were also impacted.

The effect of the ransomware attack was felt worldwide, given that Blackbaud’s roster included thousands of healthcare organisations, charities, education establishments, churches and other non-profit organisations, many of whom stored millions of records. The incident was publicised in international media leaving clients to face a whole series of questions from potentially impacted data subjects wanting to understand what the ramifications for them might be. It also led to multiple notifications to data protection regulators globally, illustrating how an event affecting a single organisation can spread to have a material effect on a series of related organisations in the same supply chain network.

A recent example in the insurance industry relates to a cyber-attack suffered by the Davies Group. It has been reported in the insurance press and is believed to have impacted a number of insurance carriers who contracted with Davies for the provision of various outsourced services. The impact of this is still being understood, but it illustrates the challenges posed by a single party in the supply chain suffering a data breach when they themselves are connected to multiple clients.

Top tips for your contracts to mitigate the risks

Although it will be difficult to avoid many of the consequences of a supply chain breach, there are certain things you can put in place in your contracts with your supply chain to reduce the burden of dealing with a supply chain breach. These include:

1. Clarity on supply chain designations

Is your contract clear on whether your supplier is a controller or processor?

One of the key problem areas in recent supply chain breaches we have been involved in is that the contracts with your supply chain is not clear on this front. Often there is no designation at all or suppliers are designated as a processor when they are clearly a controller.

Where it is not clear what the designations of your supplier are, it also won’t be clear who is responsible in the event the supplier suffers a personal data breach, including in respect of obligations such as regulator notifications.

Where a supplier is designated as a processor, but they are clearly in practice acting as a controller:

• you may be deemed to have regulatory responsibility for a breach you have no practical control over, including not be able to properly investigate or remediate the breach; or
• the supplier will act as a controller in dealing with breach and notification, in contradiction to what the contract says. In these cases you will be left unclear as to your notification obligations.

So, how can we mitigate these risks?

When entering into contracts with your suppliers, really consider the services and their nature or the nature of the supplier themselves, should they be a controller or a processor.

This subject merits and entire article in itself so we won’t go into too much detail here, but essentially the more control or discretion a supplier has or where they or the activities they carry out are regulated or professional in nature, the more likely it will be that they are a controller.

Once you have determined (and agreed, often the more challenging exercise) the appropriate designation, this should be clearly set out in the contract.

Where a supplier is providing more than one type of services for which they hold different designations, the contract needs to be clear where the line is drawn and it needs to be possible in the case of clearly separate, different or segregated data, so that it is clear which designation applies in the case of breach.

2. Clarity on responsibility for notification

Usually flowing from designation will flow the responsibility for determining whether a breach is notifiable under the UK GDPR and then the responsibility for actually making a notification for such breach.

However, it may be useful to ensure the contract is clear on which party will be responsible for actually making the notification if required, particularly where you might require a processor supplier to actually make the notification or cooperate with you in making one.

3. Clarity on who needs to be notified of a breach – points of contact

One of the other key issues in respect of a supply chain breach, is how will you actually know that a breach has taken place, to be able to assess whether it is notifiable and any other actions that might be required.

We have had a number of instances recently where the wrong person / entity within a group has been notified of the breach meaning there has been a delay in assessing the breach and making notification.

The contract should be clear how breaches should be notified, to who, and the timeframe for doing so.

When looking at this you should consider future proofing your points of contact, for example also requiring notification to a generic mailbox such as dpo@company.com as well as any other contacts. This should also be kept under review to ensure it remains accurate, and your supplier’s awareness of the notification requirements should be reviewed at any audit/review points to minimise the risk of misdirected notifications.

4. Onwards notification requirements

When considering how you can use contracts to mitigate your risks in the event of a supply chain breach, as well as looking at your contract with the supply chain itself, you should also look at your contracts with your own clients.

Consider whether there are any upwards notification requirements to clients in respect of any breach suffered by your supply chain.

Many client contracts will require notification where you have suffered a breach, even where you act as a controller for your clients, but is it clear whether the notification requirement only applies to breaches you suffer, or could the wording be interpreted as applying to breaches suffered by your supply chain as well. Ideally you would limit the notification requirements to your own breaches.

Linked to this is whether the notification requirement applies to breaches suffered in respect of all data processed under or in connection with the contract (i.e. contract/account management data as well as any client data) or just client data. Ideally it would be limited to the latter so breaches which effect client account contact details etc are not caught, as often this data is held separately to actual client data that might be the subject of the service provided.

You should also consider whether your client contracts require notification of all breaches suffered, or just those that are determined to meet the threshold for notification. If I was negotiating for one of my clients I would want notifications of all actual and suspected breaches, but if you are looking at your client contracts you would want to limit notification to notifiable breaches only.

5. Level of oversight required

Even in an arrangement where a supplier is a controller, where they are carrying out more typical processor type tasks but due to their nature or the nature of the activities (e.g. they are regulated / of a professional nature) they are designated as a controller, you may still wish to have oversight / control of breach remediation and notification activities, so you are notified of all breaches and have input into determining and making notification.

Whereas in some arrangements where a supplier is a controller you may be happy for them to be solely responsible and take the lead and only be only notified of notifiable breaches.

There will not necessarily be a standard approach, and you should consider on a supplier by supplier basis what is appropriate.