Due Diligence Voor Azure Omgevingen Bij Overnames En Fusies

Overnames en fusies brengen vaak meerdere Azure-tenants, abonnementen en beheermodellen samen. Zonder een systematische due diligence kunnen organisaties onverwachts geconfronteerd worden met ernstige beveiligingsproblemen: verouderde configuraties die niet voldoen aan de eigen security-standaarden, ontbrekende compliance-controles die leiden tot audit-findings, verborgen kosten door inefficiënte resource-allocaties, of zelfs actieve security-incidenten die nog niet zijn opgelost. In de praktijk zien we dat organisaties tijdens integratietrajecten pas laat ontdekken dat een overgenomen Azure-omgeving bijvoorbeeld geen MFA vereist voor beheerders, dat er gedeelde accounts worden gebruikt zonder logging, dat kritieke workloads in verouderde regio's draaien zonder disaster recovery, of dat er geen Azure Policy's zijn geconfigureerd waardoor nieuwe resources automatisch onveilig worden aangemaakt. Deze problemen escaleren snel wanneer de omgevingen worden samengevoegd: een zwakke schakel in de ene tenant kan de beveiliging van de gehele geïntegreerde omgeving compromitteren. Bovendien brengen fusies en overnames vaak compliance-uitdagingen met zich mee: de overgenomen organisatie kan andere classificaties hanteren voor data, andere BIO-niveaus hebben toegepast, of andere contractuele verplichtingen hebben met cloudproviders die niet compatibel zijn met de eigen governance-structuur. Een grondige due diligence voorkomt dat deze problemen pas tijdens de integratie of bij een eerste audit aan het licht komen, wat kan leiden tot vertragingen, extra kosten, reputatieschade of zelfs juridische aansprakelijkheid.

Implementatie

Dit artikel beschrijft een gestructureerd due diligence-proces specifiek voor Azure-omgevingen, dat organisaties helpt om vóór een overname of fusie een volledig beeld te krijgen van de beveiligingsstatus, compliance-positie, technische volwassenheid en operationele risico's van de te verwerven Azure-infrastructuur. Het proces start met een inventarisatiefase waarin alle Azure-tenants, abonnementen, management groups en kritieke workloads worden geïdentificeerd en gedocumenteerd. Vervolgens wordt een systematische beoordeling uitgevoerd langs vier hoofdlijnen: beveiligingsconfiguratie (zoals identity-beveiliging, netwerksegmentatie, logging en monitoring), compliance en governance (zoals aanwezigheid van Azure Policy's, resource tagging, cost management en data residency-controles), technische volwassenheid (zoals gebruik van moderne architectuurpatronen, automatisering, disaster recovery en update-beleid), en operationele risico's (zoals technische schuld, documentatiekwaliteit, kennis bij teams en afhankelijkheden van externe partijen). Voor elk van deze lijnen worden concrete checklists en assessment-criteria gebruikt die aansluiten bij de Nederlandse Baseline voor Veilige Cloud, BIO-normen en NIS2-vereisten. De uitkomsten worden samengebracht in een risicomatrix die duidelijk maakt welke problemen kritiek zijn en direct moeten worden aangepakt vóór integratie, welke acceptabel zijn maar wel monitoring vereisen, en welke kunnen worden meegenomen in een post-merger verbeterplan. Het artikel bevat ook praktische richtlijnen voor het uitvoeren van technische assessments, het beoordelen van compliance-documentatie, het schatten van remediatiekosten en het opstellen van integratie-scenario's die rekening houden met de gevonden risico's.

Vereisten

