Third-Party Risk Assessment: Gestructureerde Evaluatie Van Leveranciersrisico's

Het ontbreken van een gestructureerd third-party risk assessment proces creëert aanzienlijke beveiligings-, operationele en compliance-risico's voor Nederlandse overheidsorganisaties. Zonder systematische evaluatie van leveranciers kunnen organisaties niet verifiëren dat derde partijen die toegang hebben tot gevoelige gegevens of kritieke systemen, voldoen aan dezelfde beveiligingsstandaarden die intern worden toegepast. Supply chain aanvallen vormen een van de snelst groeiende bedreigingen in de moderne cybersecurity-landschap, waarbij aanvallers zich richten op leveranciers en serviceproviders om indirect toegang te krijgen tot doelorganisaties. Onderzoek toont aan dat meer dan 60% van alle beveiligingsincidenten verband houdt met derde partijen, hetgeen onderstreept dat leveranciersrisico's niet kunnen worden genegeerd. Zonder een gestructureerd assessment-proces kunnen organisaties niet identificeren welke leveranciers kwetsbaar zijn voor dergelijke aanvallen, wat hen blootstelt aan risico's die buiten hun directe controle liggen.

Implementatie

Dit artikel beschrijft een volledige methodologie voor third-party risk assessment binnen de context van de Nederlandse Baseline voor Veilige Cloud. We behandelen hoe organisaties een gestructureerd assessment-proces kunnen opzetten waarin leveranciers worden geïdentificeerd en gecategoriseerd op basis van hun risicoprofiel, hoe beveiligingsvereisten worden vastgesteld op basis van organisatorische standaarden en compliance-vereisten, en hoe assessments worden uitgevoerd om te verifiëren dat leveranciers voldoen aan deze vereisten. Het artikel beschrijft concrete stappen voor het uitvoeren van technische, organisatorische en compliance-assessments, voor het documenteren van bevindingen en risico's, en voor het ontwikkelen van remediatieplannen wanneer leveranciers niet voldoen aan beveiligingsvereisten. Daarnaast biedt het artikel handvatten voor het opzetten van periodieke herbeoordelingsprocessen, voor het monitoren van leveranciersrisico's over tijd, en voor het rapporteren van assessment-resultaten aan stakeholders zoals bestuur, CISO en compliance officers. Het gekoppelde PowerShell-script ondersteunt dit proces door automatisch leveranciers te inventariseren, assessment-status te monitoren en rapportages te genereren die inzicht geven in de volwassenheid en compliance-status van third-party risicobeheer.

Fundamenten van Third-Party Risk Assessment

Een effectief third-party risk assessment proces begint bij een helder gedefinieerd framework dat beschrijft hoe leveranciers worden geïdentificeerd, gecategoriseerd en geëvalueerd. Het framework moet gebaseerd zijn op erkende standaarden zoals ISO 27001, NIST Cybersecurity Framework of de BIO-normen, zodat assessments consistent en vergelijkbaar zijn tussen verschillende leveranciers en over verschillende tijdsperioden. Het framework definieert verschillende risicocategorieën – zoals hoog, medium en laag risico – op basis van factoren zoals het type toegang dat de leverancier heeft tot organisatiegegevens of systemen, het niveau van gevoeligheid van de gegevens die worden verwerkt, de kritiekheid van de services die worden geleverd, en de geografische locatie en jurisdictie van de leverancier. Voor elke risicocategorie worden specifieke assessment-vereisten gedefinieerd: welke typen assessments moeten worden uitgevoerd, welke beveiligingscontroles moeten worden geëvalueerd, hoe vaak assessments moeten worden herhaald, en welke documentatie vereist is om compliance aan te tonen.

De scope van een third-party risk assessment omvat meerdere dimensies van leveranciersrisico's. Technische risico's omvatten het evalueren van beveiligingsarchitectuur, encryptie-standaarden, toegangscontrole-mechanismen, logging- en monitoring-capaciteiten, en incident response procedures van leveranciers. Organisatorische risico's omvatten het evalueren van beveiligingsbeleid, security awareness programma's, training van medewerkers, en governance-structuren binnen de leveranciersorganisatie. Compliance-risico's omvatten het evalueren of leveranciers voldoen aan relevante wet- en regelgeving zoals AVG, ISO 27001, en sector-specifieke vereisten. Operationele risico's omvatten het evalueren van business continuity planning, disaster recovery capaciteiten, service level agreements, en financiële stabiliteit van leveranciers. Door deze verschillende dimensies te combineren ontstaat een holistisch beeld van de risico's die een leverancier met zich meebrengt, wat organisaties in staat stelt om weloverwogen beslissingen te nemen over leveranciersselectie en contractuele beveiligingsvereisten.

