Vendor Toegangscontrole Voor Azure-omgevingen In Nederlandse Overheidsorganisaties

Nederlandse overheidsorganisaties werken regelmatig samen met externe leveranciers voor cloudimplementaties, beveiligingsaudits, applicatie-ontwikkeling, systeemonderhoud en technische ondersteuning. Deze samenwerking vereist dat vendors toegang krijgen tot Azure-omgevingen, wat inherent beveiligingsrisico's met zich meebrengt. Zonder doordachte toegangscontrole kunnen vendors onbedoeld of opzettelijk toegang krijgen tot gevoelige data, kunnen zij configuraties wijzigen die de beveiligingspostuur beïnvloeden, en kunnen zij activiteiten uitvoeren die niet worden gemonitord of geaudit. Voor Nederlandse overheidsorganisaties die persoonsgegevens, bedrijfsgevoelige informatie en nationale veiligheidsgevoelige data verwerken, is dit onacceptabel. Compliance-kaders zoals NIS2 vereisen expliciet passende maatregelen voor supply chain security en third-party risk management, BIO vraagt om toegangscontrole en monitoring van externe toegang, en ISO 27001 schrijft controls voor voor supplier relationships en access control. Zonder een gedocumenteerd en geïmplementeerd vendor toegangscontrole framework kunnen organisaties niet aantoonbaar voldoen aan deze eisen en lopen zij het risico op sancties, datalekken en verlies van vertrouwen.

Implementatie