Een effectieve due diligence voor Azure-omgevingen vereist toegang tot de te beoordelen Azure-tenant, maar ook een duidelijke scope, gestructureerde methodiek en voldoende tijd om grondig onderzoek te kunnen doen. Een eerste cruciale vereiste is het verkrijgen van de juiste toegangsrechten en credentials voor de Azure-omgeving die wordt beoordeeld. In de praktijk betekent dit dat de due diligence-team minimaal leesrechten nodig heeft op alle relevante abonnementen en management groups, toegang tot Azure Portal en PowerShell-omgevingen, en inzicht in bestaande documentatie, policy's en compliance-rapportages. Idealiter heeft het team ook tijdelijk verhoogde rechten om bepaalde configuraties te kunnen verifiëren zonder wijzigingen aan te brengen. Het is belangrijk dat deze toegang formeel wordt geregeld via de juiste kanalen binnen de te verwerven organisatie, met duidelijke afspraken over wat wel en niet wordt onderzocht, en met respect voor eventuele vertrouwelijkheidsvereisten. Een tweede vereiste is het hebben van een gestructureerde assessment-methodiek die specifiek is afgestemd op Azure en cloud-omgevingen. Een generieke IT-due diligence die vooral kijkt naar on-premises systemen en netwerken mist typisch de cloud-specifieke risico's zoals misconfiguraties van identity providers, ontbrekende Azure Policy's, onjuiste resource tagging, of problemen met data residency en cross-border data transfers. De methodiek moet daarom expliciet aandacht besteden aan Azure-specifieke beveiligingscontroles zoals Conditional Access policies, Privileged Identity Management, Defender for Cloud configuraties, Log Analytics workspace-instellingen, en de inrichting van management groups en subscription-hiërarchieën. Bovendien moet de methodiek aansluiten bij de compliance-kaders die voor de eigen organisatie gelden – zoals BIO, NIS2 of ISO 27001 – zodat duidelijk kan worden beoordeeld of de overgenomen omgeving voldoet aan dezelfde standaarden die de organisatie hanteert. Daarnaast is er expertise nodig binnen het due diligence-team op het gebied van Azure-architectuur, beveiliging en compliance. Het team moet niet alleen kunnen werken met Azure Portal en PowerShell, maar ook de implicaties begrijpen van verschillende configuratiekeuzes, kunnen inschatten welke risico's bepaalde architectuurpatronen met zich meebrengen, en kunnen beoordelen of bestaande documentatie en processen voldoende zijn voor een veilige integratie. In veel gevallen is het raadzaam om externe specialisten in te schakelen die onafhankelijk kunnen beoordelen en die ervaring hebben met vergelijkbare due diligence-processen in de publieke sector. Deze expertise is vooral belangrijk bij het interpreteren van technische bevindingen en het vertalen daarvan naar concrete risico's en kostenramingen. Een vierde vereiste betreft de beschikbaarheid van referentiemateriaal en baseline-documenten waartegen de te verwerven omgeving kan worden afgezet. Dit omvat niet alleen de eigen security-standaarden en compliance-eisen, maar ook concrete implementatievoorbeelden, checklists en best practices die zijn gebaseerd op de Nederlandse Baseline voor Veilige Cloud. Zonder duidelijke referenties is het moeilijk om objectief te beoordelen of een bepaalde configuratie acceptabel is of dat er verbetering nodig is. Het is daarom aan te raden om voorafgaand aan de due diligence een set assessment-criteria op te stellen die expliciet beschrijven wat als 'goed', 'acceptabel met voorwaarden' of 'onacceptabel' wordt beschouwd voor elk beoordeeld aspect. Tot slot moet er voldoende tijd en budget worden gereserveerd voor een grondige due diligence. Een oppervlakkige assessment die alleen kijkt naar enkele hoog-niveau metrics zoals Secure Score of het aantal geconfigureerde policy's, mist vaak de dieperliggende problemen die pas tijdens integratie of bij een eerste audit aan het licht komen. Een volledige due diligence voor een middelgrote Azure-omgeving met meerdere abonnementen en kritieke workloads kan gemakkelijk enkele weken in beslag nemen, afhankelijk van de complexiteit en de beschikbaarheid van documentatie en key personnel. Het is belangrijk dat dit wordt meegenomen in de planning van het M&A-proces, zodat de due diligence niet wordt overhaast en belangrijke risico's niet worden gemist.

Implementatie