Het assessment-framework moet flexibel genoeg zijn om verschillende typen leveranciers te accommoderen, van kleine lokale serviceproviders tot grote internationale cloud providers, terwijl het consistent genoeg blijft om vergelijkingen mogelijk te maken. Voor high-risk leveranciers die toegang hebben tot kritieke systemen of gevoelige gegevens verwerken, worden uitgebreide assessments uitgevoerd die diepgaande evaluaties omvatten van alle beveiligingscontroles, on-site audits of remote security assessments, en verificatie van certificeringen zoals SOC 2 Type II of ISO 27001. Voor medium-risk leveranciers worden standaard assessments uitgevoerd die basis beveiligingscontroles evalueren via security questionnaires en documentreviews. Voor low-risk leveranciers kunnen vereenvoudigde assessments of zelfcertificering voldoende zijn, waarbij leveranciers zelf verklaren dat zij voldoen aan basis beveiligingsvereisten. Deze risicogebaseerde aanpak zorgt ervoor dat organisaties hun resources effectief toewijzen aan de leveranciers die het grootste risico vormen, terwijl kleinere leveranciers niet onnodig worden belast met uitgebreide assessment-processen.

Een cruciaal aspect van het assessment-framework is de definitie van gestandaardiseerde beveiligingsvereisten die leveranciers moeten voldoen. Deze vereisten moeten gebaseerd zijn op organisatorische standaarden en compliance-frameworks zoals ISO 27001, NIST, en de BIO-normen, en moeten zowel technische controles als organisatorische controles omvatten. Technische vereisten omvatten zaken zoals encryptie in transit en at rest, multi-factor authenticatie voor toegang tot systemen, regelmatige security updates en patching, en uitgebreide logging en monitoring. Organisatorische vereisten omvatten zaken zoals gedefinieerd beveiligingsbeleid, regelmatige security training voor medewerkers, robuuste incident response procedures, en periodieke security audits. Het framework moet ook beschrijven hoe deze vereisten worden gecommuniceerd naar leveranciers, hoe compliance wordt geverifieerd tijdens assessments, en hoe uitzonderingen worden beheerd wanneer leveranciers niet volledig kunnen voldoen aan alle vereisten vanwege technische beperkingen of bedrijfsvereisten.

Assessment Methodologie en Uitvoering

De praktische uitvoering van third-party risk assessments volgt een gestructureerd proces dat bestaat uit verschillende fasen. De eerste fase omvat de identificatie en categorisering van leveranciers op basis van hun risicoprofiel. Alle leveranciers die toegang hebben tot organisatiegegevens of systemen, of die services leveren die van invloed zijn op beveiliging of compliance, moeten worden geïnventariseerd en gecategoriseerd. Dit omvat niet alleen primaire leveranciers, maar ook subleveranciers en vierde partijen die indirect toegang hebben tot gegevens of systemen. Het gekoppelde PowerShell-script ondersteunt dit proces door automatisch verschillende informatiebronnen te doorzoeken – zoals contractdatabases, Microsoft 365 tenant-configuraties, Azure-resources, en toegangsbeheersystemen – om een compleet overzicht te genereren van alle derde partijen die interactie hebben met de organisatie. Op basis van het risicoprofiel worden leveranciers toegewezen aan een risicocategorie, wat bepaalt welk type assessment wordt uitgevoerd en hoe vaak assessments worden herhaald.

