The Good

Some suppliers can really make you happy. We’ve for example seen some suppliers that would supply reports from years of pentesting, including details on findings and solutions. They also provided insights into what risks they had accepted. With that information, you as a customer can determine if any additional actions are necessary.

In another case, we saw the supplier organize a session with most of its customers to share their lessons learned from our ransomware resilience program with their customers. They specifically called them out to change certain settings that they, as their supplier, could not fix for them.
 

The Bad

Sadly, we’ve also seen the exact opposite happen with suppliers. We’ve seen for example that a pentest was repeatedly postponed, and then during testing, we noticed the environment had not been patched for 4 years. Only after the initial date of pentest did the supplier attempt to secure the environment.

We’ve also seen many cases where the systems were deployed with default insecure settings, default passwords, and sometimes even testing accounts were still active in production environments.

Sometimes there are also suppliers that try to “dodge” the bullet. For example, by actively blocking the IP address of the pentesters, specifically blocking the tester submitted payloads in their firewalls/WAFs, or turning specific vulnerable systems off during a test, so they won’t end up in the results.

The Ugly

Somewhere between the good and the bad, there is the ugly. Which are suppliers that you may initially be very happy with, but later on had turned into a rather sour relationship. Quite a number of suppliers have responded to our pentest reports with something along the lines of “security was not part of the requirements” usually followed by a “we can fix it, but for a hefty price increase”.

We also frequently see that the communication and mainly the expectation management between the supplier and the consumer doesn’t work. The customer expects one thing, and the supplier in practice never committed to that expectation. Because of this mismatch, conflict often occurs.

There are also cases where changes in the infrastructure or configuration of systems can cause issues with existing third party suppliers. We’ve for example seen several cases where a third party monitoring service was unable to detect even the most basic attacks due to changes to systems and network configurations, causing major blind spots for their service.

We’ve also seen this happen the other way around, where a supplier tries to convince their customer to increase their security, but the customer refuses to do so for various motives. In these cases, if an incident happens, it can get very messy and lead to many years of legal fighting.

Finally, there’s also the SLA. Typically suppliers do their best to follow their SLAs and ensure all tickets are handled within that time frame. However, sometimes in a crisis, you need things to happen much faster. We’ve for example seen cases where a ransomware attack on a limited amount of folders was marked as a medium priority issue, with 30 days in the SLA to address the problem. I’m fairly certain that any CISO or incident response personnel would have set a completely different priority level there.

What To Do?

The above are just some of the many examples we see in our daily work. While there is no one-size-fits-all solution for supply chain management, we believe that for almost all supplier consumer relations, the following points are key:

Expectation management

• Don’t assume your supplier does things for you, or knows about threats targeting you, discuss it explicitly.
• Ask your supplier if there are any things you should do.

Proving/showing they are in control

• Pentest reports & solutions, audit reports (ISO27k, SOC2), sectoral stamps of approval.
• Do a pentest together

Having the right lines of communication

• Operational people can directly talk to other operational people
• Know how to reach each other during a crisis.

Providing a mandate

• What can a supplier do without your permission (especially during a crisis situation or for security providing vendors) and when must he obtain permission first, and who is authorized to give that permission?

Setting security requirements during procurement

• While it should be default to have security, it’s often not, so it’s best to note this as an explicit demand in any procurement processes. Furthermore, it also helps to get the subject matter experts involved in procurement as they may come-up with different additional requirements or can review the content of incoming proposals.

Put it all in writing

• If things go well, you rarely ever need the paperwork, but all relationships have some level of friction every now and then. It helps to have paperwork with agreements and commitments to fall back to.

About the Author

Willem Westerhof is Team Manager Security Specialists at Bureau Veritas Cybersecurity with nearly 10 years of experience in offensive security. He has led high-impact projects across critical infrastructure and the Dutch government, including politically sensitive and confidential assignments recognized at national and European level.

Known for bridging technical depth with clear communication, Willem is a frequent speaker and advisor on cybersecurity. His passion for the field extends beyond client work into research, publications, and active contributions to the wider security community.