Gebruik PowerShell-script acquisition-due-diligence.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van een due diligence voor Azure-omgevingen start met een voorbereidingsfase waarin de scope wordt bepaald en de benodigde toegang wordt geregeld. In deze fase wordt allereerst een overzicht gemaakt van alle Azure-tenants en abonnementen die onder de scope vallen van de due diligence. Dit omvat niet alleen de primaire productie-omgevingen, maar ook development-, test- en sandbox-abonnementen, omdat ook deze omgevingen risico's kunnen bevatten of inzicht kunnen geven in de volwassenheid van de organisatie. Vervolgens wordt bepaald welke management groups, resource groups en kritieke workloads specifiek moeten worden beoordeeld, en welke kunnen worden meegenomen in een meer oppervlakkige review. Parallel hieraan wordt de toegang geregeld: het due diligence-team krijgt de benodigde Azure-rollen toegewezen, er worden afspraken gemaakt over toegang tot documentatie en key personnel, en er wordt een tijdlijn opgesteld voor de verschillende assessment-activiteiten. In de tweede fase wordt een systematische inventarisatie uitgevoerd van alle relevante Azure-resources, configuraties en governance-structuren. Dit begint met het in kaart brengen van de tenant- en subscription-structuur: hoeveel tenants zijn er, hoe zijn de management groups georganiseerd, welke abonnementen bestaan er en wat is hun doel en classificatie? Vervolgens worden alle kritieke workloads geïnventariseerd: welke applicaties en services draaien in Azure, welke data verwerken ze, wat is hun bedrijfskritiekheid en welke afhankelijkheden hebben ze? Deze inventarisatie wordt ondersteund door het PowerShell-script dat bij dit artikel hoort, dat automatisch een overzicht genereert van alle abonnementen, management groups, policy assignments en resource-distributies. De output van dit script vormt de basis voor verdere, meer diepgaande assessments. De derde fase bestaat uit het uitvoeren van gedetailleerde security- en compliance-assessments langs de vier hoofdlijnen. Voor beveiligingsconfiguratie wordt onder meer gekeken naar: de inrichting van identity en access management (zoals MFA-dekking, gebruik van PIM, aanwezigheid van break-glass-accounts, en configuratie van Conditional Access), netwerkbeveiliging (zoals gebruik van private endpoints, NSG-regels, firewall-configuraties en netwerksegmentatie), logging en monitoring (zoals aanwezigheid van Log Analytics workspaces, configuratie van diagnostic settings, integratie met SIEM-systemen en retentieperiodes), en data protection (zoals encryptie-instellingen, back-upconfiguraties en data classification). Voor compliance en governance wordt beoordeeld: de aanwezigheid en configuratie van Azure Policy's en initiatieven, het gebruik van resource tagging en cost management, de naleving van data residency-vereisten, en de aanwezigheid van formele governance-documentatie zoals security policies, runbooks en change management-processen. Voor technische volwassenheid wordt gekeken naar aspecten zoals: het gebruik van Infrastructure as Code en automatisering, de toepassing van moderne architectuurpatronen (zoals microservices, serverless of container-gebaseerde oplossingen), de aanwezigheid van disaster recovery en business continuity-plannen, en het patch- en update-beleid voor Azure-services en workloads. Operationele risico's worden beoordeeld door te kijken naar: de kwaliteit en volledigheid van documentatie, de beschikbaarheid van kennis bij teams, afhankelijkheden van externe consultants of managed service providers, en de aanwezigheid van technische schuld die toekomstige migraties of upgrades kan bemoeilijken. De vierde fase betreft het analyseren van de bevindingen en het opstellen van een risicomatrix en aanbevelingsrapport. Alle gevonden issues worden geclassificeerd op basis van hun ernst (kritiek, hoog, medium, laag) en impact (beveiliging, compliance, operationeel, financieel). Issues die direct moeten worden opgelost vóór integratie worden expliciet gemarkeerd, evenals issues die acceptabel zijn maar wel monitoring vereisen. Voor elk kritiek of hoog risico wordt een schatting gemaakt van de benodigde remediatie-inspanning en -kosten, en wordt aangegeven welke expertise en resources nodig zijn. Het rapport wordt afgesloten met concrete aanbevelingen voor het integratiescenario: kan de omgeving direct worden geïntegreerd, zijn er eerst mitigaties nodig, of is een gefaseerde aanpak met tussenstappen vereist? Het PowerShell-script ondersteunt dit proces door objectieve, kwantificeerbare metrics te leveren die kunnen worden gebruikt om de bevindingen te onderbouwen en prioritering te ondersteunen.

Monitoring

Gebruik PowerShell-script acquisition-due-diligence.ps1 (functie Invoke-Monitoring) – Controleren.

