NIS2-richtlijn: Implementatie- en nalevingsroadmap voor Microsoft 365

CLOUD SERVICES GDPR ISO 27001 SOC 2 Compliance Status 90%

De NIS2-richtlijn (EU 2022/2555) vervangt de oorspronkelijke NIS en vergroot de scope van een paar honderd naar duizenden Nederlandse organisaties. Vanaf 17 oktober 2024 vallen vrijwel alle overheidsorganisaties, uitvoerende diensten en vitale aanbieders onder nationaal toezicht en kan de toezichthouder boetes tot €10 miljoen of 2% van de wereldwijde omzet opleggen. Bestuurders blijven persoonlijk verantwoordelijk voor een aantoonbaar risicogestuurde beveiligingsaanpak, incidentmelding en ketenbeveiliging.

Microsoft 365 en Azure zijn voor de meeste Nederlandse organisaties de ruggengraat voor communicatie, samenwerking en identiteitsbeheer. Juist daar moeten de tien maatregelen uit artikel 21 landen: van risicobeoordeling en meervoudige authenticatie tot crisiscommunicatie en leverancierstoezicht. Deze gids koppelt NIS2-eisen aan Purview, Defender, Sentinel en Secure Score, zodat je de BIO-eisen en NIS2-verplichtingen met één controlestelsel afdekt en tegelijkertijd bewijslast opbouwt voor audits.

Wat je leert

Deze gids laat zien hoe je de NIS2-maatregelen doorvertaalt naar Purview, Defender, Sentinel en Secure Score, hoe je meldprocedures binnen 24 en 72 uur uitvoert, hoe je BC/DR-tests en back-ups documenteert en hoe je leveranciers en OAuth-apps volgens de richtlijn beoordeelt. Je leert bovendien bewijsvoering te automatiseren zodat audits soepel verlopen.

Gebruik Secure Score als stuurmiddel

Leg elk NIS2-risico vast met de corresponderende Secure Score-actie. Zo kun je bestuurders elke maand laten zien welke verbeteringen zijn doorgevoerd, welk risico is geaccepteerd en welke acties nog openstaan. Zonder trenddata blijft NIS2-compliance een momentopname en kun je tijdens een audit geen verbetercyclus aantonen.

NIS2-basics: reikwijdte, verplichtingen en impact voor Nederland

De NIS2-richtlijn (EU 2022/2555) markeert een flinke intensivering van de Europese eisen aan netwerk- en informatiesystemen. Waar de oorspronkelijke NIS een relatief kleine groep vitale aanbieders betrof, breidt NIS2 het toezicht uit naar vrijwel alle organisaties die publieke diensten, digitale infrastructuur of essentiële ketens ondersteunen. Voor Nederlandse overheidsorganisaties draait de richtlijn om aantoonbare weerbaarheid: niet alleen beschikken over procedures, maar vooral kunnen laten zien dat beleid daadwerkelijk wordt uitgevoerd, getest en verbeterd. De richtlijn maakt duidelijke koppelingen met risicogestuurde sturing, waardoor de Raad van Bestuur en de portefeuillehouder Digitale Overheid inhoudelijk moeten kunnen uitleggen hoe keuzes tot stand zijn gekomen.

In Nederland vertaalt de Wet beveiliging netwerk- en informatiesystemen (Wbni) de Europese vereisten naar nationale verplichtingen. Het NCSC en sectorale Computer Security Incident Response Teams leveren dreigingsinformatie, Agentschap Telecom en DNB voeren het primaire toezicht uit, en de Autoriteit Persoonsgegevens let op de overlap met de AVG. Deze mix betekent dat CISO’s niet alleen met technische maatregelen bezig zijn, maar ook structureel moeten afstemmen met juridische adviseurs en proceseigenaren. Bestuurders blijven persoonlijk verantwoordelijk, omdat NIS2 expliciet benoemt dat zij toezicht moeten houden op risicobeheer, incidentrapportage en ketenafspraken.

Voor Nederlandse organisaties is het onderscheid tussen essentiële en belangrijke entiteiten minder zwart-wit dan het lijkt. Essentiële entiteiten omvatten diensten waarvan uitval direct maatschappelijke ontwrichting veroorzaakt, zoals Rijksbrede shared services, drinkwaterbedrijven en de nationale identiteitsinfrastructuur. Belangrijke entiteiten zijn bijvoorbeeld grote gemeenten, regionale uitvoeringsdiensten of dienstverleners die honderden publieke tenants beheren. Ook kleinere instellingen kunnen alsnog in scope vallen zodra zij unieke taken uitvoeren of deel uitmaken van een kritische keten, bijvoorbeeld een nicheleverancier die toegang heeft tot de identiteitsbron van meerdere ministeries. De praktijk vereist dus dat elke organisatie zelf onderzoekt welke ketenafhankelijkheden relevant zijn, in plaats van af te wachten of Den Haag formeel aanwijst.

De kwantitatieve drempels uit artikel 3 lijken eenvoudig—minstens vijftig medewerkers en tien miljoen euro omzet voor belangrijke entiteiten, dan wel tweehonderdvijftig medewerkers en vijftig miljoen euro voor grote ondernemingen—maar ze zijn vooral bedoeld als minimum. Zodra een organisatie vitale processen faciliteert, gelden de NIS2-eisen ongeacht de omvang. Hierdoor verschijnen ook shared service centers, onderwijsinstellingen en ondersteunende IT-dienstverleners in scope. Een nieuw aangestelde programmamanager moet dus direct inventariseren welke diensten onder Wbni vallen, welke contracten ketenafspraken bevatten en hoe de huidige BIO-implementatie aansluit op de Europese verplichtingen.

Het sanctiestelsel onderstreept de ernst. Essentiële entiteiten riskeren bestuurlijke boetes tot tien miljoen euro of twee procent van de wereldwijde omzet; belangrijke entiteiten kunnen zeven miljoen euro of 1,4 procent tegemoet zien. Toezichthouders mogen bestuurders aanwijzingen geven, tijdelijk schorsen of persoonlijk aansprakelijk stellen bij aantoonbare nalatigheid. Dat betekent dat verslaglegging over risicobesluiten, testresultaten en incidentafhandeling net zo belangrijk is als het technische controleregister. Het bestuur moet kunnen aantonen dat het frequent geïnformeerd wordt, dat verbeteracties worden afgedwongen en dat het escalatiemechanisme daadwerkelijk werkt.

