Leveranciersrisico voor wie geen TPRM-team heeft

Third Party Risk Management, kortweg TPRM, is de functie die het risico bij ICT-leveranciers en andere derden in kaart brengt, contractueel verankert en periodiek verifieert. Het is geen tool, geen afdeling, geen volwassenheidsscore. Het is een werkgewoonte: weten welke derden toegang hebben tot welke processen en data, weten wat er fout kan gaan als zij omvallen of worden gecompromitteerd, en kunnen aantonen dat je daar zicht op houdt. Wie die werkgewoonte niet heeft, draagt het risico van zijn leveranciers zonder het te kunnen onderbouwen, en dat is precies wat onder NIS2 en DORA niet meer houdbaar is.

Dit stuk legt uit hoe je die functie inricht als je geen TPRM-team hebt, geen vendor risk manager, geen vier specialisten met spreadsheets. Het is geschreven voor de Ops-manager die het werk in praktijk verzet en die intern moet onderbouwen waarom een minimumset nu nodig is, en wat die minimumset is. Niet een ideaalbeeld, een werkbare ondergrens.

Wat is TPRM, en waarom valt hij nu structureel op het Operationele portefeuille?

TPRM beschrijft de discipline om risico bij derden te beheren als een continu proces, niet als een eenmalige assessment voor of na contract. In ISO/IEC 27036, de internationale norm voor information-security-relaties met leveranciers, wordt het ontleed in drie lagen: het algemene kader voor leveranciersrelaties (deel 1), de leveranciersovereenkomst zelf (deel 2), en de specifieke eisen voor ICT-leveringsketens (deel 3). Die structuur is bruikbaar omdat ze de denkfout wegneemt dat TPRM "zorgvuldig contracteren" is. Contracteren is één moment. TPRM is het hele tijdsverloop daarvoor, daarin en daarna.

De reden dat de functie nu op het Operationele portefeuille valt en niet meer op een procurement-afdeling alleen, is wetgeving. NIS2-artikel 21, tweede lid, onder d, verplicht entiteiten binnen scope om de beveiliging van de toeleveringsketen mee te wegen in hun risicobeheersmaatregelen, inclusief de beveiligingsaspecten van de relatie met directe leveranciers en dienstverleners. DORA, hoofdstuk V van Verordening 2022/2554, gaat voor financiële entiteiten verder en eist een register van ICT-derde-partij-overeenkomsten, een classificatie van kritieke functies bij derden, contractuele minimumeisen, een exit-strategie en periodieke rapportage aan de toezichthouder. Beide kaders verlangen aantoonbaarheid. Geen "wij vinden dat we hier zicht op hebben", maar een document, een lijst, een datum, een afgesproken interval.

In organisaties zonder vendor-management-afdeling komt dat werk bij de mensen terecht die de leveranciers feitelijk zien functioneren: de Ops-kant. Niet omdat dat ideaal is, maar omdat er niemand anders is die weet wie er logt, wie er logical access heeft, wie het patchen doet, wie de back-ups draait, en welke partij stilstaat als een specifieke leverancier eruit ligt. Het Nationaal Cyber Security Centrum benadrukt in zijn handreikingen over ketenveiligheid dat het zicht op leveranciers begint bij wie ze concreet zijn en wat ze concreet doen, niet bij een abstract beleid. Dat zicht zit op de werkvloer, en daar moet de functie ook beginnen.

Wat doet een TPRM-functie precies, los van wie hem uitvoert?

Vier dingen, en het is nuttig ze één voor één scherp te krijgen, omdat veel organisaties één of twee daarvan al doen en denken dat ze er zijn.

Het eerste is identificeren en classificeren. Wie zijn jullie ICT-derden, wat doen ze, en hoe kritiek zijn ze. Een externe SOC-partij die 24/7 detectie verzorgt is iets anders dan een ontwerpbureau dat eens per kwartaal een PowerPoint-template aanlevert. Beide zijn derden, maar de tweede valt buiten elke zinvolle TPRM-scope. Classificatie is geen administratief invuloefening, het is de filter waarmee je later prioriteert. ENISA werkt in zijn publicaties over supply-chain-security met categorieën als toegang tot data, toegang tot systemen, afhankelijkheid bij uitval en aanwezigheid in kritieke processen. Die vier vragen samen geven een werkbare classificatie.