Dit artikel beschrijft een concrete implementatiestrategie voor vendor toegangscontrole binnen Azure-omgevingen, toegespitst op de specifieke eisen en context van Nederlandse overheidsorganisaties. De implementatie is gebaseerd op zes fundamentele pijlers: vendor onboarding en risicoassessment, toegangsbeheer en RBAC-configuratie, tijdgebonden toegang en Just-In-Time (JIT) access, monitoring en logging van vendor-activiteiten, compliance en audit, en vendor offboarding. De eerste pijler betreft vendor onboarding waarbij leveranciers worden beoordeeld op basis van risicoprofiel, compliance-certificeringen, en beveiligingspraktijken voordat toegang wordt verleend. Duidelijke contractuele afspraken, non-disclosure agreements (NDA's) en security requirements worden vastgelegd voordat toegang wordt geconfigureerd. De tweede pijler richt zich op toegangsbeheer waarbij Azure RBAC wordt gebruikt om vendors uitsluitend de minimale rechten te verlenen die nodig zijn voor hun specifieke taken, waarbij toegang wordt beperkt tot specifieke resources, resource groups of subscriptions op basis van de vendor's rol en verantwoordelijkheden. De derde pijler adresseert tijdgebonden toegang waarbij Privileged Identity Management (PIM) wordt gebruikt om Just-In-Time access te implementeren, waarbij vendors toegang aanvragen en activeren voor een beperkte periode (bijvoorbeeld 8 uur), en waarbij goedkeuringsworkflows worden geconfigureerd zodat toegang alleen wordt verleend na expliciete goedkeuring. De vierde pijler betreft monitoring en logging waarbij Azure Monitor, Log Analytics en Azure Sentinel worden gebruikt om vendor-activiteiten te monitoren, verdachte activiteiten te detecteren, en audit trails te genereren voor compliance-doeleinden. De vijfde pijler richt zich op compliance waarbij periodieke access reviews worden uitgevoerd om te verifiëren dat vendor-toegang nog steeds noodzakelijk is, dat vendors voldoen aan contractuele beveiligingsvereisten, en dat toegang wordt ingetrokken wanneer deze niet meer nodig is. De zesde pijler adresseert vendor offboarding waarbij toegang wordt ingetrokken wanneer contracten eindigen, waarbij audit logs worden bewaard volgens BIO-vereisten, en waarbij accounts en credentials worden verwijderd of gedeactiveerd. Het artikel beschrijft voor elke pijler concrete implementatiestappen, best practices, Azure-native services die kunnen worden ingezet, en hoe de pijlers onderling samenwerken om een robuuste en compliance-conforme vendor toegangscontrole te creëren. Daarnaast wordt uitgelegd hoe deze implementatie aansluit bij NIS2-verplichtingen rond supply chain security, BIO-normen rond toegangscontrole, en Microsoft's security best practices voor third-party access management.

Vendor onboarding en risicoassessment

Vendor onboarding vormt de eerste en meest kritieke stap in het vendor toegangscontrole proces. Voordat een externe leverancier toegang krijgt tot Azure-omgevingen, moet een grondige risicoassessment worden uitgevoerd om te bepalen welke toegang noodzakelijk is, welke beveiligingsvereisten moeten worden afgedwongen, en welke compliance-verplichtingen van toepassing zijn. Voor Nederlandse overheidsorganisaties betekent dit typisch dat vendors worden beoordeeld op basis van hun risicoprofiel (bijvoorbeeld hoog risico voor vendors die toegang krijgen tot productieomgevingen met gevoelige data, laag risico voor vendors die alleen toegang krijgen tot development-omgevingen), hun compliance-certificeringen (bijvoorbeeld ISO 27001, SOC 2, of sectorale certificeringen), en hun beveiligingspraktijken (bijvoorbeeld of zij multi-factor authenticatie gebruiken, of zij security awareness training hebben gevolgd, of zij incident response procedures hebben). Contractuele afspraken vormen een essentieel onderdeel van vendor onboarding. Non-disclosure agreements (NDA's) moeten worden ondertekend voordat toegang wordt verleend, waarbij expliciet wordt vastgelegd dat vendors geen toegang hebben tot data buiten de scope van hun contract, dat vendors beveiligingsincidenten moeten melden, en dat vendors verantwoordelijk zijn voor het naleven van beveiligingsvereisten. Security requirements moeten worden vastgelegd in service level agreements (SLA's) of contractuele bijlagen, waarbij expliciet wordt beschreven welke beveiligingsmaatregelen vendors moeten implementeren (bijvoorbeeld multi-factor authenticatie, encrypted communications, secure development practices), welke compliance-vereisten van toepassing zijn (bijvoorbeeld AVG, BIO, NIS2), en welke audit- en monitoring-vereisten gelden. Deze contractuele afspraken vormen de basis voor compliance-rapportage en kunnen worden gebruikt tijdens audits om aan te tonen dat vendors contractueel verplicht zijn om beveiligingsvereisten na te leven. Een belangrijk aspect van vendor onboarding is het bepalen van de scope van toegang. Niet alle vendors hebben dezelfde toegang nodig: een applicatie-ontwikkelaar heeft bijvoorbeeld toegang nodig tot development-omgevingen en source code repositories, maar niet tot productieomgevingen of gevoelige data. Een beveiligingsauditor heeft bijvoorbeeld toegang nodig tot audit logs en beveiligingsconfiguraties, maar niet tot applicatiecode of operationele systemen. Een systeembeheerder heeft bijvoorbeeld toegang nodig tot specifieke resources voor onderhoud en troubleshooting, maar niet tot alle resources in de omgeving. Door de scope van toegang expliciet te definiëren tijdens onboarding, kunnen organisaties ervoor zorgen dat vendors uitsluitend de minimale toegang krijgen die nodig is voor hun specifieke taken, wat het principe van least privilege ondersteunt en het risico op ongeautoriseerde toegang vermindert. Het PowerShell-script uit dit artikel kan worden gebruikt om vendor onboarding te documenteren en te verifiëren dat contractuele afspraken en beveiligingsvereisten zijn vastgelegd voordat toegang wordt geconfigureerd.

Toegangsbeheer en RBAC-configuratie voor vendors

Toegangsbeheer voor vendors in Azure moet worden gebaseerd op het principe van least privilege, waarbij vendors uitsluitend de minimale rechten krijgen die nodig zijn voor hun specifieke taken. Azure RBAC (Role-Based Access Control) vormt de basis voor vendor toegangsbeheer, waarbij ingebouwde rollen of aangepaste rollen worden gebruikt om toegang te verlenen op basis van de vendor's rol en verantwoordelijkheden. Voor Nederlandse overheidsorganisaties is het belangrijk om vendors niet te verlenen met brede rollen zoals Owner of Contributor, maar in plaats daarvan specifieke rollen te gebruiken die zijn afgestemd op de vendor's taken. Een effectieve aanpak is het gebruik van aangepaste RBAC-rollen die specifiek zijn ontworpen voor vendor-toegang. Deze rollen kunnen worden gebaseerd op de vendor's functie: een 'Vendor Developer' rol kan bijvoorbeeld toegang verlenen tot development-omgevingen en source code repositories, maar geen toegang tot productieomgevingen of gevoelige data. Een 'Vendor Auditor' rol kan bijvoorbeeld toegang verlenen tot audit logs en beveiligingsconfiguraties, maar geen toegang tot applicatiecode of operationele systemen. Een 'Vendor Operator' rol kan bijvoorbeeld toegang verlenen tot specifieke resources voor onderhoud en troubleshooting, maar geen toegang tot alle resources in de omgeving. Door aangepaste rollen te gebruiken, kunnen organisaties ervoor zorgen dat vendors uitsluitend de toegang krijgen die nodig is voor hun specifieke taken, wat het risico op ongeautoriseerde toegang vermindert en compliance-vereisten ondersteunt. Toegang moet worden beperkt tot specifieke scopes (bijvoorbeeld resource groups, subscriptions, of individuele resources) op basis van de vendor's verantwoordelijkheden. Een vendor die bijvoorbeeld alleen verantwoordelijk is voor het beheer van een specifieke applicatie, moet alleen toegang krijgen tot de resource group waarin die applicatie zich bevindt, niet tot alle resource groups in de subscription. Een vendor die bijvoorbeeld alleen verantwoordelijk is voor beveiligingsmonitoring, moet alleen toegang krijgen tot Log Analytics workspaces en beveiligingsdashboards, niet tot applicatie-resources of data-opslag. Door toegang te beperken tot specifieke scopes, kunnen organisaties ervoor zorgen dat vendors niet per ongeluk of opzettelijk toegang krijgen tot resources buiten hun verantwoordelijkheden, wat het risico op datalekken en beveiligingsincidenten vermindert. Managed identities vormen de aanbevolen methode voor vendor-authenticatie bij Azure-services wanneer vendors applicaties of scripts uitvoeren die toegang nodig hebben tot Azure-resources. In plaats van service principals met client secrets (die zelf weer moeten worden beheerd en gedeeld) gebruiken managed identities automatisch beheerde identiteiten die geen credentials vereisen. Voor vendors die applicaties ontwikkelen of beheren die toegang nodig hebben tot Azure-resources, kunnen user-assigned managed identities worden gebruikt die onafhankelijk worden aangemaakt en aan meerdere resources kunnen worden gekoppeld. Deze managed identities kunnen worden gekoppeld aan specifieke RBAC-rollen, waardoor vendors alleen toegang krijgen tot de resources die nodig zijn voor hun applicaties, zonder dat zij directe toegang hebben tot Azure Portal of andere beheerinterfaces. Het PowerShell-script uit dit artikel kan worden gebruikt om te controleren of vendor-toegang correct is geconfigureerd met Azure RBAC, of toegang is beperkt tot specifieke scopes, en of managed identities worden gebruikt in plaats van service principals met secrets.

Gebruik PowerShell-script vendor-access-controls.ps1 (functie Test-VendorAccessControl) – Controleert of vendor-toegang correct is geconfigureerd met Azure RBAC en least privilege principes.

Tijdgebonden toegang en Just-In-Time (JIT) access voor vendors

Tijdgebonden toegang is essentieel voor vendor toegangscontrole omdat vendors niet permanent toegang nodig hebben tot Azure-omgevingen. In plaats daarvan moeten vendors toegang aanvragen en activeren wanneer zij deze nodig hebben, en moet toegang automatisch worden ingetrokken wanneer deze niet meer nodig is. Azure Privileged Identity Management (PIM) vormt de basis voor tijdgebonden toegang, waarbij vendors toegang aanvragen en activeren voor een beperkte periode (bijvoorbeeld 8 uur, 1 dag, of 1 week), en waarbij toegang automatisch wordt ingetrokken wanneer de periode verloopt. Just-In-Time (JIT) access betekent dat vendors toegang aanvragen en activeren op het moment dat zij deze nodig hebben, in plaats van permanente toegang te hebben. Wanneer een vendor bijvoorbeeld toegang nodig heeft tot een productieomgeving voor troubleshooting, vraagt de vendor toegang aan via PIM, geeft een reden op voor de toegang, en activeert de toegang voor een beperkte periode (bijvoorbeeld 8 uur). Na deze periode wordt de toegang automatisch ingetrokken, waardoor het risico op ongeautoriseerde toegang wordt verminderd. JIT access is vooral belangrijk voor vendors die toegang nodig hebben tot productieomgevingen of gevoelige data, omdat permanente toegang het risico op compromittering verhoogt wanneer vendor-accounts worden gecompromitteerd of wanneer vendors de organisatie verlaten. Goedkeuringsworkflows vormen een belangrijk onderdeel van JIT access voor hoog-risico toegang. Wanneer een vendor bijvoorbeeld toegang aanvraagt tot productieomgevingen met gevoelige data, moet de aanvraag worden goedgekeurd door een bevoegde persoon (bijvoorbeeld de security officer, de applicatie-eigenaar, of de CISO) voordat toegang wordt verleend. Deze goedkeuringsworkflows kunnen worden geconfigureerd in PIM, waarbij verschillende goedkeurders kunnen worden toegewezen op basis van de scope van toegang (bijvoorbeeld subscription-level toegang vereist goedkeuring van de CISO, resource group-level toegang vereist goedkeuring van de applicatie-eigenaar). Goedkeuringsworkflows zorgen ervoor dat toegang alleen wordt verleend wanneer deze daadwerkelijk noodzakelijk is en wanneer deze is goedgekeurd door bevoegde personen, wat het risico op ongeautoriseerde toegang vermindert en compliance-vereisten ondersteunt. Multi-factor authenticatie (MFA) moet worden afgedwongen voor alle vendor-toegang, ongeacht of deze permanent of tijdgebonden is. PIM ondersteunt MFA-afdwinging voor privileged role activations, waarbij vendors MFA moeten voltooien voordat zij toegang kunnen activeren. Daarnaast moeten vendors MFA gebruiken voor alle Azure Portal-toegang en voor alle API-toegang, waarbij Conditional Access policies worden gebruikt om MFA af te dwingen voor alle vendor-accounts. MFA vermindert het risico op compromittering wanneer vendor-credentials worden gelekt of gestolen, omdat aanvallers niet alleen de credentials nodig hebben, maar ook toegang tot de vendor's MFA-apparaat. Het PowerShell-script uit dit artikel kan worden gebruikt om te controleren of PIM is geconfigureerd voor vendor-toegang, of JIT access wordt gebruikt, of goedkeuringsworkflows zijn geconfigureerd, en of MFA wordt afgedwongen voor alle vendor-toegang.

Gebruik PowerShell-script vendor-access-controls.ps1 (functie Test-VendorTimeBoundAccess) – Controleert of vendor-toegang tijdgebonden is geconfigureerd met PIM en JIT access.

Monitoring en logging van vendor-activiteiten

Monitoring en logging zijn essentieel om te detecteren wanneer vendors ongeautoriseerde activiteiten uitvoeren, wanneer verdachte activiteiten plaatsvinden, en wanneer compliance-vereisten niet worden nageleefd. Azure genereert automatisch audit logs voor alle Azure RBAC-operaties, inclusief role assignments, role activations, en toegangspogingen. Deze logs kunnen worden opgeslagen in Azure Monitor en Log Analytics, waardoor organisaties queries kunnen uitvoeren, alerts kunnen configureren, en dashboards kunnen maken voor vendor-activiteiten. Voor Nederlandse overheidsorganisaties is het belangrijk om te monitoren op verdachte activiteiten zoals ongebruikelijke toegangspatronen (bijvoorbeeld toegang buiten normale werkuren, toegang vanaf onbekende locaties), gefaalde authenticatiepogingen, en wijzigingen aan kritieke configuraties. Azure Sentinel kan worden gebruikt om vendor logs te analyseren en security incidents te detecteren. Daarnaast moeten alerts worden geconfigureerd voor kritieke events zoals het activeren van privileged roles, het wijzigen van RBAC-configuraties, en het toegang krijgen tot gevoelige data. Deze alerts moeten worden verzonden naar security teams en compliance officers, zodat tijdig actie kan worden ondernomen wanneer verdachte activiteiten worden gedetecteerd. Compliance-rapportage is een belangrijk aspect van monitoring. Organisaties moeten periodiek rapporten genereren die aangeven welke vendors toegang hebben, welke rollen zijn toegewezen, wanneer toegang is geactiveerd en ingetrokken, en welke activiteiten zijn uitgevoerd. Deze rapporten kunnen worden gebruikt voor interne audits, externe assessments, en compliance-rapportage aan bestuur en directie. Voor Nederlandse overheidsorganisaties is het verstandig om een vaste rapportagecyclus af te spreken, bijvoorbeeld maandelijkse rapportages over vendor-toegang, activiteiten en compliance-status. Deze rapportages worden besproken in governance-overleggen met CISO, security officer en bestuur, en vormen de basis voor besluitvorming over vendor-toegang, prioritering van verbeteracties of acceptatie van rest-risico's. Audit trails moeten worden bewaard volgens BIO-vereisten (typisch 7 jaar voor kritieke logs). Azure Monitor en Log Analytics ondersteunen lange-termijn opslag van logs, waarbij logs kunnen worden gearchiveerd naar Azure Storage voor kostenefficiënte lange-termijn opslag. Daarnaast moeten audit logs worden beveiligd tegen wijziging en verwijdering, bijvoorbeeld door gebruik te maken van immutable storage of door logs te exporteren naar een extern systeem dat onder controle staat van de organisatie. Het PowerShell-script uit dit artikel kan worden gebruikt om vendor-activiteiten te monitoren, compliance-rapportages te genereren, en audit trails te verifiëren.

Gebruik PowerShell-script vendor-access-controls.ps1 (functie Invoke-VendorMonitoring) – Monitort vendor-activiteiten en genereert compliance-rapportages.

Compliance en audit voor vendor-toegang

Compliance en audit vormen de laatste pijler van een volwassen vendor toegangscontrole framework. Voor Nederlandse overheidsorganisaties die moeten voldoen aan NIS2, BIO en ISO 27001 is het essentieel dat vendor-toegang aantoonbaar voldoen aan compliance-vereisten. Dit vereist documentatie, configuratie, monitoring en periodieke assessments. Periodieke access reviews zijn essentieel om te verifiëren dat vendor-toegang nog steeds noodzakelijk is, dat vendors voldoen aan contractuele beveiligingsvereisten, en dat toegang wordt ingetrokken wanneer deze niet meer nodig is. Azure AD Access Reviews kunnen worden gebruikt om periodiek (bijvoorbeeld elk kwartaal) te controleren of vendor-toegang nog steeds nodig is, of vendors nog steeds actief zijn, en of toegang moet worden ingetrokken. Access reviews moeten worden uitgevoerd door bevoegde personen (bijvoorbeeld de applicatie-eigenaar, de security officer, of de CISO), waarbij expliciet wordt vastgelegd of toegang wordt behouden, gewijzigd of ingetrokken. De uitkomsten van access reviews moeten worden vastgelegd in auditrapporten, en bevindingen moeten worden opgevolgd met concrete acties (bijvoorbeeld het intrekken van toegang, het wijzigen van rollen, of het bijwerken van contractuele afspraken). Vendor compliance-verificatie is belangrijk om te verifiëren dat vendors voldoen aan contractuele beveiligingsvereisten. Dit kan bijvoorbeeld betekenen dat vendors periodiek moeten aantonen dat zij MFA gebruiken, dat zij security awareness training hebben gevolgd, dat zij incident response procedures hebben, of dat zij compliance-certificeringen hebben behouden. Deze verificatie kan worden uitgevoerd via vragenlijsten, audits, of certificeringsverificatie. Wanneer vendors niet voldoen aan contractuele beveiligingsvereisten, moet toegang worden ingetrokken totdat vendors voldoen aan de vereisten, of moeten contractuele afspraken worden bijgewerkt om nieuwe vereisten vast te leggen. Audit trails moeten worden bewaard volgens BIO-vereisten en moeten beschikbaar zijn voor interne audits en externe assessments. Audit trails moeten alle vendor-activiteiten bevatten, inclusief toegangsaanvragen, role activations, configuratiewijzigingen, en data-toegang. Deze audit trails moeten worden bewaard voor minimaal 7 jaar volgens BIO-vereisten, en moeten worden beveiligd tegen wijziging en verwijdering. Het PowerShell-script uit dit artikel kan worden gebruikt om te controleren of access reviews worden uitgevoerd, of vendor compliance wordt geverifieerd, en of audit trails correct zijn geconfigureerd.

Gebruik PowerShell-script vendor-access-controls.ps1 (functie Test-VendorCompliance) – Controleert of vendor-toegang voldoen aan compliance-vereisten zoals access reviews en audit logging.

Vendor offboarding en toegangsintrekking

Vendor offboarding is een kritieke stap in het vendor toegangscontrole proces die vaak wordt vergeten of onvoldoende wordt uitgevoerd. Wanneer een vendor-contract eindigt, wanneer een vendor de organisatie verlaat, of wanneer een vendor niet meer nodig is, moet alle toegang worden ingetrokken om te voorkomen dat vendors na het einde van hun contract nog steeds toegang hebben tot Azure-omgevingen. Voor Nederlandse overheidsorganisaties is het essentieel dat vendor offboarding wordt uitgevoerd volgens een gestructureerd proces dat ervoor zorgt dat alle toegang wordt ingetrokken, dat audit logs worden bewaard, en dat accounts en credentials worden verwijderd of gedeactiveerd. Het offboarding-proces moet beginnen met een inventarisatie van alle vendor-toegang: welke RBAC-rollen zijn toegewezen, welke PIM-rollen zijn geconfigureerd, welke managed identities zijn gebruikt, welke service principals zijn aangemaakt, en welke resources zijn toegankelijk. Deze inventarisatie kan worden uitgevoerd met behulp van Azure Portal, Azure CLI, of PowerShell-scripts. Zodra alle toegang is geïdentificeerd, moet deze systematisch worden ingetrokken: RBAC-rollen worden verwijderd, PIM-rollen worden gedeactiveerd, managed identities worden verwijderd of ontkoppeld, service principals worden verwijderd of gedeactiveerd, en accounts worden verwijderd of gedeactiveerd. Audit logs moeten worden bewaard volgens BIO-vereisten (typisch 7 jaar voor kritieke logs) en moeten alle vendor-activiteiten bevatten tot aan het moment van offboarding. Deze audit logs kunnen worden gebruikt voor compliance-rapportage, interne audits, en externe assessments. Daarnaast moeten contractuele afspraken worden nageleefd: wanneer een vendor-contract bijvoorbeeld vereist dat data wordt verwijderd of teruggegeven, moet dit worden uitgevoerd voordat toegang wordt ingetrokken. Wanneer een vendor-contract bijvoorbeeld vereist dat kennis wordt overgedragen, moet dit worden uitgevoerd voordat toegang wordt ingetrokken. Verificatie is belangrijk om te verifiëren dat alle toegang daadwerkelijk is ingetrokken. Dit kan worden uitgevoerd door te controleren of RBAC-rollen zijn verwijderd, of PIM-rollen zijn gedeactiveerd, of accounts zijn verwijderd of gedeactiveerd, en of er geen actieve sessies zijn. Het PowerShell-script uit dit artikel kan worden gebruikt om vendor offboarding te automatiseren, toegang te inventariseren en in te trekken, en verificatie uit te voeren om te verifiëren dat alle toegang is ingetrokken.

Gebruik PowerShell-script vendor-access-controls.ps1 (functie Invoke-VendorOffboarding) – Automatiseert vendor offboarding door toegang te inventariseren en in te trekken.

Compliance & Frameworks

• BIO: 08.03.01, 09.01.02, 09.02.01, 12.01.01, 12.04.01 - Toegangscontrole en monitoring van externe toegang voor vendors in Azure-omgevingen voor Nederlandse overheidsorganisaties
• ISO 27001:2022: A.5.19, A.8.1.1, A.8.2.1, A.8.2.3, A.8.3.1, A.15.1.1, A.15.2.1 - Supplier relationships, access control en monitoring voor vendor-toegang in Azure-omgevingen
• NIS2: Artikel - Supply chain security en risicobeheersing voor third-party toegang in Azure-omgevingen voor essentiële en belangrijke entiteiten

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

Implementeer vendor toegangscontrole met zes pijlers: vendor onboarding en risicoassessment, toegangsbeheer en RBAC, tijdgebonden toegang en JIT access, monitoring en logging, compliance en audit, en vendor offboarding. Essentieel voor NIS2 supply chain security en BIO compliance. Implementatie: 360 uur.

• Implementatietijd: 360 uur
• FTE required: 1 FTE