Artikel 21 bundelt tien maatregelen die samen een integraal stelsel vormen. Risicobeheer en beleid fungeren als fundament, waarna incidentrespons, bedrijfscontinuïteit, ketenbeveiliging en secure-by-design maatregelen het operationele hart vormen. Effectiviteitstoetsing en logging waarborgen dat maatregelen blijven presteren, terwijl cryptografie, identiteits- en assetbeheer en meervoudige authenticatie de toegangskant afdekken. Tot slot vereist de richtlijn beveiligde communicatiekanalen zodat bestuurders, leveranciers en toezichthouders bij een crisis op dezelfde feiten kunnen vertrouwen. In Microsoft 365 en Azure betekent dit dat Purview, Defender, Sentinel, Entra ID en de diverse beheerportalen niet langer losse initiatieven zijn, maar gezamenlijk bewijs moeten opleveren dat elk artikel 21-onderdeel daadwerkelijk is ingericht.

Een bijkomend voordeel van deze integrale benadering is de koppeling met de Baseline Informatiebeveiliging Overheid (BIO) en de Nederlandse Baseline voor Veilige Cloud. Door dezelfde sturingscyclus te gebruiken voor BIO-controles, NIS2-artikelen en interne risicorapportages ontstaat een traceerbare lijn van beleidsintentie naar technische configuratie. Daarmee kunnen auditors direct zien hoe een Secure Score-maatregel, een Purview-labelbeleid of een Sentinel-playbook bijdraagt aan een specifieke wettelijke verplichting. Organisaties die deze samenhang nu al uitwerken, ervaren dat NIS2 niet louter een complianceoefening is, maar een katalysator voor professionele governance en aantoonbare digitale weerbaarheid.

NIS2 maatregel 1: Risicomanagement en beleid in Microsoft Cloud

Artikel 21 lid 1 verplicht organisaties om risicoanalyse en beveiligingsbeleid niet als statische documenten te behandelen maar als een voortdurend verbeterproces. Voor Microsoft 365 en Azure-landschappen betekent dit dat de Purview Data Map, Defender for Cloud, Secure Score en Compliance Manager samen het zenuwstelsel vormen waarmee risico’s zichtbaar worden gemaakt, geëvalueerd en aangescherpt. Door elk controlerapport direct te koppelen aan een NIS2-maatregel ontstaat een audittrail die aantoont dat managementbesluiten gebaseerd zijn op actuele feiten in plaats van verouderde jaarplannen.

Een robuust risico-overzicht start met een volledige inventarisatie van assets, gegevensstromen en proceseigenaren. Purview Data Map herkent automatisch SharePoint-sites, Teams, Exchange-postvakken, OneDrive-accounts en Azure-resources; vervolgens verrijk je elk object met BIO-classificaties en proceseigenaarschap. Door deze inventarisatie te koppelen aan het werkproces—denk aan burgerzaken, vergunningverlening of HR—begrijpt een auditor direct waarom de data bestaat, welke wettelijke grondslag geldt en welke ketenpartners meekijken. Het registreren van lifecycle-data voorkomt bovendien dat verouderde werkruimten blindelings toegang blijven houden tot gevoelige informatie.

Het dreigingsbeeld vormt de tweede pijler. Nederlandse organisaties combineren MITRE ATT&CK met adviezen van het NCSC, de Informatiebeveiligingsdienst (IBD) en Microsoft Threat Intelligence om scenario’s op te stellen die passen bij geopolitieke spanningen, supplychain-aanvallen of gerichte phishingcampagnes tegen ambtenaren. Door indicatoren zoals kwetsbaarheden in VPN-gateways, verdachte OAuth-apps of toegenomen brute-force activiteit vast te leggen in een centrale bibliotheek, kan het SOC prioriteiten afstemmen met het risicoteam. In dezelfde workflow leg je ook interne factoren vast, zoals organisatorische wijzigingen, fusies of tijdelijke uitbestedingen die een andere risico-acceptatie vergen.

Kwetsbaarheden worden structureel beoordeeld via Defender Vulnerability Management, Secure Score en Defender for Cloud. Elke ontdekking krijgt een oplostermijn die aansluit op de ernst: kritieke issues binnen achtenveertig uur, hoge severities binnen zeven dagen en middelhoge binnen dertig dagen. Het systeem registreert automatisch of patches zijn uitgerold, of compensating controls actief zijn en welke teams verantwoordelijk zijn voor follow-up. Door deze data door te zetten naar Power BI zien bestuurders of verbeteringen tijdig worden afgerond en of extra capaciteit nodig is voor bijvoorbeeld verouderde applicaties of beheerplatforms.

De risico-uitkomst wordt vastgelegd in een uniform register waarin kans en impact op een schaal van één tot vier worden gescoord. In woorden beschrijf je de dreiging, de kwetsbaarheid en de gekozen maatregel, inclusief verantwoordelijke eigenaar en herbeoordelingsdatum. Een concreet voorbeeld: ransomware op een Exchange-server scoort hoog op kans en kritiek op impact, waarna het patchteam binnen vierentwintig uur updates aanbrengt en Defender for Endpoint monitoring activeert. Een tweede voorbeeld betreft privilege misuse doordat niet alle adminaccounts multi-factor authenticatie gebruiken; het identity-team schakelt phishing-resistente methoden en Privileged Identity Management in en rapporteert de afronding. Onderstaande tabel vat dergelijke situaties samen en toont hoe acties, controles en statussen overzichtelijk blijven voor auditors.

Omdat management expliciet moet instemmen met risico-acceptaties, wordt elke acceptatie digitaal ondertekend in het risicoregister en gekoppeld aan een besluitvormingsmoment in het bestuursoverleg. Acceptaties krijgen een looptijd, bijvoorbeeld tot het moment waarop een legacy-platform is uitgefaseerd of een leverancier een nieuwe auditrapportage heeft aangeleverd. Door Secure Score-trends naast het risicoregister te leggen, zien bestuurders welk effect investeringen hebben. Dat maakt de balans tussen kosteneffectiviteit en veiligheid concreet: een maatregel die weinig Secure Score-punten oplevert maar wel een NIS2-risico reduceert, blijft toch prioriteit omdat de wettelijke eisen zwaarder wegen.

