Third-party risk management: leveranciersbeheer dat een audit doorstaat

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. Dit artikel beschrijft hoe je dat proces inricht en, minstens zo belangrijk, wat een auditor er later van wil zien.

Waar de eis vandaan komt

Leveranciersbeheer staat in vrijwel elk kader dat wij toetsen, en de formulering verschilt per kader. ISO 27001:2022 wijdt er in Annex A vijf maatregelen aan: 5.19 tot en met 5.23, over beleid voor leveranciersrelaties, de afspraken in overeenkomsten, de ICT-toeleveringsketen, het monitoren en beoordelen van leveranciersdiensten, en het gebruik van clouddiensten. Bij SOC 2 valt het onder CC9.2, dat vraagt dat de organisatie risico's van leveranciers en zakenpartners beoordeelt en beheerst. NIS2 en de Cyberbeveiligingswet noemen de beveiliging van de toeleveringsketen als een van de zorgplichtcategorieën, inclusief de relatie met directe leveranciers. DORA gaat het verst: een informatieregister van alle contractuele overeenkomsten voor ICT-diensten, verplichte contractbepalingen en een exitstrategie voor diensten die kritieke of belangrijke functies ondersteunen. En de AVG vraagt in artikel 28 dat je alleen verwerkers inschakelt die afdoende garanties bieden, met een auditrecht en toestemming voor subverwerkers in de verwerkersovereenkomst.

De kaders delen één uitgangspunt: de beheersing van een leverancier stel je vast, en je kunt achteraf laten zien hoe. Hoe NIS2 in Nederland uitwerkt en wat DORA precies van financiële instellingen vraagt staat in aparte artikelen. Hieronder gaat het om het proces dat onder al die kaders hetzelfde is.

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, de einddatum van het contract en de datum van de laatste beoordeling. Voor organisaties onder DORA komt daar meer bij, waaronder de identificatiecode van de leverancier, het vestigingsland en de onderaannemers die de dienst mede leveren.

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. Een auditor die het register wil toetsen op volledigheid, doet dat door het te vergelijken met een onafhankelijke bron: de crediteurenlijst uit de financiële administratie, de SSO-koppelingen in de identity provider, of de DNS- en firewallregels. Elke partij die daar wel staat en in het register niet, is een bevinding. Doe die vergelijking zelf voordat de auditor het doet.

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 een periodiek heronderzoek. 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, en dat is precies wat een auditor ziet in een register waarvan de beoordelingsdata allemaal uit hetzelfde kwartaal komen.

Leg de classificatiecriteria vast voordat je gaat classificeren. Een auditor die een leverancier in de laagste klasse ziet staan terwijl die klantdata verwerkt, vraagt naar de onderbouwing. Staat die er niet, dan is de classificatie zelf de bevinding.

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](/kennisbank/soc-2-uitleg)- of ISAE 3402-rapport kijk je naar vijf dingen. Valt de dienst die jij afneemt binnen de scope van het rapport, en niet alleen de naam van de leverancier. Welke periode is getoetst, en hoe groot is het gat tussen het einde van die periode en vandaag. Staan er uitzonderingen in de testresultaten, en raken die de maatregelen waar jij op steunt. Zijn er onderaannemers uitgesloten, en heb je van die partijen dan een eigen rapport nodig. En welke maatregelen verwacht de leverancier van jou.

Dat laatste punt, de complementary user entity controls, is waar veel organisaties de bal laten liggen. Een rapport dat stelt dat toegangsbeheer bij de klant ligt, dekt jouw risico alleen als jij dat toegangsbeheer ook echt doet. Een auditor die jouw leveranciersbeheer toetst, vraagt om de beoordeling van het rapport, en die beoordeling moet meer zijn dan een vinkje. Een korte notitie per rapport met de vijf punten hierboven en een conclusie is het bewijs dat in het dossier hoort. Ligt er een rapport met een uitzondering die niemand heeft opgemerkt, dan is dat een bevinding bij jou, niet bij de leverancier.