De tweede fase omvat het voorbereiden en uitvoeren van het assessment zelf. Voor high-risk leveranciers begint dit met het verzenden van een gestructureerde security questionnaire die is gebaseerd op erkende standaarden zoals de Cloud Security Alliance (CSA) Cloud Controls Matrix of de Shared Assessments Standard Information Gathering (SIG) questionnaire. De questionnaire vraagt leveranciers om gedetailleerde informatie te verstrekken over hun beveiligingsarchitectuur, technische controles, organisatorische processen, en compliance-status. Leveranciers moeten bewijs leveren van hun implementaties, zoals beveiligingsbeleidsdocumenten, certificeringen, auditrapporten, en technische documentatie. Na ontvangst van de questionnaire-respons wordt deze geanalyseerd door security officers die beoordelen of leveranciers voldoen aan de gestelde beveiligingsvereisten. Voor kritieke leveranciers kunnen aanvullende verificatiestappen worden uitgevoerd, zoals on-site audits, remote security assessments, of penetration testing door externe security testers.

De derde fase omvat het analyseren van assessment-resultaten en het documenteren van bevindingen en risico's. Voor elke leverancier wordt een assessment-rapport opgesteld dat beschrijft welke beveiligingsvereisten worden nageleefd, welke tekortkomingen zijn geïdentificeerd, en welke risico's deze tekortkomingen met zich meebrengen. Risico's worden gekwantificeerd op basis van criteria zoals de ernst van de tekortkoming, de waarschijnlijkheid dat de tekortkoming wordt uitgebuit, en de potentiële impact op de organisatie. Het rapport identificeert ook welke tekortkomingen kritiek zijn en onmiddellijk moeten worden aangepakt, welke tekortkomingen belangrijk zijn maar binnen een bepaalde termijn kunnen worden opgelost, en welke tekortkomingen minder kritiek zijn en kunnen worden geaccepteerd via een gestructureerd uitzonderingsproces. Het assessment-rapport vormt de basis voor besluitvorming over leveranciersselectie, contractuele beveiligingsvereisten, en eventuele risicoacceptatie of mitigatiemaatregelen.

De vierde fase omvat het ontwikkelen van remediatieplannen wanneer assessments aangeven dat leveranciers niet voldoen aan beveiligingsvereisten. Dit omvat het identificeren van specifieke tekortkomingen, het ontwikkelen van actieplannen in samenwerking met leveranciers om deze tekortkomingen aan te pakken, en het monitoren van voortgang totdat alle kritieke tekortkomingen zijn opgelost. Voor tekortkomingen die niet kunnen worden opgelost, bijvoorbeeld vanwege technische beperkingen of bedrijfsvereisten, moet een gestructureerd uitzonderingsproces worden doorlopen waarbij risico's expliciet worden geaccepteerd en gedocumenteerd, en aanvullende mitigatiemaatregelen worden geïmplementeerd om resterende risico's te beperken. Het remediatieproces moet tijdgebonden zijn, met duidelijke deadlines voor het oplossen van tekortkomingen, en moet regelmatig worden gemonitord om te verzekeren dat leveranciers daadwerkelijk voortgang boeken in het aanpakken van geïdentificeerde risico's.

Integratie met Compliance-Frameworks

Third-party risk assessment moet naadloos integreren met relevante compliance-frameworks die van toepassing zijn op Nederlandse overheidsorganisaties. De Baseline Informatiebeveiliging Overheid (BIO) vereist expliciet dat organisaties zicht hebben op de volledige keten van gegevensverwerking, inclusief alle derde partijen, en dat risico's worden geïdentificeerd en beheerst. BIO-norm 12.04 stelt dat organisaties processen moeten hebben voor het beheren van leveranciersrelaties, inclusief processen voor het evalueren van leveranciers voordat contracten worden afgesloten, en voor het monitoren van leveranciersprestaties tijdens de contractduur. Het assessment-proces moet daarom expliciet aantonen hoe het bijdraagt aan het voldoen aan deze BIO-vereisten, door gestructureerde processen te definiëren voor leveranciersevaluatie, documentatie van assessment-resultaten, en periodieke herbeoordeling van leveranciersrisico's. Assessment-rapporten en leveranciersregisters vormen cruciale audit evidence die toont dat organisaties voldoen aan BIO-vereisten voor leveranciersmanagement.