Het tweede is contractueel verankeren wat afgesproken moet zijn. Dat is niet "een NDA tekenen". Het is een set bepalingen die per categorie verschilt: notificatie-termijnen bij incidenten, het recht om audits uit te voeren of audit-rapporten op te vragen, sub-uitbestedings-restricties, beveiligingsstandaarden waaraan de leverancier zich verbindt, exit-bepalingen en data-teruggave. DORA-artikel 30 schrijft voor financiële entiteiten letterlijk voor wat een ICT-derde-partij-overeenkomst minimaal moet bevatten. Wie buiten DORA-scope valt, kan die lijst nog steeds als kapstok gebruiken, want hij is in essentie wat een redelijke koper zou afspreken.

Het derde is periodiek verifiëren. Een leverancier die bij contractsluiting voldeed, voldoet niet automatisch twee jaar later. Verificatie betekent: opvragen van geldige certificeringen, opvragen of laten uitvoeren van een actuele assurance-rapportage (ISAE 3402, SOC 2, ISO 27001-certificaat), en bij hoog-kritieke leveranciers een eigen toets of een joint exercise. ISO 27036-3 noemt dit "ongoing assurance" en het is precies waar de meeste organisaties het verzaken: ze hebben een dossier opgebouwd op moment T en doen er daarna niets meer mee tot moment T plus vier jaar.

Het vierde is een exit-pad kennen voordat je het nodig hebt. Wat gebeurt er als deze leverancier morgen failliet gaat, wordt overgenomen door een partij die jullie niet vertrouwen, of een datalek heeft dat hen onbruikbaar maakt. Wie draait dan welke taak over, op welke termijn, met welke kosten. DORA-artikel 28 maakt dit voor financiële entiteiten een verplichte exit-strategie per kritieke leverancier. Voor de rest is het gezond verstand. Een TPRM-functie zonder gedachte over exit is een dossier dat niet werkt op het moment dat het moet werken.

Hoe ziet een lichtgewicht TPRM-functie eruit als je geen team hebt?

Hier is het scheidingsvlak tussen wat boeken voorschrijven en wat een midmarket-organisatie kan dragen. De boeken beschrijven een ideale TPRM-organisatie met rollen, tooling, jaarcycli en geïntegreerde dashboards. Die ideale vorm is voor weinig organisaties haalbaar en voor de meeste niet nodig. Wat wel nodig is, is een minimumset die de wet aan kan en die bij een redelijke audit standhoudt. De rest is gradatie.

De minimumset bestaat uit vier onderdelen die elke organisatie kan inrichten met de mensen die er al zijn, mits iemand er eigenaar van wordt:

Een leveranciersregister. Eén lijst, één bron, geen schaduwlijsten in inboxen. Per leverancier vastleggen: naam, contracteigenaar intern, type dienst, toegang tot welke systemen of data, classificatie van kritikaliteit, contracteinddatum, datum laatste assurance-document, eigenaar bij de leverancier. Een spreadsheet volstaat, mits hij wordt bijgehouden. Beter een werkende spreadsheet dan een dood TPRM-platform.

Een classificatie-matrix met drie of vier niveaus. Kritiek, hoog, midden, laag. De criteria expliciet: welke data, welke systeemtoegang, welke afhankelijkheid bij uitval, welke aanwezigheid in kritieke bedrijfsprocessen. De classificatie bepaalt wat er aan controles op die leverancier wordt gezet. Een kritieke leverancier krijgt jaarlijkse verificatie en een exit-plan. Een lage krijgt een contractcheck en niets meer. Zonder die filter wordt elke leverancier gelijk behandeld en gebeurt er bij niemand iets.

Een set standaard contractuele clausules. Niet voor elke leverancier opnieuw onderhandelen, maar één set die de basis vormt: meldplicht bij incidenten binnen 24 of 48 uur, recht op audit-rapporten of certificeringen, sub-uitbestedings-toestemming, beveiligingsstandaarden, data-teruggave en deletie bij beëindiging, exit-medewerking. Per classificatie aanvullen of verzwaren. Deze set is eenmalig werk en daarna een knip-en-plak-exercitie. DORA-artikel 30 is de strengste lijst die je kunt nemen; voor wie buiten DORA valt is hij overdreven maar bruikbaar als bovengrens.

Een verificatie-ritme per classificatie. Voor kritieke leveranciers: jaarlijks assurance-document opvragen, gesprek voeren, exit-plan vernieuwen. Voor hoog: tweejaarlijks. Voor midden: bij contractverlenging. Voor laag: alleen registreren en bij verlenging een contractcheck. Vastleggen wie wanneer wat doet, in dezelfde lijst als het register. Een ritme zonder eigenaar is geen ritme, het is een goede bedoeling.