De documentatie vormt de laatste stap. Elk risico is gekoppeld aan bewijs, zoals exportbestanden, beleidsdocumenten, screenshots of scripts. Deze bewijsstukken worden opgeslagen in een afgeschermde SharePoint-site met versiebeheer, zodat inspecteurs kunnen nagaan wanneer wijzigingen hebben plaatsgevonden. Audits verlopen daardoor sneller, omdat duidelijk is welke gegevensbron hoort bij een bepaald risico en welke persoon aanspreekpunt is. Bovendien maakt deze aanpak het mogelijk om BIO-controles, NIS2-eisen en interne KPI’s te combineren zonder drie verschillende registers bij te houden; één geïntegreerd dossier volstaat.

markdown
| Risico-ID | Dreiging | Kwetsbaarheid | Kans | Impact | Score | Actie | Control | Eigenaar | Status | Herbeoordeling | |-----------|----------|---------------|------|--------|-------|-------|---------|---------|--------|----------------| | R-001 | Ransomware | Niet-gepatchte Exchange-server | Hoog (3) | Kritiek (4) | 12 | Mitigeren | Patch binnen 24 uur, Defender for Endpoint | IT-beveiliging | In uitvoering | 2024-10-25 | | R-002 | Credential theft | Geen MFA op adminaccounts | Hoog (3) | Kritiek (4) | 12 | Mitigeren | Phishing-resistente MFA, PIM | Identity-team | Afgerond | 2024-11-01 | | R-003 | Data-exfiltratie | Publieke SharePoint-sites | Middel (2) | Hoog (3) | 6 | Mitigeren | DLP, sensitivity labels, rechtenherziening | Compliance | In uitvoering | 2024-10-30 | | R-004 | Insider threat | Te brede adminrechten | Middel (2) | Hoog (3) | 6 | Mitigeren | Least privilege, access reviews | IAM-team | Gepland | 2024-11-15 | | R-005 | Leveranciersketen | OAuth-app met te veel rechten | Laag (1) | Hoog (3) | 3 | Mitigeren | OAuth-governance, toestemmingsbeleid | Security | In uitvoering | 2024-11-01 | | R-006 | DDoS-aanval | Publieke webapplicaties | Laag (1) | Middel (2) | 2 | Overdragen | Azure DDoS Protection Standard | Netwerkteam | Afgerond | 2024-09-15 | | R-007 | Legacy-platform | End-of-life Windows Server 2008 | Laag (1) | Middel (2) | 2 | Accepteren | Gesegmenteerd, uitfaseren in Q1 2025 | IT-operations | Geaccepteerd | 2025-01-31 |

NIS2 maatregel 2: Incidentafhandeling en meldplicht

Artikel 23 van NIS2 introduceert een strak tijdpad voor incidentmeldingen: binnen vierentwintig uur een vroegtijdige waarschuwing, binnen tweeënzeventig uur een voortgangsrapport en binnen een maand een eindrapport. Voor organisaties die zwaar leunen op Microsoft 365 en Azure betekent dit dat de SOC-processen, juridische meldingen richting toezichthouders en communicatie met bestuurders tot op de minuut moeten zijn afgestemd. Zonder geoefende draaiboeken en heldere besluitvorming is het onmogelijk om feiten, forensische gegevens en risico-inschattingen binnen deze termijnen te verzamelen.

De detectiefase begint met het samenbrengen van signalen uit Defender XDR, Microsoft Sentinel, Purview Audit en meldingen vanuit gebruikers of leveranciers. Door standaard KQL-queries te draaien, dashboards te monitoren en alerts te correleren met MITRE-technieken, bepaalt het SOC of een incident NIS2-meldwaardig is. In dezelfde minuut worden context en gevoeligheid vastgelegd: welke systemen zijn geraakt, welke data is mogelijk ingezien en of er aanwijzingen zijn voor ketenimpact. Deze informatie stroomt automatisch naar een casemanagementsysteem zodat juristen en communicatieadviseurs direct kunnen meekijken.

Tijdens de triagefase wordt een incident commander aangewezen die beslissingsbevoegdheid heeft. Het team stelt prioriteiten op basis van maatschappelijke impact, wettelijke verplichtingen en reputatierisico. Ze bepalen welke diensten essentieel zijn voor burgers of bedrijven en leggen vast welke continuïteit bedreigd wordt. Tegelijkertijd wordt geverifieerd of er AVG-aspecten spelen, zodat een eventuele datalekmelding gecoördineerd kan plaatsvinden. Door triage te koppelen aan vooraf ingevulde rapportagevelden ontstaat consistentie in alle meldingen, ook als verschillende teams de afhandeling verzorgen.

Indammen en uitroeien vragen om nauwe samenwerking tussen SOC, identity-team en applicatiebeheerders. Defender for Endpoint kan apparaten isoleren, Entra ID trekt refresh tokens in en Microsoft Purview blokkeert delingslinks of zet sites in quarantaine. In Azure worden netwerkbeveiligingsgroepen aangepast en in Microsoft 365 kan Exchange Online gecompromitteerde accounts onmiddellijk blokkeren. Alle acties worden gelogd, inclusief tijdstempel en verantwoordelijke, zodat het eindrapport exact laat zien welke maatregelen op welk moment het risico hebben teruggebracht. Parallel wordt de communicatie naar bestuur en ketenpartners verzorgd, zodat zij maatregelen kunnen treffen.

Het rapportageproces is meer dan het invullen van een formulier; het vereist een begrijpelijk narratief dat de toezichthouder inzicht geeft in oorzaken, impact en verbetermaatregelen. Binnen vierentwintig uur beschrijf je de eerste feiten, mogelijke betrokken ketenpartners en of er voorlopige maatregelen zijn getroffen. Binnen tweeënzeventig uur volgen forensische resultaten, voorlopige impactanalyses en de verwachte vervolgstappen. Het eindrapport bevat root cause, lessons learned, herstelacties en een evaluatie van de communicatie. Door alle versies in een Purview eDiscovery-case te archiveren, is achteraf aantoonbaar dat deadlines zijn gehaald en dat informatie consistent is gebleven.