De NIS2-richtlijn, die in Nederland is geïmplementeerd via de Wet beveiliging netwerk- en informatiesystemen (Wbni), stelt specifieke eisen aan supply-chain beveiliging voor essentiële en belangrijke entiteiten. Artikel 21 van NIS2 vereist dat organisaties risico's van leveranciers en serviceproviders identificeren en beheersen, en dat zij maatregelen treffen om de beveiliging van de supply chain te waarborgen. Dit omvat onder meer due diligence bij selectie van leveranciers, contractuele beveiligingsvereisten, periodieke beveiligingsassessments, en monitoring van leveranciersprestaties. Het assessment-proces moet daarom expliciet adresseren hoe het voldoet aan NIS2-vereisten, door gestructureerde due diligence-processen te definiëren, contractuele beveiligingsclausules te standaardiseren, en periodieke assessment-cycli in te richten die regelmatig leveranciersrisico's herbeoordelen. Voor organisaties die als essentiële of belangrijke entiteiten worden aangemerkt onder NIS2 is een gestructureerd assessment-proces niet alleen een best practice, maar een wettelijke verplichting.

ISO 27001 bevat specifieke controls voor leveranciersrelaties (A.15.1 en A.15.2) die vereisen dat organisaties informatiebeveiligingsvereisten vaststellen voor relaties met leveranciers, inclusief processen voor het evalueren van leveranciers voordat contracten worden afgesloten, en voor het monitoren van leveranciersprestaties. Het assessment-proces moet daarom aansluiten bij ISO 27001-vereisten door gestandaardiseerde beveiligingsvereisten te definiëren die zijn gebaseerd op ISO 27001 controls, door assessment-processen te documenteren in het informatiebeveiligingsmanagementsysteem, en door assessment-resultaten te gebruiken als input voor risicobeheer en continu verbeteringsprocessen. Voor organisaties die ISO 27001-gecertificeerd zijn, moeten assessment-processen expliciet aantonen hoe zij bijdragen aan het voldoen aan relevante ISO 27001 controls, en moeten assessment-resultaten worden geïntegreerd in het risicomanagementsysteem dat onderdeel is van het certificeringsproces.

De Algemene Verordening Gegevensbescherming (AVG) stelt expliciete eisen aan de relatie tussen verwerkingsverantwoordelijken en verwerkers, waarbij vereist wordt dat verwerkers voldoen aan dezelfde beveiligings- en privacyvereisten als de verwerkingsverantwoordelijke zelf. Hoewel artikel 28 van de AVG primair gericht is op verwerkers zoals cloud providers, strekt de verantwoordelijkheid van de organisatie zich uit tot alle derde partijen die toegang hebben tot of verwerken van persoonsgegevens. Het assessment-proces moet daarom expliciet evalueren of leveranciers voldoen aan AVG-vereisten, inclusief vereisten voor gegevensbescherming, gegevensminimalisatie, rechten van betrokkenen, en datalek-meldingsprocedures. Voor leveranciers die persoonsgegevens verwerken moeten assessments verifiëren dat er passende contractuele waarborgen zijn, zoals data processing agreements, en dat leveranciers kunnen aantonen dat zij technische en organisatorische maatregelen hebben geïmplementeerd om persoonsgegevens te beschermen. Assessment-resultaten moeten worden gedocumenteerd en kunnen worden gebruikt als bewijs tijdens AVG-audits dat organisaties proactief hebben geëvalueerd of leveranciers voldoen aan privacyvereisten.

Monitoring en Periodieke Herbeoordeling

Gebruik PowerShell-script third-party-risk-assessment.ps1 (functie Invoke-Monitoring) – Monitort de status van third-party risk assessments door te analyseren welke leveranciers zijn geïdentificeerd, welke assessments zijn uitgevoerd, en welke leveranciers herbeoordeling vereisen op basis van hun risicoprofiel en de verstreken tijd sinds het laatste assessment..

Third-party risk assessment is geen eenmalige activiteit, maar een continu proces waarbij leveranciersrisico's regelmatig worden herbeoordeeld en gemonitord. Het assessment-framework definieert periodieke herbeoordelingscycli op basis van het risicoprofiel van leveranciers: high-risk leveranciers moeten minimaal jaarlijks worden herbeoordeeld, medium-risk leveranciers tweejaarlijks, en low-risk leveranciers driejaarlijks. Deze cycli moeten flexibel zijn om te kunnen reageren op wijzigingen in leveranciersbeveiligingsposturen, zoals wanneer leveranciers nieuwe services introduceren, hun beveiligingscontroles wijzigen, of beveiligingsincidenten ervaren. Het gekoppelde PowerShell-script ondersteunt dit proces door automatisch te monitoren welke leveranciers herbeoordeling vereisen op basis van de verstreken tijd sinds het laatste assessment, door wijzigingen in leveranciersconfiguraties of toegang te detecteren die kunnen wijzen op veranderingen in risicoprofiel, en door rapportages te genereren die inzicht geven in de status van alle leveranciersassessments.

