Best practices for third-party risk management
Ten years of client engagements distilled into what an effective third-party risk programme actually contains — from a complete inventory and risk-based due diligence to SBOMs, continuous monitoring and governance aligned to NIST 800-161, ISO 27036, NIS2 and DORA.
We have argued that third-party risk is cheap to manage and ruinous to ignore. This is the companion piece: not why, but how. Across a decade of client engagements — building programmes, auditing them, and cleaning up after the ones that were never really there — the same practices separate the third-party risk management (TPRM) programmes that hold from the ones that give a false sense of safety.
An effective programme is not a spreadsheet of signed questionnaires. It is a living set of controls that covers the supplier relationship from before it starts to after it ends. Here is what ten years of engagements say it should contain.
1. A complete inventory — including fourth parties
Everything starts here, and most programmes are already incomplete at this first step. You need a complete, current inventory of all third parties — and of the critical fourth parties your suppliers themselves depend on. The concentration risk of everyone quietly relying on the same handful of providers is invisible until you map it. You cannot manage a relationship you have not written down, and the breach almost always comes through the one that was missing from the list.
2. Risk-based due diligence before onboarding
Assess before you grant access, not after something goes wrong — and make the effort proportionate to the risk. That means security questionnaires for every supplier, and independent assurance for the ones that matter: an ISO 27001 certificate or a SOC 2 report where appropriate, rather than taking a vendor’s word for their own security. Due diligence at onboarding is the cheapest point of leverage you will ever have; it is far easier to set the bar before a contract is signed than to raise it afterwards.
3. Strong contractual security requirements
The contract is where good intentions become obligations. The programmes that hold bake security into the paper: breach-notification timelines that are measured in hours, not discovered in the press; audit rights so you can verify rather than trust; vulnerability-management expectations; and clear data-handling requirements covering location, encryption, retention and sub-processors. What is not in the contract is not enforceable — and leverage is highest before you sign.
4. Least-privilege access for every vendor
Treat vendor access exactly as you would treat your own — because to an attacker it is the same door. That means least privilege by default, multi-factor authentication on every vendor account, just-in-time access so standing credentials do not sit waiting to be abused, and network segmentation so a compromised supplier reaches a contained zone rather than your whole estate. Most supply-chain intrusions are, at heart, an access-control failure wearing a vendor’s badge.
5. Continuous monitoring of vendor posture
A supplier’s security is a moving target, so a one-time assessment is a snapshot of a situation that has already changed. Mature programmes monitor continuously: vendor security posture over time, threat intelligence on suppliers and their sectors, and exposed vulnerabilities on their external attack surface. The goal is to learn a supplier has a problem from your own monitoring — not from their breach notification, or worse, from your own.
6. Formal software supply-chain controls
The software your suppliers ship is its own attack surface, and the last decade’s most far-reaching incidents rode in through it. Effective programmes apply formal controls: software bills of materials (SBOMs) so you know what is actually inside the components you run, code-signing verification so you can trust that software is what it claims to be, and secure update processes so a routine update cannot become a delivery mechanism for an implant. Knowing your dependencies is no longer optional.
7. Regular reassessment and joint incident rehearsals
Onboarding assurance decays. Critical suppliers need regular reassessment, not a certificate filed once and forgotten. And because a supplier will eventually have an incident, the strongest programmes run coordinated incident-response exercises with key vendors — rehearsing detection, notification and response together, before it is real. The first time you test how a critical supplier behaves in a crisis should not be during one.
8. Governance aligned to recognised frameworks
Finally, the whole thing needs ongoing governance anchored to established standards rather than reinvented in-house. The engagements that endure align to frameworks such as NIST SP 800-161 (cyber supply-chain risk management), ISO/IEC 27036 (information security for supplier relationships), and, where they apply, regulatory regimes such as NIS2 and DORA. Frameworks turn a set of good intentions into a repeatable, auditable, defensible programme — and, increasingly in regulated sectors, into a legal obligation.
The shift these practices represent
Taken together, these practices demonstrate something the last decade has made unarguable: third-party risk management is no longer just a procurement or compliance activity — it is a core component of cybersecurity and operational resilience. A weakness in a single trusted supplier can rapidly become an enterprise-wide, or even global, security incident. Programmes that still treat vendors as a paperwork exercise are managing the wrong risk at the wrong altitude.
The good news, and the theme running through all ten years of this work, is that none of it is exotic. It is disciplined, unglamorous engineering applied consistently — the same quality that turns a compliance obligation into genuine business value and real resilience.
How we help
We help organisations build TPRM programmes that are complete and proportionate: mapping every third- and fourth-party touchpoint, standing up risk-based due diligence, contractual, access and monitoring controls, software supply-chain assurance, and governance aligned to the right frameworks — folded into wider cyber security and operational-resilience work rather than bolted on beside it.
Want a third-party risk programme built on what actually works? Get in touch.