Automatisering waarborgt snelheid zonder het vier-ogenprincipe te verliezen. Logic Apps en Sentinel-playbooks analyseren op basis van KQL, zoals het script hieronder, welke containment-acties passend zijn bij het incidenttype en de ernst. Het systeem adviseert bijvoorbeeld om apparaten te isoleren, adminrechten te verwijderen of direct het CISO-team te alarmeren. Automatische afhandeling is alleen toegestaan onder vooraf vastgestelde voorwaarden, bijvoorbeeld maximaal tien entiteiten per incident en verplichte goedkeuring door de incident commander. Zo blijft de mens aan het roer, terwijl repetitieve taken binnen seconden worden uitgevoerd.

Tenslotte worden procedures regelmatig getest via tabletop-oefeningen en technische simulaties. SOC-analisten draaien rampscenario’s met vooraf geselecteerde Sentinel-incidents, bestuurders oefenen de crisiscommunicatie en juristen toetsen de meldformulieren tegen NIS2- en AVG-eisen. Elke oefening levert verbeteracties op, variërend van extra training in KQL tot het uitbreiden van rolbeschrijvingen. Via deze cyclus blijft de organisatie onder de meldtermijnen, ook wanneer meerdere incidenten tegelijk plaatsvinden of wanneer ketenpartners extra informatie eisen.

kql
// Automated containment decision tree // This query determines appropriate containment actions based on incident severity SecurityIncident | where TimeGenerated > ago(1h) | where Status == "New" | extend Severity = tostring(Properties.severity) | extend IncidentType = tostring(Properties.title) | extend AffectedEntities = Properties.relatedEntities // Extract affected accounts and devices | mv-expand Entity = AffectedEntities | extend EntityType = tostring(Entity['kind']) | extend EntityValue = tostring(Entity['name']) // Determine containment actions based on incident characteristics | extend ContainmentAction = case( // Critical incidents: Immediate aggressive containment Severity == "High" and IncidentType has "Ransomware", "IsolateDevice+DisableAccount+AlertCISO", Severity == "High" and IncidentType has "Data Exfiltration", "DisableAccount+RevokeTokens+LegalHold", Severity == "High" and IncidentType has "Privilege Escalation", "DisableAccount+RevokeAdminRights+AlertSOC", // Medium severity: Moderate containment Severity == "Medium" and IncidentType has "Phishing", "QuarantineEmail+ResetPassword+MFAChallenge", Severity == "Medium" and IncidentType has "Malware", "IsolateDevice+QuarantineFile+Scan", // Low severity: Monitoring and documentation Severity == "Low", "Monitor+DocumentActivity", // Default "ManualReview" ) // Generate containment recommendation | summarize IncidentID = any(IncidentNumber), Severity = any(Severity), IncidentType = any(IncidentType), AffectedAccounts = make_set_if(EntityValue, EntityType == "account"), AffectedDevices = make_set_if(EntityValue, EntityType == "host"), RecommendedAction = any(ContainmentAction), EntityCount = count() by TimeGenerated // Priority scoring for automated execution | extend AutomationEligible = iff( Severity in ("High", "Critical") and EntityCount <= 10, // Limit automated actions to <10 entities true, false ) | project TimeGenerated, IncidentID, Severity, IncidentType, AffectedAccounts, AffectedDevices, RecommendedAction, AutomationEligible | order by Severity desc

NIS2 maatregel 3: Bedrijfscontinuïteit en herstel

NIS2 verbindt bedrijfscontinuïteit en herstel expliciet aan cybersecurity doordat artikel 21 lid 2c verplicht tot het onderhouden van werkende plannen, gescheiden back-ups en aantoonbaar geteste scenario’s. Microsoft 365 en Azure bieden weliswaar ingebouwde redundantie, maar de verantwoordelijkheid voor configuratie, testresultaten en herstelbesluiten blijft bij de organisatie. Daardoor kan risicomanagement niet los worden gezien van business continuity management: de CISO, CIO en proceseigenaren sturen samen op dezelfde draaiboeken.

Het opstellen van RTO- en RPO-waarden begint bij het bepalen welke diensten cruciaal zijn voor burgers en bedrijven. Voor een gemeente kunnen dat identiteitsverificatie, uitkeringsbetalingen of omgevingsloketten zijn; voor een ministerie zijn het beleidsdossiers en vertrouwelijke communicatie. Per dienst leg je vast welk tijdsverlies nog acceptabel is en hoeveel dataherstel mogelijk is zonder dat wettelijke taken in gevaar komen. Deze waarden worden gekoppeld aan Azure Site Recovery, Microsoft 365 Backup, Exchange lagged copies en alternatieve werkprocedures. Door de waarden jaarlijks met proceseigenaren te herzien, blijven ze realistisch, zeker bij grote migraties of reorganisaties.

Een scenario dat steevast terugkomt is een volledige Azure-regiostoring. Hoewel Microsoft replicatie en failover verzorgt voor platformdiensten, moet de organisatie exact weten welke workloads geo-redundant zijn ingericht en welke handelingen nodig zijn om failover te starten. Dit omvat de configuratie van Azure Traffic Manager, het synchroniseren van secrets via Key Vault, het herstellen van identiteiten via Entra ID Connect en het opnieuw distribueren van Conditional Access-beleid wanneer gebruikers plots in een andere regio landen. Documenteer ook welke onderdelen onder de verantwoordelijkheid van Microsoft vallen en waar je eigen team stappen moet zetten. Alleen dan kun je tijdens een crisis snel beoordelen of aanvullende maatregelen nodig zijn, zoals het tijdelijk overschakelen op papieren procedures of het verplaatsen van een SOC-team naar een back-uplocatie.

Ransomware blijft een realistisch risico voor Microsoft 365. Het preventieve deel bestaat uit Defender for Office 365, Defender for Endpoint, attack surface reduction en intensieve monitoring in Sentinel. Toch moet je ervan uitgaan dat een gebruiker of beheerder ooit slachtoffer wordt. Daarom ligt er een uitgewerkt herstelpad waarin OneDrive, SharePoint, Exchange en Teams data teruggezet kunnen worden naar een schoon herstelpunt. Het PowerShell-script hieronder automatiseert een groot deel van dat proces door OneDrive te herstellen naar een eerder tijdstip, SharePoint-sites te reconstrueren en e-mail uit de Recoverable Items-map terug te kopiëren. Belangrijk is dat je na elke herstelactie controles uitvoert: zijn de bestanden vrij van malware, is de versiegeschiedenis nog intact en zijn de gebruikers geïnformeerd over eventuele dataverliezen?

