Third-party risk management: zo houd je grip op je leveranciersketen

Bijna elke organisatie is voor haar kritieke processen afhankelijk van partijen die ze niet zelf bestuurt. Cloudhosting, softwareontwikkeling, salarisadministratie, klantcontact, en steeds vaker AI-diensten. Uitbesteden verplaatst de uitvoering, niet de verantwoordelijkheid. Third-party risk management, meestal afgekort tot TPRM, is het proces waarmee je die verplaatste risico's alsnog beheerst.

Waarom de druk is toegenomen

Twee ontwikkelingen komen samen. Ten eerste is de keten langer geworden: je leverancier heeft zelf leveranciers, en een storing bij een partij die je nooit hebt gecontracteerd kan je dienstverlening platleggen. Ten tweede is er regelgeving die eisen stelt aan ketenbeheersing. NIS2 noemt leveranciersbeheer expliciet als onderdeel van de te nemen maatregelen (artikel 21). DORA verplicht financiële entiteiten een register van al hun ICT-contracten bij te houden en stelt inhoudelijke eisen aan de contracten met dienstverleners die kritieke functies ondersteunen. De AVG vraagt om verwerkersovereenkomsten en om toetsing van de garanties die een verwerker biedt.

Beginnen bij een register

Zonder overzicht is elke beoordeling willekeurig. Een bruikbaar leveranciersregister bevat per partij de geleverde dienst, het proces dat ervan afhankelijk is, welke data er wordt verwerkt en waar, wie de contracteigenaar is, en de einddatum van het contract.

In de praktijk komt dat register er niet in één keer. Inkoop kent de contracten, IT kent de koppelingen, en de afdelingen kennen de tools die ze zelf hebben aangeschaft. Die derde groep is meestal de grootste blinde vlek, net als bij AI-tools.

Classificeren op impact, niet op omvang

Een leverancier is niet kritiek omdat de factuur hoog is. Kritiek is hij als je zonder hem je eigen verplichtingen niet nakomt. Drie vragen bepalen de klasse: wat gebeurt er met onze dienstverlening als deze partij een week uitvalt, welke gegevens hebben zij en hoe gevoelig zijn die, en hoe makkelijk kunnen we over naar een alternatief.

Die uitkomst bepaalt de diepgang van je beoordeling. Voor de bovenste categorie doe je een volledige beoordeling met bewijsstukken en periodieke heronderzoeken. Voor de middenklasse volstaat een vragenlijst met steekproefsgewijze verificatie. Voor de onderste categorie is registratie voldoende. Wie alles even zwaar behandelt, houdt het na een half jaar niet meer bij.

Due diligence: verder dan de vragenlijst

Een ingevulde vragenlijst is een bewering van de leverancier, geen bewijs. Vraag daarom om assurance-rapporten, en lees ze ook echt. Bij een SOC 2- of ISAE 3402-rapport kijk je naar vier dingen: valt de dienst die jij afneemt binnen de scope, welke periode is getoetst, staan er uitzonderingen in de testresultaten, en welke maatregelen verwacht de leverancier van jou. Dat laatste, de complementary user entity controls, is precies waar veel organisaties de bal laten liggen: die maatregelen moeten in je eigen beheersing zitten.

Bij een ISO 27001-certificaat controleer je de scopeverklaring op het certificaat. Een certificaat dat alleen het hoofdkantoor dekt terwijl de dienst uit een ander land komt, dekt jouw risico niet. Vraag daarnaast om een recent pentestrapport, of om de samenvatting daarvan, en om de manier waarop kwetsbaarheden worden opgevolgd.

Wat er in het contract hoort

Contractuele afspraken zijn de enige beheersmaatregel die je zelf volledig in de hand hebt. Zorg dat er minimaal in staat: de beveiligingseisen waaraan de leverancier moet voldoen, een meldplicht bij incidenten met een concrete termijn, het recht om te auditen of jaarlijks een assurance-rapport te ontvangen, afspraken over onderaanneming en over het informeren bij wijziging van subverwerkers, en een exitregeling waarin staat hoe je je data terugkrijgt en in welk formaat.

Die exitregeling wordt het vaakst vergeten en is bij een verstoorde relatie het meest waardevol. Spreek ook een overgangsperiode af waarin de leverancier blijft leveren terwijl jij migreert.

Concentratie en vierde partijen

Twintig leveranciers die allemaal bij dezelfde cloudprovider draaien, geven één storingsscenario en niet twintig. Breng daarom in kaart welke onderliggende platformen je leveranciers gebruiken. Ook hier is een contractuele haak nuttig: het recht om geïnformeerd te worden als je leverancier een kritieke onderaannemer vervangt.

Monitoring maakt het verschil

Een beoordeling bij contractafsluiting verliest snel waarde. Werk daarom met triggers in plaats van alleen met een jaarcyclus. Een nieuw assurance-rapport, een gemeld incident, een overname van de leverancier, een wijziging in de dienst of in de subverwerkers, en het aflopen van een certificaat zijn allemaal aanleidingen om opnieuw te kijken.

Houd bij grote leveranciers ook de operationele kant bij: gehaalde en gemiste serviceniveaus, de doorlooptijd waarmee zij kwetsbaarheden dichten, en of afgesproken rapportages daadwerkelijk komen. Blijft rapportage uit, dan is dat zelf een signaal.

Waar TPRM in de praktijk vastloopt

Drie patronen zien we telkens terug. Een register dat na de eerste inventarisatie niet meer wordt bijgehouden, zodat het na een jaar niet meer klopt. Assurance-rapporten die worden opgevraagd en gearchiveerd zonder dat iemand de uitzonderingen leest. En verantwoordelijkheid die nergens ligt: inkoop denkt dat security het beoordeelt, security denkt dat inkoop het contractueel dichtzet.

Dat laatste los je op met eigenaarschap per leverancier, niet met een extra proces.

Verder lezen: ketenbeveiliging en supply chain security, wat er in een SOC 2-rapport staat, de eisen die toezichthouders aan risicomanagement stellen en wat NIS2 in Nederland betekent.