Third-party risk management: keeping control of your supplier chain

Almost every organisation depends on parties it does not control for its critical processes. Cloud hosting, software development, payroll, customer contact, and increasingly AI services. Outsourcing moves the execution, not the responsibility. Third-party risk management, usually shortened to TPRM, is how you keep control of the risks you moved out.

Why the pressure has increased

Two developments meet here. First, the chain got longer: your supplier has suppliers of its own, and an outage at a party you never contracted can take your service down. Second, regulation now sets requirements for supply chain control. NIS2 explicitly names supply chain security among the measures organisations must take (Article 21). DORA requires financial entities to maintain a register of all their ICT contracts and sets substantive requirements for contracts with providers supporting critical functions. The GDPR requires data processing agreements and an assessment of the guarantees a processor offers.

Start with a register

Without an overview, every assessment is arbitrary. A usable supplier register records, per party, the service delivered, the process depending on it, which data is processed and where, who owns the contract, and when the contract ends.

In practice that register does not appear in one go. Procurement knows the contracts, IT knows the integrations, and departments know the tools they bought themselves. That third group is usually the biggest blind spot, exactly as with AI tools.

Classify on impact, not on size

A supplier is not critical because the invoice is large. It is critical when you cannot meet your own obligations without it. Three questions set the class: what happens to our service if this party is down for a week, what data do they hold and how sensitive is it, and how easily could we move to an alternative.

That outcome drives the depth of your assessment. For the top tier you run a full review with supporting evidence and periodic reassessment. For the middle tier a questionnaire with sample verification is enough. For the bottom tier registration will do. Treat everything equally and you will have stopped maintaining it within six months.

Due diligence beyond the questionnaire

A completed questionnaire is a claim by the supplier, not evidence. Ask for assurance reports, and actually read them. With a SOC 2 or ISAE 3402 report, check four things: whether the service you buy falls inside the scope, which period was tested, whether the test results contain exceptions, and which controls the supplier expects from you. That last point, the complementary user entity controls, is where many organisations drop the ball: those controls have to sit in your own control environment.

With an ISO 27001 certificate, check the scope statement on the certificate itself. A certificate covering only the head office while the service runs from another country does not cover your risk. Also ask for a recent penetration test report, or its summary, and for how vulnerabilities are followed up.

What belongs in the contract

Contractual arrangements are the only control you fully own. Make sure they cover at minimum: the security requirements the supplier has to meet, an incident notification obligation with a concrete deadline, the right to audit or to receive an annual assurance report, arrangements on subcontracting and on being informed when subprocessors change, and an exit clause stating how you get your data back and in which format.

That exit clause is the one most often forgotten and the most valuable once a relationship sours. Agree a transition period as well, during which the supplier keeps delivering while you migrate.

Concentration and fourth parties

Twenty suppliers all running on the same cloud provider give you one outage scenario, not twenty. Map which underlying platforms your suppliers use. A contractual hook helps here too: the right to be informed when your supplier replaces a critical subcontractor.

Monitoring makes the difference

An assessment done at contract signature loses value quickly. Work with triggers rather than an annual cycle alone. A new assurance report, a reported incident, an acquisition of the supplier, a change in the service or in subprocessors, and an expiring certificate are all reasons to look again.

For major suppliers, track the operational side as well: service levels met and missed, how quickly they close vulnerabilities, and whether agreed reporting actually arrives. Reporting going quiet is a signal in itself.

Where TPRM stalls in practice

Three patterns keep coming back. A register that stops being maintained after the first inventory, so it no longer matches reality a year later. Assurance reports that get requested and filed without anyone reading the exceptions. And ownership that sits nowhere: procurement assumes security reviews it, security assumes procurement nailed it down contractually.

You fix that last one with an owner per supplier, not with another process.

Further reading: supply chain security, what sits in a SOC 2 report, what regulators expect from IT risk management and what NIS2 means in the Netherlands.