How to Prevent Supply Chain Attacks: What Actually Works in Third-Party Risk Management

What counts as a supply chain attack?

A supply chain attack is any breach where an attacker reaches an organisation through a supplier, vendor, service provider or software dependency rather than through its own systems directly. 

It isn't one attack type, it covers several distinct patterns, and each demands a different response:

• Supplier compromise: An attacker breaches a vendor and uses its access or systems to reach that vendor's customers directly.
• Software supply chain compromise: Malicious code is inserted into a dependency, build pipeline or update before it ever reaches you.
• Managed service provider compromise: An outsourced operator or cloud provider is compromised and used as a route to many customers at once.
• Fourth-party compromise: A supplier's own supplier is compromised, somewhere you have no direct relationship or audit right.
• Concentration risk: Several suppliers you treat as independent turn out to depend on the same cloud, identity or file-transfer provider, so one failure disrupts more than one relationship at once.

MOVEit Transfer showed the concentration risk pattern clearly. Organisations that never used the product directly still had exposure, because a supplier, processor or subcontractor did.

It’s also worth clarifying that a threat is the possibility of an incident. An incident requires confirmed impact to your organisation specifically. A breach at a supplier is not automatically an incident for you, and treating every supplier-side threat as your own incident creates panic and wasted effort without making anyone safer.

When something emerges further down the chain, the first job is establishing which of the two you're dealing with. Most of the time, at the point you hear about it, you're still assessing exposure, not managing an incident.

‍

Why attackers target suppliers instead of you directly

Attackers go through suppliers because the economics work in their favour. Breach one supplier once, and every organisation that trusts it becomes reachable. Breach one well-defended target directly, and the effort buys you exactly one outcome.

A supplier's access, software updates and administrator accounts are things you've already agreed to rely on, so an attacker who compromises the supplier inherits that trust rather than having to build it.

Most organisations can also name their direct suppliers but far fewer can say with confidence what those suppliers depend on, what data they hold, or which systems they can reach. Attackers exploit exactly that gap, because a security team can't defend what it hasn't mapped.

This is also why smaller, niche suppliers are increasingly the target rather than an afterthought. A supplier doesn't need to be large to be valuable to an attacker, it needs to be trusted, connected, and less well defended than the organisation it ultimately leads to.

The Synnovis attack on NHS pathology services in 2024 is a useful case here: a single service provider going down disrupted patient care across multiple NHS trusts, not because Synnovis itself was the target's business, but because its role made it a route to significant, wide-reaching impact.

Not every supplier needs the same level of scrutiny. But the attacker's target selection doesn't follow your org chart or your spend categories, so your assessment of where the risk sits shouldn't either.

‍

What security teams ask next

• How Do We Identify Critical Suppliers In Our Supply Chain?
• Fourth-Party Vendor Risk Management: How to See Beyond Direct Suppliers
• The Supplier Risk Assessment Process: Evidence, Review and Decision-Making
• Are We Exposed To Emerging Supply Chain Threats?
• Which Suppliers Should We Contact First During A Supply Chain Incident?
• What Does Good Supply Chain Threat Response Look Like?
• What Should Our TPRM Programme Cover End To End?

‍

Why annual questionnaires alone don't stop this

An annual security questionnaire tells you what a supplier's controls looked like on the day they filled it in, which is a reasonable snapshot but a bad substitute for knowing what's true now. Ownership changes hands, architecture gets rebuilt, a new subprocessor gets brought on without anyone thinking to flag it internally, and none of that surfaces until the next review cycle rolls around, if it surfaces at all.

Questionnaires aren't the problem. Asking a supplier structured questions about what they do, what data they hold, and what access they have is still the right instinct, and there's no good substitute for it. What causes the damage is everything that happens around that instinct: the same questions get asked in a slightly different format by every customer a supplier works with, so suppliers end up re-answering things they've already answered elsewhere, and by the time the responses land they're already describing a version of the supplier that's a few months out of date.

This matters most when something's actually gone wrong. A supplier discloses a vulnerability, and the instinct is to go and check your records, but if those records are a spreadsheet nobody's touched since renewal, checking them tells you less than you think it does. This is why so many teams end up doing the same thing when a threat emerges: emailing every supplier on the list at once, because there's no faster way to work out who actually needs a response first.

The solution to this isn't sending the same questionnaire more often. That just multiplies the effort on both sides without closing the gap that caused the problem in the first place. What actually changes the picture is treating supplier information as something that updates when something changes, rather than something a team goes back and re-collects on a calendar.