Monitoring tijdens een due diligence-proces richt zich op het continu bijhouden van de assessment-vorderingen en het tijdig signaleren van nieuwe risico's of afwijkingen die tijdens het onderzoek aan het licht komen. In tegenstelling tot reguliere operationele monitoring, is due diligence-monitoring vooral gericht op het verzamelen van een compleet en accuraat beeld van de te beoordelen omgeving binnen een beperkte tijdsperiode. Een belangrijk aspect hiervan is het bijhouden van welke assessments zijn voltooid, welke nog open staan, en welke bevindingen zijn gedocumenteerd. Dit helpt om te voorkomen dat belangrijke onderdelen worden overgeslagen of dat dezelfde configuraties meerdere keren worden beoordeeld zonder dat de resultaten worden geconsolideerd. Een tweede aspect van monitoring betreft het volgen van technische metrics die kunnen wijzen op veranderingen in de omgeving tijdens de due diligence-periode. Wanneer bijvoorbeeld nieuwe resources worden aangemaakt, policy's worden gewijzigd, of er ongebruikelijke activiteiten plaatsvinden in de Azure-tenant, kan dit duiden op pogingen om problemen te verbergen of op onverwachte operationele wijzigingen die de assessment-resultaten beïnvloeden. Het PowerShell-script dat bij dit artikel hoort kan periodiek worden uitgevoerd om dergelijke veranderingen te detecteren, bijvoorbeeld door het aantal abonnementen, policy assignments of resource counts te vergelijken met eerdere metingen. Dit helpt om te zorgen dat de due diligence-resultaten gebaseerd zijn op een stabiel en representatief beeld van de omgeving. Daarnaast is het belangrijk om tijdens de due diligence te monitoren of alle benodigde informatie en toegang daadwerkelijk beschikbaar zijn. Wanneer bepaalde documentatie ontbreekt, key personnel niet beschikbaar zijn voor interviews, of bepaalde Azure-onderdelen niet toegankelijk zijn voor assessment, moet dit worden gedocumenteerd als een beperking van de due diligence. Deze beperkingen moeten expliciet worden vermeld in het eindrapport, omdat ze kunnen wijzen op governance-problemen of op bewuste obstructie, en omdat ze de betrouwbaarheid van de assessment kunnen beïnvloeden. Monitoring helpt om dergelijke gaten tijdig te identificeren, zodat er nog gelegenheid is om aanvullende informatie op te vragen of alternatieve assessment-methoden toe te passen. Tot slot moet monitoring tijdens due diligence ook aandacht besteden aan de kwaliteit en consistentie van de verzamelde data. Wanneer verschillende assessors verschillende bevindingen rapporteren over vergelijkbare configuraties, of wanneer automatische scans andere resultaten opleveren dan handmatige reviews, moet dit worden geanalyseerd om te bepalen welke bron betrouwbaarder is en of er aanvullende verificatie nodig is. Het gebruik van gestandaardiseerde checklists, assessment-criteria en geautomatiseerde scripts helpt om deze consistentie te waarborgen, maar vereist wel dat de resultaten regelmatig worden gereviewd en gevalideerd door senior teamleden.

Compliance en Auditing

