Securing What You Don’t Control: What Mature Organisations Get Right About Supplier Risk

No organisation is an island. In cyber security, that’s not just a philosophical point. It’s a hard truth. Our dependencies, on software vendors, cloud services, hardware suppliers, logistics chains, consultants, and managed providers, are growing deeper and more interdependent. And with every new integration, procurement or digital connection, the potential surface area for compromise quietly expands.

Many of the organisations I’ve spoken with over the past few years already know this. Supply chain risk is not a new concept. What’s changing is the urgency. Attacks like SolarWinds, MOVEit and Kaseya were loud, public reminders that third-party compromise can have first-order effects. But the more difficult reality is that most supply chain weaknesses are not made visible through the headlines. They sit quietly in misconfigured APIs, shadow sub-processors, outsourced code modules, expired contracts, and informal working arrangements that don’t feature in the official risk register.

For security leaders, the challenge now is to move supply chain security from an abstract concern into a structured, accountable, and measurable part of organisational risk management. That means building the practices, relationships, and governance needed to understand what’s in the chain, assess how it might fail, and decide what level of trust is acceptable.

Supply Chain Risk Is Not a Technical Problem

To begin with, we have to recognise that this is not just a technology issue. It’s a governance issue, a procurement issue, and a leadership issue. Many of the risks we face don’t come from a supplier’s firewall. They come from the absence of shared expectations, unclear roles, inconsistent onboarding, and a tendency to trust vendors once they’re in the door without maintaining active oversight.

A healthy supply chain risk posture starts with having visibility over who your suppliers are and what they do. That sounds straightforward, but in large organisations the picture is often surprisingly incomplete. One business we worked with in the energy sector discovered it had more than 1,200 active suppliers, and no clear record of which ones had access to its operational systems.

Visibility alone isn’t enough. What matters is understanding where each supplier sits in the risk landscape. This means assessing not only the sensitivity of the data they handle, but also the criticality of the service they provide, the privileges they are granted, and the interdependencies that exist between them and others in your ecosystem. A payroll provider and a software development firm might both be third parties, but the risk profile and required controls are very different.

A Framework for Assurance, Not a Checklist

Once that mapping work begins, the next challenge is assurance. But assurance in this space has to be meaningful. Too often, supply chain due diligence relies on broad questionnaires that go unanswered or tick-box responses that are impossible to verify. What’s needed is a tiered, risk-based approach to assurance, one that reflects the nature of the service, the risk tolerance of the organisation, and the maturity of the supplier.

In high-risk contexts, assurance might include structured technical assessments, code reviews, penetration testing or collaborative tabletop exercises. In lower-risk contexts, it may be more about understanding how a supplier approaches their own governance and whether they’ve demonstrated responsiveness and transparency during incidents.

What matters is not whether a supplier can produce a security policy, but whether they understand their own risk profile and can demonstrate how it’s being actively managed.

In several of the more mature firms we’ve spoken with, assurance is now treated as an ongoing relationship, not a pre-contract hurdle. Suppliers are brought into threat intelligence exchanges. They’re invited to joint training sessions. Performance against SLAs is reviewed alongside incident metrics. This approach takes effort, but it helps shift the dynamic from policing to partnership.

Embedding Controls Through the Lifecycle

If you’re building or procuring software, the picture becomes even more complex. Software today is rarely written from scratch. It’s assembled, using open-source libraries, third-party SDKs, cloud functions, and increasingly, machine-generated code. Each of these components brings potential risk, especially when their provenance is unclear or their update cycles are misaligned with your own.

Modern development environments introduce the possibility of compromise through poisoned build chains, CI/CD pipeline misconfigurations, and unauthorised contributor access. What’s needed is not just secure coding but secure orchestration. And that means security teams must work closely with development, procurement and legal to define what “secure enough” looks like across the lifecycle, from design and acquisition through to deployment, patching and decommissioning.

In this context, contractual protections have a role. But contracts are not controls. You can’t enforce your way out of weak technical design. Nor can you rely on indemnity clauses to mitigate reputational damage. Where possible, expectations around security hygiene, patch timelines, vulnerability reporting and incident disclosure should be built into contracts and supported by processes that make it possible to verify compliance.

Resilience, Not Perfection

Perhaps the most important shift is one of mindset. You will not be able to secure every supplier. You will not be able to control every component in your supply chain. What you can do is build resilience, so that if something fails, it fails gracefully, visibly, and with enough time to respond.

That resilience starts with understanding your dependencies and prioritising the most critical ones. It involves designing with isolation in mind, so that supplier compromise doesn’t lead to cascading exposure. It requires knowing what logs to retain, how to detect lateral movement, and how to initiate coordinated responses when the impact crosses organisational lines.

And above all, it requires trust, not blind trust, but informed trust. That’s the role of the security leader: to help the business decide where trust is acceptable, where it must be verified, and where it cannot be relied upon at all.