Vier onderdelen, één eigenaar, één lijst. Dat is de ondergrens. Wie dit heeft, kan onder NIS2 en DORA aantonen dat de toeleveringsketen wordt beheerd. Wie meer wil, kan tooling toevoegen, joint exercises met kritieke leveranciers organiseren of een security-vragenlijst-flow inrichten. Maar die uitbouw is meerwaarde, geen voorwaarde. De voorwaarde is dat de minimumset draait.

Waar loopt dit in de praktijk vast, en hoe voorkom je dat?

Drie patronen zien we terugkomen, en ze hebben allemaal te maken met het verschil tussen "we hebben dit ingericht" en "dit werkt".

Het eerste patroon is eigenaarschap dat zweeft tussen procurement, IT en security. Procurement zegt dat het over risico gaat, dus security. Security zegt dat het over contracten gaat, dus procurement. IT zegt dat de leveranciers wel werken, dus waar gaan we over. Het gevolg: niemand voert het register bij, niemand stuurt de verificatie-herinneringen, niemand bewaakt de exit-plannen. De oplossing is geen herorganisatie, het is een naam. Eén persoon in de lijst, met de bevoegdheid om aan procurement en aan IT te vragen wat hij nodig heeft, en met een halfjaarlijkse review bij zijn manager. Bij organisaties zonder TPRM-team zit die naam vaak op de Ops-functie, omdat daar al het zicht zit.

Het tweede patroon is het register dat een momentopname is. Een externe partij maakt een leveranciers-assessment, levert een rapport, en het rapport wordt opgeslagen op een sharepoint. Twee jaar later is er een NIS2-toezichtvraag, en het rapport blijkt over leveranciers te gaan die deels niet meer bestaan, deels onder een andere naam zijn doorgegaan, en deels door subuitbesteding zijn aangevuld met partijen die niet in het rapport voorkomen. Het rapport is correct op de dag waarop het werd opgeleverd, en irrelevant op elke dag daarna. De oplossing is dat het register een levend document is dat met elke contractwijziging meebeweegt, niet een document dat eens per project wordt uitgebracht.

Het derde patroon is contractuele clausules die niet getoetst worden. De clausules staan in elk contract, de leveranciers tekenen ze. Tot er een incident gebeurt en blijkt dat de meldplicht van 48 uur op het bureau van een accountmanager belandde die met vakantie was, dat het audit-recht in de praktijk werd geweigerd, of dat sub-uitbesteding allang had plaatsgevonden zonder kennisgeving. Een contractuele clausule die niet eens per cyclus wordt getest, is een papieren afspraak. De oplossing is jaarlijks of tweejaarlijks bij kritieke leveranciers gewoon vragen om bewijs dat de clausules nageleefd worden: stuur ons jullie incident-meldproces, stuur ons jullie lijst van sub-uitbesteders, stuur ons jullie laatste audit. De vraag stellen brengt vaak meer naar boven dan het antwoord zelf.

Wat betekent dit voor het gesprek dat de Operationele leiding voert?

De boodschap naar boven hoeft geen waarschuwingsverhaal te zijn over wat NIS2 of DORA zou kunnen kosten. Het is eenvoudiger: er is een werkgewoonte rond leveranciers die nu nergens belegd is, die wetgeving en redelijke audits van ons gaan vragen, en die met vier onderdelen en één eigenaar in te richten is zonder dat er een afdeling bij komt. De keuze is niet "een TPRM-team opzetten of niets". De keuze is wie de minimumset bewaakt, en hoeveel tijd dat per maand kost.

De Ops-manager die deze functie informeel al deels uitvoert, voert intern in feite twee gesprekken tegelijk. Het ene gaat over erkenning: maak zichtbaar dat het werk plaatsvindt en wie het doet, anders blijft het ongezien en kwetsbaar voor wegval bij vakantie of vertrek. Het andere gaat over kader: leg vast wat de minimumset is, zodat het werk niet uitdijt naar elke kleine leverancier en niet inkrimpt onder werkdruk. Beide gesprekken kosten weinig, mits het kader en de eigenaar expliciet zijn.

De keuze voor een lichtgewicht functie is geen compromis op kwaliteit. Het is een herkenning dat de wet aantoonbaarheid vraagt, niet maximale volwassenheid. Een werkende ondergrens die wordt bijgehouden, staat sterker dan een ambitieus framework dat verwatert. Wie dit jaar de minimumset op orde krijgt, heeft volgend jaar de ruimte om hem uit te bouwen. Wie wacht tot er een team is, wacht in praktijk tot het eerste incident of de eerste toezichtsbrief, en dan verschuift de discussie van inrichting naar verantwoording. Die volgorde is de duurste.