‍

Identify and tier your critical suppliers first

Most TPRM programmes start assessing suppliers before anyone's actually decided which ones matter. But this order needs to be corrected, because it's what decides where a stretched team spends its time.

• A critical supplier is one your business can't function without. If they go down, something essential stops.
• A high-risk supplier is a wider group: any supplier whose data, access or role could seriously damage the business, whether or not you'd even notice they'd gone offline.

The two groups overlap a lot, but they're not the same thing, and treating them as interchangeable is how genuinely dangerous suppliers slip through unnoticed. Synnovis, for example, was never going to top anyone's spend list, but when it went down, patient care was disrupted across multiple NHS trusts.

Working this out doesn't require a supplier's input at all.

Ask your own business three things:

• What does this supplier actually do for us?
• What data do they hold
• What access do they have into our systems?

Between those three you get availability, confidentiality, and a decent sense of what a hostile actor could do if that supplier were compromised.

Where this usually goes wrong is spend and impact. Sorting suppliers by cost feels efficient, but it waves through small suppliers who happen to hold sensitive data or sit deep inside a critical process.

And stopping at impact, without asking how likely a problem actually is, misses the suppliers in the middle: not your biggest names, but the ones with real exposure and weak security, which is often where the actual risk sits.

Read our full breakdown of how to work through this, including the impact and likelihood framework and (including a free interactive tool for scoring individual suppliers).

‍

Map what's behind your suppliers, not just the suppliers themselves

A fourth party is a supplier's supplier. You've got no contract with them, no right to audit them, and often no idea they exist, but your own supplier depends on them to keep running. None of that makes the risk go away. It just puts it somewhere you can't see.

Most organisations with a critical supplier have a backup lined up, a second supplier ready to take over if the first goes down, and the more mature ones actually test that switchover once a year to prove it works.

Here's where it falls apart: if the reason your primary supplier went down is a breach at a fourth party they share with your backup supplier, both go down together. The failover you tested doesn't help, because it was never really independent.

MOVEit Transfer is the real-world version of this. Plenty of organisations that had never touched the product lost service anyway, because a supplier or subcontractor two steps removed from them relied on it.

This is what that concentration looks like in practice: several suppliers you'd treat as separate, all sitting on top of the same underlying provider.

The reason fourth-party risk is genuinely harder to deal with than direct supplier risk isn't just distance, it's leverage. The contract, the audit rights, the ability to just pick up the phone, none of that extends past your direct supplier. Anything you know about what's underneath them depends on that supplier being asked the right questions and answering honestly, or on getting that picture from somewhere that doesn't rely on any one supplier telling you the truth.

‍

Put security into procurement before the contract is signed

Security requirements need to sit inside the buying decision, not after it. Once a contract's signed and a supplier's already integrated, you've lost almost all your leverage to insist on anything you didn't ask for up front.

The pattern that causes the most damage is procurement running ahead of security. A supplier gets selected, commercial terms get agreed, and security only gets pulled in once the relationship is close to live, at which point flagging a serious concern means unwinding a decision the business has already made.

By then, "no" is a much harder conversation than it needed to be. Building a basic set of trigger questions into procurement itself, before a security review is even scheduled, fixes most of this: does the supplier touch data, do they integrate with any of our systems, do we rely on them operationally. Answering those three early gives you a dataset to work from, so the deeper review only goes to suppliers who've actually shown a reason to need one, rather than every supplier that happens to be new.

The contract itself needs a handful of things a supplier should reasonably expect from any customer doing this properly: how quickly they're expected to notify you of an incident, whether they can disclose subprocessors, whether you have any right to ask for evidence rather than just take their word for it. This doesn’t need to be adversarial - a supplier that balks at basic notification terms or subprocessor disclosure is telling you something useful before you've even signed.

‍

Make assurance continuous, not calendar-based

A point-in-time questionnaire tells you what a supplier looked like on the day they answered it, and by the time you need that information most, it's usually out of date. The answer isn't assessing every supplier constantly, it's matching how often you look at a supplier to how much risk that supplier actually carries.

A periodic checkpoint still has a place. Having someone apply human judgement to a supplier's risk level at a sensible interval makes sense, and there's no reason to abandon that. What needs to change is what triggers the review.

Most teams default to a fixed calendar: every supplier gets reassessed once a year, regardless of whether anything about them has actually changed. But low-risk suppliers you're already comfortable with don't need annual attention at all, some barely need reviewing more than once. Your highest-risk and most critical suppliers need far more frequent attention than an annual cycle gives them, because a year is a long time for architecture, ownership or subprocessors to shift without anyone noticing.