Documentatie van BC/DR-tests is een harde eis. Elke test benoemt de aanleiding, datum, betrokken systemen, meetresultaten en verbeteracties. Wanneer tijdens een oefening blijkt dat contactgegevens verouderd zijn of dat een processtap ontbreekt, wordt dat direct toegevoegd aan het draaiboek en opnieuw getest. Testresultaten worden gekoppeld aan het risicoregister en aan het boardreport, zodat het bestuur trends ziet: werden RTO’s gehaald, liep de communicatie soepel en zijn nieuwe afhankelijkheden opgedoken? Door lessons learned te koppelen aan investeringsbesluiten kan het bestuur aantonen dat het actief stuurt op herstelbaarheid.

BC/DR is ten slotte verweven met andere kaders zoals de BIO, de Wet open overheid en sectorale continuïteitsrichtlijnen. Wanneer je dezelfde documentatie gebruikt voor NIS2, BIO en interne audits voorkom je dubbel werk en toon je consistentie aan. Beschermingsniveaus BBN2 en BBN3 sluiten goed aan op de NIS2-vereiste om ook tijdens een crisis vertrouwelijkheid, integriteit en beschikbaarheid te borgen. Door alle scenario’s op dezelfde SharePoint-omgeving te beheren ontstaat één bron van waarheid die zowel auditors als crisisteams direct kunnen raadplegen.

powershell
# Microsoft 365 Ransomware Recovery Script # Restore OneDrive and SharePoint files to pre-attack state param( [Parameter(Mandatory=$true)] [string]$UserPrincipalName, # Affected user [Parameter(Mandatory=$true)] [datetime]$RestorePointDateTime # Point in time before attack ) Connect-SPOService -Url "https://contoso-admin.sharepoint.com" Connect-MgGraph -Scopes "Files.ReadWrite.All", "Sites.ReadWrite.All" Write-Host "Microsoft 365 Ransomware Recovery" -ForegroundColor Cyan Write-Host "==========================================" Write-Host "User: $UserPrincipalName" Write-Host "Restore Point: $($RestorePointDateTime.ToString('yyyy-MM-dd HH:mm:ss'))" Write-Host "" # Get user's OneDrive site $oneDriveSite = Get-SPOSite -Filter "Owner -eq '$UserPrincipalName'" -IncludePersonalSite $true if (-not $oneDriveSite) { Write-Error "OneDrive site not found for user: $UserPrincipalName" exit 1 } $oneDriveUrl = $oneDriveSite.Url Write-Host "OneDrive URL: $oneDriveUrl" -ForegroundColor Yellow # Restore OneDrive to previous point in time try { Write-Host "Initiating OneDrive restore to $RestorePointDateTime..." -ForegroundColor Cyan # Use SharePoint Online Management Shell cmdlet Restore-SPODeletedSite -Identity $oneDriveUrl -NoWait # Alternative: File-level restore via Graph API $siteId = ($oneDriveSite.Url -split '/')[-1] $restorePayload = @{ restorePointDateTime = $RestorePointDateTime.ToString("yyyy-MM-ddTHH:mm:ssZ") } # This requires Microsoft Graph API with beta endpoint Invoke-MgGraphRequest -Method POST ` -Uri "https://graph.microsoft.com/v1.0/users/$UserPrincipalName/drive/root/restore" ` -Body ($restorePayload | ConvertTo-Json) Write-Host "✓ OneDrive restore initiated successfully" -ForegroundColor Green Write-Host " Restore typically completes within 1-4 hours depending on data volume" } catch { Write-Error "OneDrive restore failed: $($_.Exception.Message)" } # Restore SharePoint sites if user is site owner/admin Write-Host "" Write-Host "Checking SharePoint sites owned by user..." -ForegroundColor Cyan $userSites = Get-SPOSite -Filter "Owner -eq '$UserPrincipalName'" | Where-Object { -not $_.IsPersonalSite } if ($userSites) { Write-Host "Found $($userSites.Count) SharePoint site(s):" -ForegroundColor Yellow foreach ($site in $userSites) { Write-Host " • $($site.Url)" try { # Restore site collection to previous version # Note: This requires SharePoint Admin rights Invoke-SPOSiteSwap -SourceUrl $site.Url ` -TargetUrl "$($site.Url)-restore" ` -ArchiveUrl "$($site.Url)-archive" Write-Host " ✓ Site restore initiated" -ForegroundColor Green } catch { Write-Warning " Failed to restore site: $($_.Exception.Message)" } } } else { Write-Host "No SharePoint sites owned by this user" -ForegroundColor Gray } # Restore deleted emails from Recoverable Items (if mailbox was affected) Write-Host "" Write-Host "Checking Exchange mailbox for recoverable items..." -ForegroundColor Cyan Connect-ExchangeOnline try { # Search for deleted items in Recoverable Items folder $deletedItems = Search-Mailbox -Identity $UserPrincipalName ` -SearchDumpsterOnly ` -SearchQuery "Received >= '$($RestorePointDateTime.ToString('yyyy-MM-dd'))'" ` -EstimateResultOnly if ($deletedItems.ResultItemsCount -gt 0) { Write-Host "Found $($deletedItems.ResultItemsCount) recoverable email items" -ForegroundColor Yellow # Restore items from Recoverable Items to Inbox Search-Mailbox -Identity $UserPrincipalName ` -SearchDumpsterOnly ` -SearchQuery "Received >= '$($RestorePointDateTime.ToString('yyyy-MM-dd'))'" ` -TargetMailbox $UserPrincipalName ` -TargetFolder "Inbox\Recovered-Ransomware" ` -LogLevel Full Write-Host "✓ Email items restored to folder: Inbox\Recovered-Ransomware" -ForegroundColor Green } else { Write-Host "No deleted email items found" -ForegroundColor Gray } } catch { Write-Warning "Email recovery failed: $($_.Exception.Message)" } # Generate recovery report Write-Host "" Write-Host "Recovery Summary:" -ForegroundColor Cyan Write-Host "==========================================" Write-Host "User: $UserPrincipalName" Write-Host "Restore Point: $($RestorePointDateTime.ToString('yyyy-MM-dd HH:mm:ss'))" Write-Host "OneDrive: Restore initiated" Write-Host "SharePoint Sites: $($userSites.Count) site(s) processed" Write-Host "Email Items: $($deletedItems.ResultItemsCount) items recovered" Write-Host "" Write-Host "Next Steps:" -ForegroundColor Yellow Write-Host "1. Monitor restore progress in SharePoint Admin Center" Write-Host "2. Verify file integrity after restore completion" Write-Host "3. Re-scan restored files for malware" Write-Host "4. Document incident in NIS2 incident log" Write-Host "5. Review security controls to prevent recurrence" Disconnect-ExchangeOnline -Confirm:$false