Naast periodieke herbeoordeling moet het assessment-proces ook continue monitoring omvatten van leveranciersactiviteiten en beveiligingsposturen. Dit omvat het monitoren van toegangslogs om te detecteren of leveranciers ongebruikelijke of onbevoegde toegang hebben tot systemen of gegevens, het monitoren van beveiligingsincidenten bij leveranciers die kunnen wijzen op veranderingen in beveiligingspostuur, en het monitoren van wijzigingen in leveranciersconfiguraties of services die nieuwe risico's kunnen introduceren. Het proces moet ook proactief reageren op externe gebeurtenissen die van invloed kunnen zijn op leveranciersrisico's, zoals wanneer leveranciers worden genoemd in beveiligingsadvisories, wanneer sector-specifieke bedreigingen worden geïdentificeerd, of wanneer nieuwe compliance-vereisten worden geïntroduceerd die gevolgen hebben voor leveranciersbeveiligingsvereisten. Door continue monitoring te combineren met periodieke herbeoordeling ontstaat een proactief risicomanagementsysteem dat snel kan reageren op veranderingen in leveranciersrisico's.

Effectieve monitoring vereist ook duidelijke rapportage en communicatie naar stakeholders. Assessment-resultaten, herbeoordelingsstatus, en geïdentificeerde risico's moeten regelmatig worden gerapporteerd aan bestuur, CISO, compliance officers, en andere relevante stakeholders die betrokken zijn bij leveranciersmanagement. Rapportages moeten duidelijk maken welke leveranciers zijn geëvalueerd, welke risico's zijn geïdentificeerd, welke tekortkomingen zijn aangepakt, en welke leveranciers herbeoordeling vereisen. Door assessment-informatie te centraliseren in een leveranciersregister dat integreert met andere systemen zoals het risicoregister, het compliancemanagementsysteem, en contractdatabases, ontstaat een holistisch beeld van leveranciersrisico's dat kan worden gebruikt voor strategische besluitvorming over leveranciersselectie, contractbeheer, en risicoacceptatie. Het gekoppelde PowerShell-script ondersteunt dit door automatisch rapportages te genereren die inzicht geven in de volwassenheid en compliance-status van third-party risicobeheer, en door dashboards te creëren die real-time inzicht geven in leveranciersrisico's en assessment-status.

Remediatie en Risicomitigatie

Gebruik PowerShell-script third-party-risk-assessment.ps1 (functie Invoke-Remediation) – Ondersteunt remediatie door te identificeren welke leveranciers assessment vereisen, welke leveranciers herbeoordeling vereisen op basis van verstreken tijd of wijzigingen in risicoprofiel, en welke leveranciers kritieke tekortkomingen hebben die onmiddellijk moeten worden aangepakt..

Wanneer assessments tekortkomingen identificeren in leveranciersbeveiligingsposturen, moet een gestructureerd remediatieproces worden gevolgd om deze tekortkomingen aan te pakken en risico's te mitigeren. Het remediatieproces begint bij het prioriteren van geïdentificeerde tekortkomingen op basis van criteria zoals de ernst van de tekortkoming, de waarschijnlijkheid dat de tekortkoming wordt uitgebuit, de potentiële impact op de organisatie, en de haalbaarheid van remediatie. Kritieke tekortkomingen die directe beveiligingsrisico's vormen, zoals ontbrekende encryptie, zwakke toegangscontroles, of gebrek aan logging en monitoring, moeten onmiddellijk worden aangepakt, eventueel door tijdelijk de toegang van leveranciers te beperken totdat remediatie is voltooid. Belangrijke tekortkomingen die significante risico's vormen maar niet onmiddellijk kritiek zijn, moeten worden aangepakt binnen een bepaalde termijn, bijvoorbeeld binnen drie tot zes maanden, waarbij voortgang regelmatig wordt gemonitord. Minder kritieke tekortkomingen kunnen worden geaccepteerd via een gestructureerd uitzonderingsproces waarbij risico's expliciet worden geaccepteerd en gedocumenteerd, en aanvullende mitigatiemaatregelen worden geïmplementeerd om resterende risico's te beperken.