Due diligence voor Azure-omgevingen heeft een directe relatie met compliance en auditing, omdat het proces moet aantonen dat de te verwerven omgeving voldoet aan dezelfde normen en eisen die de organisatie hanteert. Voor Nederlandse overheidsorganisaties betekent dit concreet dat de due diligence moet beoordelen of de overgenomen Azure-omgeving voldoet aan BIO-normen, NIS2-vereisten en AVG-verplichtingen op hetzelfde niveau als de eigen omgeving. Wanneer dit niet het geval is, moet dit worden geïdentificeerd als een compliance-risico dat moet worden gemitigeerd vóór of tijdens de integratie. Het due diligence-rapport dient daarom expliciet per relevante norm of framework aan te geven wat de compliance-status is, welke tekortkomingen zijn gevonden, en welke remediatie nodig is om tot het gewenste niveau te komen. Voor NIS2 is het vooral belangrijk om te beoordelen of de te verwerven organisatie en haar Azure-omgeving voldoet aan de vereisten voor essentiële of belangrijke entiteiten. Dit omvat onder meer de aanwezigheid van passende beveiligingsmaatregelen, incident response-capaciteiten, supply chain security-controles en rapportage-vereisten. Wanneer een overname leidt tot een wijziging in de status als essentiële of belangrijke entiteit, of wanneer de gecombineerde organisatie nieuwe kritieke diensten gaat leveren, moet dit worden meegenomen in de compliance-beoordeling. De due diligence moet daarom niet alleen kijken naar de huidige configuratie, maar ook naar de impact van de integratie op de NIS2-status en -verplichtingen. Voor het BIO-raamwerk moet de due diligence beoordelen of de informatieclassificaties, beveiligingsmaatregelen en governance-structuren in de overgenomen omgeving compatibel zijn met de eigen BIO-implementatie. Wanneer de te verwerven organisatie andere classificaties hanteert, andere BIO-thema's heeft geïmplementeerd, of andere interpretaties heeft van bepaalde normen, kan dit leiden tot inconsistenties die moeten worden opgelost tijdens de integratie. Het is daarom belangrijk om tijdens de due diligence niet alleen te kijken naar de technische configuraties, maar ook naar de onderliggende governance-documentatie, classificatiebesluiten en risicoanalyses die zijn uitgevoerd volgens het BIO-kader. De AVG vereist dat organisaties kunnen aantonen dat zij passende technische en organisatorische maatregelen hebben getroffen voor de verwerking van persoonsgegevens. Bij een overname of fusie moet worden beoordeeld of de overgenomen Azure-omgeving voldoet aan deze vereisten, en of de geplande integratie geen nieuwe risico's introduceert voor de bescherming van persoonsgegevens. Dit omvat onder meer de beoordeling van encryptie-instellingen, toegangscontroles, logging en monitoring van data-verwerking, en de aanwezigheid van processen voor het afhandelen van data subject rights. Wanneer de due diligence tekortkomingen identificeert, moet dit worden meegenomen in de planning van de integratie, en moet mogelijk worden overwogen om de Autoriteit Persoonsgegevens te informeren over de overname en de geplande maatregelen. Voor audit-doeleinden is het essentieel dat het due diligence-proces zelf goed is gedocumenteerd en reproduceerbaar is. Dit betekent dat alle assessments moeten zijn uitgevoerd volgens een vastgestelde methodiek, dat alle bevindingen zijn gedocumenteerd met onderbouwing en bewijs, en dat de conclusies en aanbevelingen traceerbaar zijn naar de onderliggende data. Het gebruik van geautomatiseerde scripts en gestandaardiseerde checklists helpt hierbij, maar vereist wel dat de scripts zelf, hun configuraties en hun outputs worden bewaard als audit trail. Wanneer externe auditors later vragen stellen over de due diligence of over beslissingen die zijn genomen op basis van de bevindingen, moet kunnen worden aangetoond dat het proces grondig, objectief en methodisch is uitgevoerd.

Remediatie

Gebruik PowerShell-script acquisition-due-diligence.ps1 (functie Invoke-Remediation) – Herstellen.