NIS2 maatregel 4: Ketenbeveiliging en derde-partijrisico’s

Ketenbeveiliging, vastgelegd in artikel 21 lid 2d, verplicht organisaties om verder te kijken dan de eigen tenant. Microsoft 365-omgevingen zitten vol integraties met leveranciers, consultants, SaaS-applicaties en tijdelijke projecten. Als één van die schakels faalt, ligt de verantwoordelijkheid alsnog bij de oorspronkelijke organisatie. Daarom moeten leveranciersregisters, beoordelingstrajecten en technische monitoring naadloos op elkaar aansluiten.

Een actueel register bevat niet alleen bedrijfsnamen maar ook toegangssoorten, data-impact, contractverantwoordelijken en toegewezen proceseigenaren. In plaats van generieke categorieën beschrijf je per partij waarom toegang nodig is, welke datasets geraakt worden en welke authenticatiemiddelen gelden. Hoewel veel organisaties spreken over drie tiers—kritiek, hoog en middel—leg je in narratieve vorm vast welke kenmerken bij elk niveau horen. Een kritieke leverancier is bijvoorbeeld een managed service provider met Global Adminrechten, terwijl een middelmatige leverancier slechts beperkte toegang heeft tot een projectsite. Door deze context op te nemen, begrijpen auditors meteen waarom een partij in een bepaalde categorie valt.

Due diligence stopt niet bij onboarding. Jaarlijkse beoordelingen toetsen of SOC2-rapportages, ISO 27001-certificaten of BIO-verklaringen nog geldig zijn, of incidentmeldingen tijdig worden gedeeld en of subverwerkers conform contract worden gemeld. Contractsjablonen bevatten clausules over meldtermijnen, recht op audit, verplichtingen rond meervoudige authenticatie en eisen aan logging. Wanneer een leverancier niet voldoet, documenteer je het herstelpad inclusief escalaties richting de contractmanager en het bestuur. Dit voorkomt dat ketenrisico’s onder de radar blijven omdat de technische toegang toevallig goed is ingeregeld.

Technische monitoring richt zich op de dominante risicovectoren in Microsoft 365: OAuth-apps met brede Graph-rechten, externe deeltokens, Power Platform-connectors en GDAP-relaties met dienstverleners. Defender for Cloud Apps, Entra ID en Purview leveren de signalen waarmee je ontdekt of applicaties meer rechten hebben dan afgesproken of al maanden inactief zijn. Het KQL-voorbeeld hieronder laat zien hoe je applicaties met risicovolle permissies identificeert, een risico-score toekent en automatisch acties voorstelt. Alle bevindingen worden gekoppeld aan het leveranciersregister, zodat je precies weet welke contractuele afspraken geraakt worden.

Ook B2B-gastaccounts vragen om strakke governance. Elk account krijgt een eigenaar, een vervaldatum en een beschrijving van de dataset waartoe toegang wordt verleend. Verlopen accounts worden via Identity Governance automatisch geblokkeerd, terwijl risicovolle sessies via Conditional Access aanvullende verificatie eisen. GDAP-relaties met beheerders krijgen tijdelijke toestemming, gekoppeld aan een ticketnummer en gecontroleerd via access reviews. Deze procesmatige borging toont aan dat ketenpartijen alleen toegang houden zolang dat aantoonbaar nodig is.

Ketenbeveiliging eindigt pas wanneer monitoring en rapportage de resultaten terugkoppelen aan het bestuur. Dashboards laten zien hoeveel leveranciers een beoordeling hebben ondergaan, hoeveel OAuth-apps als kritisch zijn aangemerkt en welke gastaccounts zijn opgeschoond. Door deze inzichten te koppelen aan investeringsplannen kan het bestuur beslissen of extra tooling, contractmanagement of training nodig is. Zo wordt ketenbeveiliging een bestuurlijk thema in plaats van een technische bijzaak.

Wanneer een leverancier een incident veroorzaakt, moet de organisatie laten zien dat beslissingen tijdig zijn genomen en dat ketenpartners onmiddellijk zijn geïnformeerd. Het incidentlog beschrijft daarom op minutenbasis wanneer een OAuth-app werd ingetrokken, welke fallback-leverancier is geactiveerd en welke communicatie richting bestuur en toezichthouder is verstuurd. Die transparantie zorgt ervoor dat eventuele sancties aantoonbaar rekening houden met de inspanningen van de organisatie en dat andere ketenpartners vertrouwen houden in de samenwerking. Bovendien sluit deze werkwijze aan op de Nederlandse Baseline voor Veilige Cloud doordat ketenafspraken, autorisaties en herstelacties in één dossier zijn ondergebracht.

