Third-Party Risk Management (TPRM): complete gids 2026
Complete gids third-party risk management (TPRM): DORA-verplichtingen, DNB-toezicht, leveranciersbeoordeling, doorlopende monitoring en compliance in Nederland 2026.

Dit artikel samenvatten met
Third-party risk management (TPRM) — het gestructureerd beheren van risico's die voortvloeien uit relaties met externe leveranciers, dienstverleners en technologiepartners — is sinds de inwerkingtreding van de DORA-verordening op 17 januari 2025 een dwingende regelgevende verplichting voor Nederlandse financiële instellingen. 35,5% van alle datalekken is afkomstig uit de toeleveringsketen, en de Nederlandsche Bank (DNB) en de Autoriteit Financiële Markten (AFM) verwachten dat instellingen hun derde-partij-risicobeheer kunnen aantonen met concrete documentatie.
Deze gids zet het regelgevingskader voor Nederland, de vijf kernfasen van een effectief TPRM-programma en de praktische stappen voor DORA-compliance in 2026 uiteen.
Dit artikel is uitsluitend informatief van aard en vormt geen juridisch, financieel of regelgevend advies. Raadpleeg voor organisatiespecifieke vragen een gekwalificeerde adviseur.
Wat is TPRM en waarom is het verplicht?
Third-party risk management (TPRM) is het gestructureerde proces waarmee een organisatie risico's identificeert, beoordeelt, bewaakt en mitigeert die voortvloeien uit relaties met externe partijen. Het bestrijkt een breder spectrum dan uitsluitend cyberveiligheid.
De wettelijke referentie voor TPRM in Nederland is Verordening (EU) 2022/2554 (DORA), van toepassing op alle financiële entiteiten in de EU per 17 januari 2025 (DORA, artikel 28). DNB treedt op als nationale bevoegde autoriteit voor de handhaving van DORA in Nederland. DNB publiceert hierover periodiek toezichtsverwachtingen op haar DORA-informatiepagina.
Naast DORA gelden voor Nederlandse organisaties onder meer:
| Regelgeving | Toepassingsgebied | Verplichting voor TPRM |
|---|---|---|
| DORA (Verordening (EU) 2022/2554) | Financiële entiteiten | ICT-register, due diligence, contractuele bepalingen |
| AVG / GDPR | Alle organisaties die persoonsgegevens verwerken | Verwerkersovereenkomsten met leveranciers |
| Wwft (Wet ter voorkoming van witwassen) | Financiële instellingen, notarissen, advocaten | Cliëntenonderzoek inclusief derde-partijrelaties |
| NIS2-richtlijn (2022/2555) | Kritieke sectoren buiten de financiële sector | Beveiliging van de toeleveringsketen |
| DNB Good Practice DORA | Alle DNB-gereguleerde instellingen | Verwachtingen DNB-toezicht |
Regelgevingskader: DNB, AFM en DORA in 2026
DORA-verplichtingen voor Nederlandse financiële instellingen
Vanaf 17 januari 2025 is DORA van toepassing op banken, verzekeraars, vermogensbeheerders, betalingsdienstverleners en aanbieders van crypto-activadiensten die in Nederland actief zijn. DNB is de nationale toezichthouder die naleving verifieert.
De belangrijkste DORA-verplichtingen met betrekking tot TPRM zijn:
- Register van contractuele ICT-afspraken: bijhouden van een volledig register van alle contractuele regelingen met ICT-derde-partijen (artikel 28 DORA).
- Precontractuele due diligence: verplichte risicobeoordeling vóór het sluiten van contracten die kritieke of belangrijke functies betreffen.
- Contractuele minimumeisen: contracten moeten de bepalingen van artikel 30(2) DORA bevatten — auditrechten, SLA's, melding van incidenten binnen 4 uur, exitstrategieën.
- Doorlopend toezicht: instellingen kunnen hun toezichtsverantwoordelijkheid niet overdragen aan een derde partij.
- Beheer van concentratierisico's: beoordeling van alternatieven bij buitensporige afhankelijkheid van één aanbieder.
Bijzonder aandachtspunt voor 2026 is de afhankelijkheid van niet-EU-hyperscalers voor cloudopslag en -verwerking. DNB verwacht dat instellingen kunnen aantonen dat zij exitstrategieën hebben getest en alternatieven hebben geïdentificeerd voor kritieke cloudproviders.
DNB-verwachtingen en de Wwft
Naast DORA verwacht DNB in het kader van de Wet ter voorkoming van witwassen en financieren van terrorisme (Wwft) dat financiële instellingen cliëntenonderzoek uitvoeren op hun zakelijke relaties. Dit omvat ook derde-partijrelaties die risico's op witwassen of terrorismefinanciering kunnen introduceren.
Als van 17 januari 2025 gelden voor Nederlandse financiële instellingen tegelijkertijd de Wwft-verplichtingen en de DORA-vereisten voor ICT-derde-partijrisicobeheer. Een geïntegreerde aanpak — waarbij due diligence-processen voor Wwft en DORA worden gecombineerd — is efficiënter dan twee parallelle processen.
De vijf kernfasen van een TPRM-programma
Fase 1: Inventarisatie en classificatie van derde partijen
Een TPRM-programma begint met een volledig en actueel overzicht van alle derde partijen — directe leveranciers, onderaannemers, technologiepartners en cloudaanbieders. Uit onderzoek van Whistic (2025) blijkt dat organisaties gemiddeld 286 leveranciers beheren, met een gemiddelde ratio van 33,6 leveranciers per risicospecialist.
Elke derde partij wordt geclassificeerd op basis van kritikaliteit:
- Kritiek: leveranciers die kritieke of belangrijke functies ondersteunen, toegang tot gevoelige data, hoge operationele afhankelijkheid.
- Hoog: matige impact bij uitval, beperkte datatoegang.
- Standaard: randactiviteiten, lage operationele impact.
Deze classificatie bepaalt de diepgang van de due diligence, de beoordelingsfrequentie en de vereiste contractuele bescherming.
Fase 2: Precontractuele due diligence
Voor kritieke ICT-derde-partijen moet de precontractuele due diligence omvatten:
- Financiële stabiliteit (gecontroleerde jaarrekeningen, kredietrating, verzekeringsdekkingen).
- Beveiligingspostuur (ISO 27001, SOC 2 Type II, resultaten penetratietests).
- Naleving van regelgeving (AVG, DORA, sectorspecifiek).
- Capaciteit voor bedrijfscontinuïteit en noodherstel.
- Exitstrategie en dataportabiliteitsplan.
CheckFile automatiseert de verzameling en verificatie van leveranciersdocumenten in deze fase — certificeringen, jaarrekeningen, verzekeringspolissen, KvK-uittreksels — met automatische signalering van ontbrekende of verlopen documenten.
Fase 3: Contractuele bescherming conform DORA
Contracten met kritieke ICT-leveranciers moeten de bepalingen van artikel 30(2) DORA bevatten, anders lopen instellingen het risico op handhaving door DNB. De minimumeisen omvatten:
- Precieze beschrijving van diensten en prestatieniveaus (SLA).
- Audit- en inspectierechten voor de instelling en haar toezichthouders.
- Melding van ernstige incidenten binnen 4 uur.
- Beëindigingsvoorwaarden en gedocumenteerde exitstrategie.
- Beperkingen op uitbesteding van kritieke functies zonder voorafgaande goedkeuring.
- Locatie van gegevens en toepasselijk rechtsstelsel.
Fase 4: Doorlopende monitoring
Periodieke beoordelingen volstaan niet meer. 70% van de functionele stakeholders heeft geen inzicht in de risico's van hun leveranciers (Gartner, 2025). DNB en de Europese toezichtautoriteiten verwachten realtime inzicht, niet statische jaarlijkse zelfevaluaties.
Effectieve doorlopende monitoring omvat:
- Periodieke herbeoordeling van vragenlijsten, op maat van de kritikaliteit (kwartaal voor kritiek, jaarlijks voor standaard).
- Externe beveiligingsmonitoring (aanvalsoppervlakbeheer, CVE-meldingen).
- Bewaking van de financiële gezondheid van kritieke leveranciers.
- Opvolging van wijzigingen in regelgeving en geopolitieke risico's die leveranciers treffen.
- Automatische meldingen voor het verlopen van certificeringen en regelgevende vergunningen.
CheckFile centraliseert de nalevingsdocumentatie van leveranciers en stuurt automatische meldingen wanneer een ISO-certificering, verzekeringsbeleid of regelgevende vergunning bijna verloopt, zodat uw instelling altijd aantoonbaar compliant is tegenover DNB.
Fase 5: Incidentbeheer en exitstrategieën
DORA vereist gedocumenteerde en geteste exitstrategieën voor alle kritieke ICT-leveranciers. DNB verwacht bewijs dat exitplannen daadwerkelijk zijn gerepeteerd, niet alleen op papier zijn beschreven. Een effectieve exitstrategie omvat:
- Geïdentificeerde alternatieve aanbieders of internalisatieplannen.
- Gedocumenteerde procedures voor datamigatie en systeemovergang.
- Contractuele opzegtermijnen die zijn afgestemd op de complexiteit van de overgang.
- Volledig register van technische afhankelijkheden en datastromen.
Zie ons artikel over DORA 2026 en documentverificatie in de financiële sector voor gedetailleerde vereisten inzake incidentrapportage en TLPT-testen.
Praktische uitdagingen bij TPRM in Nederland
Compliance-professionals in Nederland en op forums zoals r/thenetherlands (zakelijke discussies) identificeren steeds dezelfde obstakels bij de implementatie van een volwassen TPRM-programma.
Uitdaging 1: de juiste documentatie van leveranciers verkrijgen. 48% van de complianceteams noemt dit als hun voornaamste obstakel (ISACA, 2020). Kleinere leveranciers beschikken vaak niet over gestructureerde nalevingsprogramma's en kunnen de gevraagde documentatie moeilijk aanleveren. Geautomatiseerde documentverzameling elimineert de tijdrovende e-mailwisselingen die compliancecapaciteit opslorpen.
Uitdaging 2: onderbezetting. 62% van de risicoleiders zegt dat hun TPRM-programma onvoldoende bemand is. Met gemiddeld 33,6 leveranciers per risicospecialist is automatisering geen luxe, maar een noodzaak.
Uitdaging 3: draagvlak bij de directie. Slechts 40% van de bedrijven rapporteert regelmatig over derde-partijrisico's aan de raad van bestuur. De zakelijke argumentatie is duidelijk: de gemiddelde kosten van een datalek bedroegen in 2024 USD 4,88 miljoen (IBM Cost of a Data Breach Report 2024), en DORA-sancties voor kritieke ICT-derde-partijen kunnen oplopen tot 1% van de dagelijkse wereldwijde omzet.
Voor een overzicht van hoe TPRM past in het bredere GRC-kader, zie onze GRC-gids en de gids documentcompliance.
TPRM-volwassenheidsmodel: vier niveaus
Organisaties bevinden zich op verschillende niveaus van TPRM-volwassenheid. Het onderstaande model helpt teams te bepalen waar ze staan en welke stappen nodig zijn voor DORA-conformiteit.
| Niveau | Kenmerken | Risico voor DNB-toezicht |
|---|---|---|
| 1 — Ad hoc | Geen formeel beleid, geen volledige inventaris, contracten zonder auditrechten | Zeer hoog: niet-conform met DORA |
| 2 — Herhalend | Beleid aanwezig, gedeeltelijke inventaris, jaarlijkse beoordelingen, geen exitstrategieën | Hoog: kritieke lacunes |
| 3 — Gedefinieerd | Volledige inventaris, risicoklassificatie, contractuele minimumeisen, periodieke monitoring | Matig: voldoet grotendeels aan DORA |
| 4 — Beheerd | Doorlopende monitoring, geteste exitstrategieën, vierde-partijrisicobeheersing, geautomatiseerde documentopvolging | Laag: volledig DORA-conform |
Uit onderzoek van Netrin (Third-Party Risk Insights 2026) blijkt dat 46% van de organisaties nog geen volwassen TPRM-programma heeft — niveau 1 of 2 in bovenstaand model. Voor Nederlandse financiële instellingen die onder DORA vallen, zijn niveau 1 en 2 onacceptabel vanaf 17 januari 2025.
De stap van niveau 2 naar niveau 3 vereist doorgaans: het opbouwen van een volledig ICT-register, het renegotiëren van contracten om DORA-clausules toe te voegen, en het invoeren van geautomatiseerde documentopvolging. CheckFile ondersteunt deze transitie door de documentverzameling bij leveranciers te automatiseren en een auditklaar dossier samen te stellen dat DNB-toezichthouders direct kunnen inzien.
Operationele TPRM-checklist
Een volwassen TPRM-programma bevat de volgende elementen:
- Schriftelijk TPRM-beleid goedgekeurd door de directie.
- Volledig en actueel overzicht van alle derde partijen met kritikaliteitsclassificatie.
- Beoordelingsvragenlijsten afgestemd op het risiconiveau.
- Register van ICT-contractuele afspraken conform artikel 28 DORA.
- Contractuele bepalingen conform artikel 30(2) DORA voor kritieke leveranciers.
- Gedocumenteerd doorlopend monitoringproces.
- Geteste exitstrategieën voor kritieke leveranciers.
- Jaarlijks TPRM-rapport aangeboden aan het bestuur of de risicocommissie.
- Kaart van concentratierisico's.
- Incidentresponsprocedure voor door derde partijen veroorzaakte gebeurtenissen.
Ontdek CheckFile voor het centraliseren van leveranciersdocumentatie en het automatiseren van de opvolging van certificeringen en contracten.
Veelgestelde vragen
Wat is third-party risk management (TPRM)?
TPRM is het gestructureerde proces van identificeren, beoordelen en beheren van risico's die worden geïntroduceerd door leveranciers, dienstverleners en partners. Het bestrijkt operationele, cyberrisico's, nalevingsrisico's, reputatierisico's, concentratierisico's en geopolitieke risico's gedurende de volledige levenscyclus van de derde-partijrelatie.
Welke Nederlandse instellingen vallen onder DORA?
DORA is van toepassing op banken, verzekeraars, vermogensbeheerders, betalingsdienstverleners, uitgevers van elektronisch geld, cryptodienstverleners en aanverwante ICT-aanbieders die actief zijn in de EU. DNB en de AFM zijn de bevoegde autoriteiten in Nederland. Instellingen buiten de financiële sector vallen onder NIS2.
Wat is het verschil tussen TPRM en leveranciersbeheer?
Leveranciersbeheer richt zich op operationele prestaties en commerciële voorwaarden. TPRM voegt een gestructureerde risicodimensie toe: beveiligingsbeoordeling, naleving van regelgeving, financiële stabiliteit en veerkracht, met documentatie bestemd voor toezichthouders.
Hoe vaak moeten leveranciersrisicobeoordelingen worden uitgevoerd?
De beoordelingsfrequentie moet evenredig zijn aan de kritikaliteit van de leverancier. Kritieke leveranciers die kritieke bedrijfsdiensten ondersteunen, vereisen doorgaans kwartaalbeoordelingen en doorlopende externe monitoring. Standaardleveranciers kunnen jaarlijks worden beoordeeld. Triggerende gebeurtenissen — grote incidenten, financiële problemen, wijzigingen in regelgeving — vereisen onmiddellijke herbeoordeling.
Welke sancties gelden bij niet-naleving van DORA in Nederland?
Bij niet-naleving van DORA kan DNB handhavingsmaatregelen treffen, waaronder bestuurlijke boetes, aanwijzingen en beperkingen op bedrijfsactiviteiten. Voor kritieke ICT-derde-partijen die rechtstreeks worden gecontroleerd door de ESAs, kunnen periodieke boetes oplopen tot 1% van de gemiddelde dagelijkse wereldwijde omzet totdat naleving is hersteld.