Third-party risk management: supplier management that passes an audit

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. This article describes how to set up that process and, just as important, what an auditor will later want to see of it.

Where the requirement comes from

Supplier management appears in almost every framework we audit against, and each one words it differently. ISO 27001:2022 devotes five Annex A controls to it, 5.19 through 5.23, covering the policy for supplier relationships, the terms in supplier agreements, the ICT supply chain, monitoring and review of supplier services, and the use of cloud services. In SOC 2 it sits under CC9.2, which requires the entity to assess and manage risks associated with vendors and business partners. NIS2 and the Dutch Cyberbeveiligingswet list supply chain security among the duty-of-care categories, including the relationship with direct suppliers. DORA goes furthest: a register of information covering all contractual arrangements for ICT services, mandatory contract clauses, and an exit strategy for services supporting critical or important functions. And the GDPR requires in Article 28 that you only engage processors providing sufficient guarantees, with an audit right and approval of sub-processors written into the processing agreement.

The frameworks share one starting point: you establish how a supplier is controlled, and you can show afterwards how you did it. How NIS2 works out in the Netherlands and what DORA requires of financial entities are covered in separate articles. What follows is the process that is the same under all of them.

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, when the contract ends, and the date of the last review. Organisations under DORA need more, including the supplier's identification code, its country of establishment and the subcontractors involved in delivering the service.

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. An auditor testing the register for completeness compares it with an independent source: the creditor list from the finance system, the SSO integrations in the identity provider, or the DNS and firewall rules. Every party that appears there and not in the register is a finding. Run that comparison yourself before the auditor does.

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, which is exactly what an auditor sees in a register where every review date falls in the same quarter.

Write down the classification criteria before you classify. An auditor who finds a supplier in the lowest tier while it processes customer data will ask for the reasoning. If there is none, the classification itself is the finding.

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 you check five things. Whether the service you buy falls inside the scope of the report, and not just the supplier's name. Which period was tested, and how large the gap is between the end of that period and today. Whether the test results contain exceptions, and whether those touch the controls you rely on. Whether subcontractors are carved out, and whether you then need a separate report from those parties. And which controls the supplier expects from you.

That last point, the complementary user entity controls, is where many organisations drop the ball. A report stating that access management sits with the customer only covers your risk if you actually do that access management. An auditor testing your supplier management asks for your review of the report, and that review has to be more than a tick. A short note per report covering the five points above and a conclusion is the evidence that belongs in the file. If a report with an unnoticed exception sits in your archive, that is a finding against you, not against the supplier.

The gap between the report period and today deserves attention. A Type II report on the calendar year, published in March, says nothing in November about the last ten months. A bridge letter, in which the supplier states that no material changes to the controls occurred in the intervening period, is a limited but common way to cover that gap. Ask for one.

With an ISO 27001 certificate, check the scope statement on the certificate itself, plus the name of the certification body and its accreditation. A certificate covering only the head office while the service runs from another data centre does not cover your risk. A certificate also says nothing about exceptions: where a Type II report shows per control what was tested and what the result was, a certificate only states that the management system met the standard at the time of the audit. Also ask for a recent penetration test report, or its management 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 that fits your own reporting duty, the right to audit or to receive an annual assurance report, arrangements on subcontracting and on being informed when sub-processors change, and an exit clause stating how you get your data back, in which format and within what period.

Watch the order of those notification deadlines. If NIS2 requires you to issue an early warning within 24 hours and your supplier contractually has 72 hours to report an incident, you have a gap of your own making. Organisations under DORA also have a fixed list of clauses from Article 30 that must appear in every contract, and a heavier set for services supporting critical or important functions. What that means for the provider itself is covered in a separate article.

The 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. An exit clause is not yet an exit strategy: the latter also describes who performs the migration, to which alternative, and how long it takes.

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. That is the same question your auditor asks about the carve-out of subservice organisations in an assurance report: if the hyperscaler is excluded from your SaaS provider's report, what do you rely on for that part. 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 sub-processors, 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. Record each periodic review with a date, a reviewer and an outcome. Annex A 5.22 asks for exactly that, and an auditor testing the operating effectiveness of your supplier management draws a sample from your register and asks, per supplier, for the latest review. What counts as usable evidence there, and what does not, is covered in the article on audit evidence.

What the auditor tests

In short, an auditor arrives with four questions. Is the register complete, tested against an independent source. Is the classification right, and is it substantiated. Does the depth of the assessment match the tier, and is the evidence (report reviews, contracts, notes) on file. And does the process work over time: have reassessments been done, have triggers been followed up, have new suppliers entered through the process. That last question is what separates a Type II report from a Type I, and a surveillance audit from the initial certification.

Where TPRM stalls in practice

Four patterns keep coming back. A register that stops being maintained after the first inventory, so it no longer matches reality a year later and the auditor exposes it through the creditor list. Assurance reports that get requested and filed without anyone reading the exceptions and the user entity controls. Contracts in which the supplier's notification deadline is longer than your own reporting duty. And ownership that sits nowhere: procurement assumes security reviews it, security assumes procurement nailed it down contractually.

You fix that last one by naming an owner per supplier. Secure Audit tests supplier management as part of ISO 27001, SOC 2 and ISAE 3402 engagements and as a standalone review; see our risk services page.

Further reading: supply chain security, what regulators expect from IT risk management and the changes in ISO 27001:2022.