kql
// OAuth App Supply Chain Risk Assessment // Identify high-risk third-party applications with access to Microsoft 365 let riskAssessmentPeriod = 90d; // Get all OAuth apps with delegated permissions let oauthApps = CloudAppEvents | where TimeGenerated > ago(riskAssessmentPeriod) | where Application has "OAuth" | summarize LastActivity = max(TimeGenerated), ActivityCount = count(), UniqueUsers = dcount(AccountObjectId), ActivityTypes = make_set(ActivityType) by ApplicationId, Application | join kind=leftouter ( // Get app metadata from Azure AD AADServicePrincipalSignInLogs | where TimeGenerated > ago(riskAssessmentPeriod) | extend AppId = tostring(ServicePrincipalId) | extend AppName = tostring(ServicePrincipalName) | summarize TotalSignIns = count(), UniqueUsersSignedIn = dcount(UserPrincipalName), Locations = make_set(Location) by AppId, AppName ) on $left.ApplicationId == $right.AppId; // Get OAuth consent grants (permissions) let appPermissions = AuditLogs | where TimeGenerated > ago(riskAssessmentPeriod) | where OperationName == "Consent to application" | extend AppId = tostring(TargetResources[0].id) | extend AppName = tostring(TargetResources[0].displayName) | extend Permissions = tostring(TargetResources[0].modifiedProperties) | mv-expand Permission = split(Permissions, ",") | summarize GrantedPermissions = make_set(Permission) by AppId, AppName; // Define high-risk permissions let highRiskPermissions = dynamic([ "Mail.ReadWrite", "Mail.Send", "Files.ReadWrite.All", "Sites.ReadWrite.All", "User.ReadWrite.All", "Directory.ReadWrite.All", "RoleManagement.ReadWrite.Directory", "Mail.ReadBasic.All", "Calendars.ReadWrite" ]); // Combine data and calculate risk score oauthApps | join kind=leftouter (appPermissions) on $left.ApplicationId == $right.AppId | extend HasHighRiskPermissions = iff( set_has_element(GrantedPermissions, highRiskPermissions), true, false ) // Calculate activity metrics | extend DaysSinceLastActivity = datetime_diff('day', now(), LastActivity) | extend IsDormant = iff(DaysSinceLastActivity > 90, true, false) | extend LowActivityRate = iff(ActivityCount < 10, true, false) // Publisher verification (not available in logs, manual check required) | extend PublisherVerified = false // Manual verification required // Calculate composite risk score | extend RiskScore = iff(HasHighRiskPermissions, 40, 0) + iff(IsDormant, 30, 0) + iff(LowActivityRate, 20, 0) + iff(PublisherVerified == false, 25, 0) + iff(UniqueUsers > 100, 15, 0) // Broad user base = higher impact // Risk classification | extend RiskTier = case( RiskScore >= 80, "Critical", RiskScore >= 60, "High", RiskScore >= 40, "Medium", "Low" ) // Recommended actions | extend RecommendedAction = case( RiskTier == "Critical", "Immediate review required - Consider revoking access", RiskTier == "High", "Review within 7 days - Validate business justification", RiskTier == "Medium", "Review within 30 days - Verify permissions align with usage", "Monitor - Include in quarterly access review" ) | project Application, RiskTier, RiskScore, RecommendedAction, LastActivity, DaysSinceLastActivity, ActivityCount, UniqueUsers, HasHighRiskPermissions, IsDormant, GrantedPermissions | order by RiskScore desc // Generate executive summary | summarize TotalApps = count(), CriticalRiskApps = countif(RiskTier == "Critical"), HighRiskApps = countif(RiskTier == "High"), MediumRiskApps = countif(RiskTier == "Medium"), LowRiskApps = countif(RiskTier == "Low"), DormantApps = countif(IsDormant), HighPrivilegeApps = countif(HasHighRiskPermissions)

Doorlopende monitoring en NIS2-auditrapportage

Zonder harde bewijslast blijft NIS2-compliance een papieren oefening. Daarom fungeert Microsoft Purview Compliance Manager als het centrale controleregister waarin artikel 21 en 23 worden vertaald naar concrete acties, verantwoordelijken en bewijsstukken. Door alle assessments in dezelfde digitale omgeving te beheren, ontstaat een onverbrekelijke keten van doelstellingen, maatregelen en resultaten.

Het startpunt is een eigen assessmenttemplate waarin je de wettelijke tekst herschrijft naar organisatiecontext. In plaats van generieke nummers benoem je per maatregel welke processen, applicaties en teams betrokken zijn. Bijvoorbeeld: maatregel één over risicoanalyse verwijst naar de Purview Data Map, het risicoregister en de vergadercyclus van het bestuur. Voor artikel 23 beschrijf je hoe de incidentmeldingen in Sentinel worden vastgelegd en hoe de juridische afdeling het rapport aanlevert bij de toezichthouder. Deze vertaalslag maakt dat auditors begrijpen hoe de wet in jouw omgeving landt.

Daarna koppel je Microsoft-controls aan elk assessmentonderdeel. Conditional Access, Identity Protection en registratieoverzichten vullen maatregel negen (meervoudige authenticatie) in, terwijl Defender for Cloud, automation accounts en policy-as-code invulling geven aan secure-by-design eisen. Purview eDiscovery en Records Management ondersteunen de verplichting om documentatie te bewaren en te presenteren. Door zowel technische als organisatorische controls vast te leggen, voorkom je een te eenzijdige focus op tooling en toon je aan dat processen, training en governance even zwaar wegen.

Bewijsverzameling verloopt grotendeels automatisch. Compliance Manager importeert configuratiegegevens, auditlogs en rapportages en koppelt die aan improvement actions. Wanneer een control niet volledig is afgedekt, geeft het systeem verbeteracties inclusief verantwoordelijke, deadline en verwachte impact. Scripts, zoals PowerShell-exports van Conditional Access of KQL-rapportages uit Sentinel, worden als bijlage toegevoegd. Hierdoor wordt elke auditvraag beantwoord met objectieve data in plaats van mondelinge toelichting.

Dashboards bieden realtime inzicht in de voortgang. Secure Score en Compliance Score tonen trendlijnen, terwijl Power BI-rapportages laten zien hoeveel incidenten binnen de normtijd zijn afgehandeld, hoeveel BC/DR-tests succesvol zijn verlopen en hoeveel leveranciersreviews openstaan. Deze cijfers vormen de kern van het managementverslag dat elk kwartaal wordt gedeeld. Het markdownrapport hieronder schetst hoe zo’n verslag is opgebouwd, inclusief status per maatregel, kerncijfers en geplande verbeteracties. Door dezelfde structuur telkens te gebruiken kunnen bestuurders ontwikkelingen vergelijken en gericht doorvragen.

Tot slot zorgt een gestandaardiseerd rapport dat bestuurders en toezichthouders zien hoe techniek, processen en beleid in elkaar grijpen. De CISO licht toe welke maatregelen op koers liggen, de CFO ziet welke investeringen rendement opleveren en de secretaris-generaal bevestigt dat besluitvorming aantoonbaar is vastgelegd. Omdat de rapportage direct verwijst naar onderliggende bewijsstukken, kunnen audits sneller plaatsvinden en kunnen toezichthouders vertrouwen op de betrouwbaarheid van de cijfers. Zo wordt compliance monitoring een integraal onderdeel van strategische sturing en niet louter een verplicht nummertje.