Remediatie in de context van due diligence voor Azure-omgevingen heeft een andere betekenis dan bij reguliere security-operations. Het gaat hier niet primair om het direct oplossen van gevonden problemen, maar om het bepalen welke remediatie nodig is vóór, tijdens of na de integratie, en om het schatten van de benodigde inspanning en kosten. De due diligence zelf is immers een assessment-fase waarin idealiter geen wijzigingen worden aangebracht aan de te beoordelen omgeving, om te voorkomen dat de assessment-resultaten worden beïnvloed of dat er onbedoelde schade wordt veroorzaakt. Remediatie betekent in deze context vooral het opstellen van een concreet plan voor het adresseren van gevonden risico's, met prioritering, tijdlijnen en resource-vereisten. De eerste stap in remediatie is het classificeren van alle gevonden issues op basis van hun kritiekheid voor de integratie. Issues die direct moeten worden opgelost vóór integratie – bijvoorbeeld omdat ze een directe beveiligingsrisico vormen of omdat ze compliance-problemen veroorzaken die niet acceptabel zijn – worden gemarkeerd als 'pre-integration critical'. Voor deze issues moet een gedetailleerd remediatieplan worden opgesteld dat beschrijft welke stappen nodig zijn, wie verantwoordelijk is voor de uitvoering, binnen welke termijn dit moet gebeuren, en welke resources en expertise nodig zijn. Het is belangrijk dat dit plan realistisch is en rekening houdt met de beschikbaarheid van teams, de complexiteit van de wijzigingen, en eventuele afhankelijkheden met andere M&A-activiteiten. Issues die acceptabel zijn maar wel monitoring of mitigatie vereisen tijdens de integratie worden geclassificeerd als 'integration monitoring required'. Voor deze issues wordt een plan opgesteld dat beschrijft hoe ze zullen worden gemonitord tijdens de integratie, welke tijdelijke mitigaties kunnen worden toegepast om risico's te beperken, en binnen welke termijn na de integratie ze definitief moeten zijn opgelost. Dit kan bijvoorbeeld betekenen dat bepaalde workloads tijdelijk worden geïsoleerd, dat extra logging wordt ingeschakeld, of dat bepaalde functionaliteiten worden uitgeschakeld totdat de onderliggende problemen zijn opgelost. Issues die kunnen worden meegenomen in een post-merger verbeterplan worden geclassificeerd als 'post-integration improvement'. Deze issues vormen geen blokkade voor de integratie, maar moeten wel worden gedocumenteerd en opgenomen in een roadmap voor continue verbetering. Het is belangrijk dat deze roadmap wordt gekoppeld aan de reguliere governance- en security-processen van de geïntegreerde organisatie, zodat de verbeteringen daadwerkelijk worden uitgevoerd en niet worden vergeten na de eerste maanden van de integratie. Voor alle categorieën van issues moet een realistische schatting worden gemaakt van de benodigde remediatie-inspanning en -kosten. Dit helpt het management om weloverwogen beslissingen te nemen over de haalbaarheid van de integratie, de benodigde budgetten, en de prioritering van verschillende remediatie-activiteiten. De schattingen moeten gebaseerd zijn op ervaring met vergelijkbare remediaties, op de complexiteit van de gevonden problemen, en op de beschikbaarheid van expertise en resources. Het PowerShell-script dat bij dit artikel hoort kan hierbij ondersteunen door objectieve metrics te leveren over de omvang van de omgeving en de complexiteit van de configuraties, die kunnen worden gebruikt om de inspanningsschattingen te onderbouwen. Tot slot moet het remediatieplan expliciet aandacht besteden aan de governance en het eigenaarschap van de remediatie-activiteiten. Wie is verantwoordelijk voor het uitvoeren van de remediaties, wie is verantwoordelijk voor het monitoren van de voortgang, en wie neemt beslissingen wanneer er onverwachte problemen optreden? Zonder duidelijke verantwoordelijkheden en escalatiepaden kunnen remediaties vertragen of stagneren, wat de integratie kan beïnvloeden of kan leiden tot het accepteren van onnodige risico's. Het is daarom aan te raden om het remediatieplan te koppelen aan de bestaande projectmanagement- en governance-structuren van de organisatie, zodat het niet als een losstaand initiatief wordt behandeld maar als een integraal onderdeel van het M&A-proces.

Compliance & Frameworks

• BIO: 16.01.01, 17.01.02, 18.01.01 - Risicomanagement en continuïteitsbeheer bij organisatorische wijzigingen
• ISO 27001:2022: A.6.1.2, A.8.2.1, A.14.2.1 - Informatiebeveiligingsrisicobeheer en beveiliging in ontwikkelings- en ondersteuningsprocessen
• NIS2: Artikel - Beleid, procedures en governance voor beheer van cyberrisico's bij organisatorische wijzigingen

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

Due diligence voor Azure-omgevingen bij overnames en fusies is een systematisch proces om vóór integratie een volledig beeld te krijgen van beveiligingsstatus, compliance-positie, technische volwassenheid en operationele risico's. Het proces omvat inventarisatie van tenants en abonnementen, assessment van security-configuraties, compliance en governance, technische volwassenheid en operationele risico's, analyse van bevindingen in een risicomatrix, en opstellen van remediatieplannen met prioritering en kostenramingen. Naleving van BIO, NIS2 en AVG vereist dat overgenomen omgevingen voldoen aan dezelfde normen, wat moet worden geverifieerd tijdens due diligence. Dit is een kritieke governance-activiteit die moet worden uitgevoerd bij elke overname of fusie waarbij Azure-omgevingen worden geïntegreerd.

• Implementatietijd: 72 uur
• FTE required: 0.5 FTE