The image below shows the difference. One calendar applied evenly to everyone treats a low-risk supplier and a high-risk supplier the same. A cadence set by risk reviews high-risk suppliers far more often, and layers in reviews triggered by an actual change, a contract renewal, a shift in how you use a supplier, a new regulatory requirement, rather than waiting for the date on the calendar to come round.

Most contracts already say a supplier must tell you if something material changes. Whether that clause actually gets acted on, whether anyone's watching for it and knows to update the assessment when it happens, is a different question, and for most organisations the honest answer is no.

None of this works without knowing which suppliers deserve that closer attention in the first place. A continuous model applied evenly across every supplier regardless of risk just recreates the same overload that made annual reviews unworkable to begin with, just more often.

‍

Know your exposure fast when a supplier incident hits

Speed comes down to one thing. Do you already know which suppliers matter, or are you working that out for the first time while something's actively happening? If you don't have a clear picture of your critical suppliers, you've got one option when a threat lands: email everyone and wait for replies.

If you already know which suppliers hold sensitive data, which have access into your systems, and which you can't function without, you can go straight to them and have a usable answer within hours instead of days.

That difference feeds directly into what you can actually decide. Should you cut off a supplier's access? Should you invoke a backup? What do you tell your board or your regulator? All of that depends on knowing your exposure quickly enough for the answer to still matter. If you're still working it out days later, you'll likely default to the safest, most disruptive option, not because it's right, but because you don't have enough to justify anything more targeted.

‍

How we support supply chain attack prevention at Risk Ledger

Everything above is achievable without any particular platform. It requires knowing your critical suppliers, keeping their information current, seeing past the first tier, and being able to move fast when something happens.

Where Risk Ledger fit is in making that workable at the scale most security teams actually operate at, without adding headcount to do it.

The starting point is the supplier side of the problem. A supplier on our network completes one assessment and that profile is reusable across every customer they work with, rather than answering a slightly different version of the same questions for each one.

That's what makes continuous assurance realistic instead of aspirational. When a supplier updates their profile, changes a control, or brings on a new subprocessor, that information is current for everyone connected to them, not sitting in a spreadsheet waiting for next year's review.

The same network structure is what makes fourth-party visibility possible without asking your suppliers to hand over spreadsheets you then have to cross-reference by hand. Because suppliers and their own suppliers sit on the same network, we can show you where a shared dependency exists. When a threat emerges, that same data means you're not starting from a blank supplier list. You already know which of your suppliers use the affected software, because their profiles say so, and you can go straight to the ones that matter instead of emailing everyone and waiting.

We don’t replace the judgement calls your team still needs to make. But Risk Ledger does remove the manual work of getting current, connected supplier data in front of the people making those calls, so the time your team has goes toward decisions rather than data collection.

If any part of this sounds like where your programme is stuck, book a demo and we'll show you how it works with your own supply chain.

‍

How to Prevent Supply Chain Attacks FAQs

What's the difference between a supply chain attack and a third-party data breach?

A third-party data breach usually means a supplier's own data or systems were compromised. A supply chain attack is broader: it covers any breach where the attacker used a supplier, vendor, service provider or software dependency as the route into your organisation, whether that's stolen access, tampered software, or a shared provider failing in a way that takes multiple "independent" suppliers down together.

Can you prevent a supply chain attack you don't know exists?

Not the specific attack, but you can reduce how exposed you are to one. Knowing which suppliers are critical, keeping their information current instead of relying on annual snapshots, and understanding what sits behind your direct suppliers all shrink the space an attacker has to work with, even against a threat nobody's identified yet.

How often should critical supplier assurance be refreshed?

By risk, not by date. Low-risk suppliers might need reviewing once a year or less. Critical and high-risk suppliers need far more frequent attention, and a real change, a new subprocessor, a contract renewal, a shift in how you use the supplier, is a better trigger than a fixed calendar date.

Is a backup supplier enough to prevent disruption?

Only if the backup doesn't share a critical dependency with your primary supplier. If both rely on the same fourth party and that fourth party goes down, the failover fails at the same moment you need it, which is exactly what happened with MOVEit Transfer.

‍

_Sources

^{NCSC's 12 principles of supply chain security 
CISA and FBI joint advisory on the MOVEit vulnerability
NHS England's account of the Synnovis cyber-attack
NIST's Cybersecurity Supply Chain Risk Management guidance
DORA's requirements on ICT third-party risk}