Daarnaast koppelen overheidsorganisaties de compliance-artefacten aan archief- en transparantieverplichtingen uit de Archiefwet en de Wet open overheid. Elk rapport krijgt een bewaartermijn, metadata over besluitvorming en een verwijzing naar de onderliggende SharePoint-locatie zodat verzoeken van toezichthouders of burgers snel kunnen worden beantwoord. Door deze informatiehuishouding integraal te regelen, voorkomen organisaties dat audits, Woo-verzoeken en parlementaire vragen elkaar doorkruisen en ontstaat een duurzaam bewijsarchief dat jarenlang standhoudt. Het resultaat is dat CISO’s tijdens audits direct kunnen verwijzen naar een compleet digitaal dossier waarin alle besluiten, metingen en bewijzen overzichtelijk per maatregel zijn gegroepeerd.

markdown
# NIS2-compliancerapport **Organisatie**: [Naam organisatie] **Rapportageperiode**: [Q1 2025] **Rapportdatum**: [2025-01-15] **Opgesteld door**: Chief Information Security Officer **Classificatie**: Departementaal Vertrouwelijk --- ## Managementsamenvatting Dit rapport toont aan hoe de organisatie voldoet aan de NIS2-richtlijn (EU 2022/2555), met nadruk op artikel 21 voor de opgegeven periode. **Algemene nalevingsstatus**: **95% compliant** ✅ **Kerncijfers**: - Microsoft Secure Score: 87% (streefwaarde >85%) ✅ - Purview Compliance Score: 93% (streefwaarde >90%) ✅ - Gemiddelde incidentrespons: 23 minuten (streefwaarde <30 min) ✅ - BC/DR-testsucces: 100% (streefwaarde 100%) ✅ - Leveranciersreviews afgerond: 18/20 (streefwaarde 100%) ⚠️ --- ## Artikel 21 – Implementatiestatus ### Maatregel 1: Risicoanalyse en beleid **Status**: ✅ Conform **Bewijs**: - Volledige risicoanalyse uitgevoerd: 2024-12-15 - Risicoregister met 47 risico’s geactualiseerd - Beleid goedgekeurd door bestuur: 2024-11-20 **Microsoft-controls**: - Defender for Cloud voor kwetsbaarheidsmanagement - Purview Data Map voor classificatie - Secure Score voor prioritering **Documentatie**: Bijlagen A–C --- ### Maatregel 2: Incidentafhandeling **Status**: ✅ Conform **Bewijs**: - Responsplan getest in Q4 2024 - 24/72-uurs procedures operationeel - Teamtraining afgerond op 2024-10-15 **Metrics Q1 2025**: - Totaal incidenten: 12 (0 kritiek, 2 hoog, 5 middel, 5 laag) - Gemiddelde detectietijd: 8 minuten - Gemiddelde indamduur: 23 minuten - NIS2-meldingen: 0 **Microsoft-controls**: - Microsoft Sentinel, Defender XDR, Logic Apps **Documentatie**: Bijlagen D–F --- ### Maatregel 3: Bedrijfscontinuïteit & herstel **Status**: ✅ Conform **Bewijs**: - BC/DR-plan v4.0 (2024-09-01) - Gedefinieerde RTO/RPO per kritieke dienst - Jaarlijkse test 2024-11-08 geslaagd **Microsoft-controls**: - Azure Site Recovery - Microsoft 365 Backup - Geo-redundante opslag **Documentatie**: Bijlagen G–I --- ### Maatregel 4: Ketenbeveiliging **Status**: ⚠️ Gedeeltelijk conform (herstel loopt) **Bewijs**: - Register met 45 leveranciers - 18/20 Tier 1-beoordelingen afgerond - Restplanning: 2025-02-01 en 2025-02-15 **Microsoft-controls**: - Defender for Cloud Apps - Azure AD B2B - Conditional Access **Herstelplan**: - Resterende beoordelingen afronden vóór 2025-02-28 - Automatisch leveranciersrisico-dashboard inrichten --- ### Overzicht maatregelen 5–10 | Maatregel | Omschrijving | Status | Score | |-----------|--------------|--------|-------| | 5 | Beveiliging in ontwikkeling & lifecycle | ✅ | 96% | | 6 | Effectiviteitsmetingen | ✅ | 92% | | 7 | Cryptografie & sleutelbeheer | ✅ | 98% | | 8 | HR, toegang & assets | ✅ | 94% | | 9 | Meervoudige authenticatie | ✅ | 100% | | 10 | Beveiligde communicatie | ✅ | 91% | **Bewijs**: Bijlage M --- ## Continue verbetering **Q1 2025 gerealiseerd**: 1. Phishing-resistente MFA uitgerold voor adminaccounts 2. Sentinel-huntingqueries voor ketenaanvallen toegevoegd 3. Geautomatiseerde back-upvalidatie ingericht 4. Leveranciersassessments 90% voltooid (rest loopt) **Q2 2025 gepland**: 1. Purview eDiscovery Premium inzetten 2. Sentinel SOAR-playbooks uitbreiden 3. Redteamoefening voor incidentprocedures 4. Geautomatiseerde leveranciersscorekaarten --- ## Conclusie en certificering De organisatie toont overtuigend aan dat de NIS2-maatregelen structureel zijn ingericht en gemonitord. De resterende openstaande leverancierscontroles zijn ingepland. **Ondertekening**: _________________________ **Naam**: [CISO] **Datum**: [2025-01-15]

NIS2-compliance is een doorlopend programma van risico’s herkennen, maatregelen verankeren, ketenpartners toetsen en bewijslast opbouwen. Microsoft 365 en Azure leveren de technische capabilities, maar alleen een strak governanceproces zorgt ervoor dat artikel 21 en 23 aantoonbaar worden nageleefd. Koppel daarom elke maatregel aan concrete controles, voer periodieke gap-analyses uit en laat management actief besluiten over risico’s en investeringen. Zo voldoe je tegelijk aan NIS2 én de BIO, en laat je zien dat digitale dienstverlening voor burgers en bedrijven betrouwbaar blijft.

Bekijk meer artikelen over NIS2-implementatie en Microsoft 365 compliance
Bekijk artikelen →
NIS2 Naleving Microsoft 365 Beveiliging BIO Risicobeheer Incidentrespons