Het ontwikkelen van remediatieplannen gebeurt idealiter in samenwerking met leveranciers, waarbij zowel de organisatie als de leverancier verantwoordelijkheid nemen voor het aanpakken van geïdentificeerde tekortkomingen. Remediatieplannen moeten specifieke acties beschrijven die moeten worden ondernomen, duidelijke deadlines voor het voltooien van acties, en meetbare criteria voor succes die bepalen wanneer een tekortkoming is opgelost. Voor technische tekortkomingen kunnen remediatieplannen bijvoorbeeld het implementeren van aanvullende beveiligingscontroles omvatten, het upgraden van systemen of software, of het configureren van aanvullende logging en monitoring. Voor organisatorische tekortkomingen kunnen remediatieplannen het ontwikkelen of bijwerken van beveiligingsbeleid omvatten, het implementeren van security awareness programma's, of het verbeteren van incident response procedures. Het remediatieproces moet tijdgebonden zijn, met duidelijke milestones en deadlines, en moet regelmatig worden gemonitord om te verzekeren dat leveranciers daadwerkelijk voortgang boeken. Wanneer leveranciers niet in staat zijn om tekortkomingen binnen de gestelde termijnen aan te pakken, moeten organisaties beslissen of zij de leveranciersrelatie willen voortzetten, eventueel met aanvullende mitigatiemaatregelen, of dat zij moeten overwegen om over te stappen naar alternatieve leveranciers.

In sommige gevallen kunnen tekortkomingen niet volledig worden opgelost vanwege technische beperkingen, bedrijfsvereisten, of andere factoren. In deze situaties moet een gestructureerd uitzonderingsproces worden doorlopen waarbij risico's expliciet worden geaccepteerd en gedocumenteerd. Het uitzonderingsproces vereist dat de specifieke tekortkoming wordt beschreven, dat de reden voor uitzondering wordt gedocumenteerd, dat het risico wordt gekwantificeerd en geaccepteerd door de juiste autoriteit (bijvoorbeeld bestuur of CISO), en dat aanvullende mitigatiemaatregelen worden geïmplementeerd om resterende risico's te beperken. Uitzonderingen moeten tijdgebonden zijn en periodiek worden herbeoordeeld om te bepalen of de uitzondering nog steeds gerechtvaardigd is, of dat nieuwe technische mogelijkheden of bedrijfsomstandigheden het mogelijk maken om de tekortkoming alsnog aan te pakken. Door een gestructureerd uitzonderingsproces te volgen, kunnen organisaties transparant en aantoonbaar omgaan met risico's die niet volledig kunnen worden gemitigeerd, terwijl zij tegelijkertijd werken aan het verminderen van deze risico's over tijd.

Compliance & Frameworks

• BIO: 12.04, 18.01 - Borgt dat organisaties zicht hebben op de volledige keten van gegevensverwerking inclusief alle derde partijen, dat risico's worden geïdentificeerd en beheerst, en dat adequate beveiliging wordt gewaarborgd bij uitbesteding van informatievoorziening via gestructureerde assessment-processen.
• ISO 27001:2022: A.15.1, A.15.2 - Ondersteunt informatiebeveiligingsvereisten voor relaties met leveranciers, inclusief processen voor evaluatie van leveranciers voordat contracten worden afgesloten, en voor monitoring van leveranciersprestaties tijdens de contractduur.
• NIS2: Artikel - Verankert supply-chain beveiliging door gestructureerde processen voor identificatie en beheersing van risico's van leveranciers en serviceproviders, inclusief due diligence bij selectie, contractuele beveiligingsvereisten, en periodieke beveiligingsassessments.

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Third-party risk assessment vormt een fundamentele pijler van moderne governance binnen Nederlandse overheidsorganisaties. Dit artikel beschrijft een praktische methodologie voor het uitvoeren van gestructureerde assessments die voldoet aan de eisen van BIO, NIS2 en ISO 27001, en biedt handvatten voor identificatie, evaluatie, monitoring en remediatie van leveranciersrisico's.

• Implementatietijd: 250 uur
• FTE required: 0.8 FTE