Het gat tussen rapportperiode en vandaag verdient aandacht. Een Type II-rapport over het kalenderjaar dat in maart verschijnt, zegt in november niets meer over de laatste tien maanden. Een bridge letter, waarin de leverancier verklaart dat er in de tussenliggende periode geen wezenlijke wijzigingen in de beheersing zijn geweest, is een beperkte maar gangbare manier om dat gat te overbruggen. Vraag erom.

Bij een ISO 27001-certificaat controleer je de scopeverklaring op het certificaat zelf, en de naam van de certificerende instelling en haar accreditatie. Een certificaat dat alleen het hoofdkantoor dekt terwijl de dienst uit een ander datacenter komt, dekt jouw risico niet. Een certificaat zegt ook niets over uitzonderingen: waar een Type II-rapport per maatregel laat zien wat er is getest en wat het resultaat was, zegt een certificaat alleen dat het managementsysteem aan de norm voldeed op het moment van de audit. Vraag daarnaast om een recent pentestrapport, of om de managementsamenvatting 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 die past bij je eigen meldplicht, 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, in welk formaat en binnen welke termijn.

Let op de volgorde bij die meldtermijn. Als jij onder NIS2 binnen 24 uur een vroegtijdige waarschuwing moet geven en je leverancier contractueel 72 uur heeft om een incident te melden, dan heb je een gat dat je zelf hebt gecreëerd. Wie onder DORA valt, heeft bovendien een vaste lijst bepalingen uit artikel 30 die in elk contract moet staan, en een zwaardere set voor diensten die kritieke of belangrijke functies ondersteunen. Wat dat voor de leverancier zelf betekent staat in een apart artikel.

De 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. Een exitclausule is nog geen exitstrategie: die laatste beschrijft ook wie de migratie doet, naar welk alternatief en hoe lang dat duurt.

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. Dat is dezelfde vraag die je auditor stelt bij de carve-out van subserviceorganisaties in een assurance-rapport: als de hyperscaler is uitgesloten uit het rapport van je SaaS-leverancier, waar steun je dan op voor dat deel. 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. Leg de periodieke beoordeling vast met datum, beoordelaar en uitkomst. Annex A 5.22 vraagt precies dat, en een auditor die de werking van je leveranciersbeheer wil toetsen, trekt een steekproef uit je register en vraagt per leverancier naar de laatste beoordeling. Wat bruikbaar bewijs daarbij is, en wat niet, staat in het artikel over bewijslast.

Wat de auditor toetst

Samengevat komt een auditor met vier vragen. Is het register volledig, getoetst aan een onafhankelijke bron. Klopt de classificatie, en is die onderbouwd. Is de diepgang van de beoordeling in lijn met de klasse, en is het bewijs daarvan (rapportbeoordelingen, contracten, notities) aanwezig. En werkt het proces door de tijd heen: zijn er heronderzoeken gedaan, zijn triggers opgevolgd, zijn nieuwe leveranciers via het proces binnengekomen. Die laatste vraag onderscheidt een Type II-rapport van een Type I, en een surveillance-audit van de eerste certificering.

Waar TPRM in de praktijk vastloopt

Vier patronen zien we telkens terug. Een register dat na de eerste inventarisatie niet meer wordt bijgehouden, zodat het na een jaar niet meer klopt en de auditor het via de crediteurenlijst ontmaskert. Assurance-rapporten die worden opgevraagd en gearchiveerd zonder dat iemand de uitzonderingen en de gebruikersmaatregelen leest. Contracten waarin de meldtermijn van de leverancier langer is dan de eigen meldplicht. En verantwoordelijkheid die nergens ligt: inkoop denkt dat security het beoordeelt, security denkt dat inkoop het contractueel dichtzet.

Dat laatste los je op door per leverancier een eigenaar aan te wijzen. Secure Audit toetst leveranciersbeheer als onderdeel van ISO 27001-, SOC 2- en ISAE 3402-trajecten en als losse beoordeling; zie de pagina over onze risk services.

Verder lezen: ketenbeveiliging en supply chain security, de eisen die toezichthouders aan risicomanagement stellen en de wijzigingen in ISO 27001:2022.