Uncovering hidden risk within your supply chain: Part two

Thought leadership

Kevin Tunison, Data Protection Officer, Egress Software Technologies

As a DPO or member of a security team, you’ll have to deal with various departments making requests to bring in new suppliers. Depending on the size of an organisation, it’s sometimes the case that this happens ‘under the radar’ and you find out after the fact. 

That’s why the first part of this series focussed on internal communications and understanding who is likely to be engaging with suppliers. If you haven’t read part 1 in this series, you might want to check it out here.

Finding risk in your supply chain

Let’s picture a fictitious scenario of how risk can present itself in the supply chain, and what you can do to better manage it.

A member of a marketing team requests purchasing a new lead generation tool. Her manager is quite excited at the prospect of being able to grow the customer base and has had a number of discussions with their business development representative. What next?

After reviewing the company’s website, you find that the size of the organisation is much smaller than what their branding suggests. Further, there is little information explaining how they have derived their wonderful source of sales leads. There are two main risks present in this scenario:

  • A lack of certifications and privacy notices giving assurance they protect or acquire their data securely, or where said data resides
  • A lack of commitment in their draft contract regarding their data protection responsibilities

When you identify that a potential vendor lacks certifications, or they operate in a jurisdiction with no regulation, it is important at this stage to clearly advise that an impact assessment is required. 

This approach, while helping evidence compliance with various data protection laws, gives you the opportunity to contact their privacy officer and confirm whether they have credentials that provide assurances for handling data securely.

These come in many forms but a few to look out for are ISO 27001, SOC reports, SSAE reports, Cyber Essentials+, and Privacy Shield. You’ll also want to know whether they are registered with the relevant oversight regulator in their country of operation.

What to watch out for in contracts

Often when reviewing contracts, clauses known as standard contractual clauses (SCCs) should be referenced. If these are missing/lacking, or there is no offer of a data processing addendum, these are signs of an organisation that presents significant risk to your own.

Where SCCs are present, pay particular attention to how they describe the location of where data will be stored or transferred.  Quite often these will be vague and refer to sharing information with chosen partners as part of their own legitimate purposes. But they will not provide the detail of what those purposes are and how they are justified. 

Also, focus on how data retention is described. Sometimes this can be very well defined. At other times, it can be vague or non-existent. There’s a problem if they don’t give you a clear understanding of what a supplier is doing to either enable you to delete data or show transparency in their data deletion activities.

This presents a risk that your data may be kept longer than needed and makes you more likely to experience a data breach.

Risk can be very well hidden

The second example scenario I’ll run through is more technical and focuses on how even the most robust due diligence cannot mitigate all supply chain risk. Imagine your organisation has recently moved a key line of business application into the cloud.

You went through a lengthy procurement, due diligence, and negotiation process. Upon contracts being signed and a clearly laid out statement of work agreed, the migration is carried out. You are satisfied you understand the suppliers’ entire supply chain, and where data may reside in third countries such as Singapore, Japan, or the UAE.

You have the necessary SCCs in place, and penetration testing results showed vulnerabilities that were since remediated. The service is now operational, and the organisation is benefiting from its new product in many ways.

Problems often emerge later 

After 6 months, you notice that a little-known IT company has hit the headlines with a significant vulnerability. In reviewing your own risk, the supplier is not listed as a sub-processor in your supply chain. A couple of weeks pass and a colleague mentions that your organisation has a suspected security incident. 

After much investigation, it’s found that the recently onboarded solution did in fact make use of the little-known IT company and the vulnerability found its way into the product you use and has been exploited. It is a very bad day.

An entire week of operations is halted until the breach is resolved and the necessary communications with data subjects, suppliers, and regulatory bodies are completed. During the lessons learned, it was found that your main supplier had not published their updated supply chain. 

Neither had contact been made requesting them to confirm any changes to their supply chain. This was partly due to the implementation not being up for review yet – but it was also due to not asking the question of the supplier sooner.

How to better address risk

So, what could we have done to better manage the risk in our above scenario? The answer will be slightly different in every organisation, but by and large we can all ensure there is someone in our organisation who is routinely engaged with a supplier to ask security related questions. 

Make sure your organisation goes out of its way to ask suppliers questions rather than looking at (and blindly trusting) what is published on their website. Find out the dates for their regular vulnerability/health checks and ask to see those reports you requested at the beginning of due diligence. 

These actions do not remove the risk entirely, but by being more frequent and proactive they can help ensure you’re better equipped with accurate information.

You might also be interested in ...