Wat NIS2 concreet betekent voor uw Azure-omgeving

U weet dat uw organisatie NIS2-plichtig is. U heeft een beleidsdocument laten opstellen, misschien een risicoanalyse laten uitvoeren, en uw bestuur geïnformeerd. En nu zit u met een vraag die tot nu toe vaak onduidelijk blijft:

Wat moet er concreet veranderen in onze Azure-omgeving?

De Engelstalige Azure-documentatie die u krijgt doorgestuurd helpt daar meestal niet echt bij. Die legt uit hoe Azure werkt, niet wat NIS2 concreet vraagt. En veel NIS2-consultants beschrijven vooral de wet, niet de technische configuratie.

Dit artikel probeert dat wel te doen — in gewoon Nederlands.

Scope

Voordat we naar de techniek gaan: de vraag of uw organisatie onder NIS2 valt is minder eenvoudig dan het lijkt.

De Nederlandse implementatiewet — de Cyberbeveiligingswet — trad op 17 oktober 2024 in werking en maakt onderscheid tussen twee categorieën.

Essentiële entiteiten

Sectoren met een hoog risico, zoals energie, transport, bankwezen, financiële marktinfrastructuur, gezondheidszorg, drinkwater, digitale infrastructuur, overheid en ruimtevaart. Voor deze organisaties geldt proactief toezicht, inclusief mogelijke onaangekondigde audits.

Belangrijke entiteiten

Een bredere groep, waaronder post- en koeriersdiensten, afvalbeheer, chemie, voedingsindustrie, maakindustrie en digitale dienstverleners. Hier is het toezicht vooral reactief.

In veel gevallen geldt de richtlijn voor organisaties met meer dan 50 medewerkers en een jaaromzet of balanstotaal boven de 10 miljoen euro. Maar ook kleinere organisaties in kritieke sectoren kunnen onder NIS2 vallen.

Als u niet zeker weet of u onder NIS2 valt, is dat op zichzelf al iets om uit te zoeken. Het NCSC heeft hiervoor een zelfevaluatietool.

Artikel 21

Artikel 21(2) van de NIS2-richtlijn beschrijft tien categorieën beveiligingsmaatregelen. De tekst is technologieneutraal — Azure wordt nergens genoemd — maar de norm is duidelijk: maatregelen moeten passend en evenredig zijn en aansluiten bij de stand van de techniek.

In de praktijk betekent dat bijvoorbeeld het volgende.

Configuraties die een paar jaar geleden acceptabel waren, voldoen mogelijk niet meer. Denk aan permanente Global Administrator-rollen zonder PIM, een SIEM zonder actieve detectieregels, of back-ups die nooit zijn getest.

Dit zijn geen uitzonderingen — in veel Nederlandse Azure-omgevingen kom je dit nog gewoon tegen.

De tien domeinen zijn:

1. Risicoanalyse en beveiliging van informatiesystemen
2. Incidentafhandeling
3. Bedrijfscontinuïteit, back-upbeheer en herstel
4. Beveiliging van de toeleveringsketen
5. Beveiliging bij ontwikkeling en onderhoud
6. Evaluatie van maatregelen
7. Basishygiëne en training
8. Cryptografie
9. Toegangsbeheer en assetbeheer
10. Multi-factor authenticatie en beveiligde communicatie

Voor organisaties die hun beveiliging serieus nemen zijn deze onderwerpen niet nieuw. Wat NIS2 verandert, is de verplichting om aantoonbaar te maken dat ze ook echt zijn geïmplementeerd en onderhouden.

Azure-configuratie

Risicoanalyse en beveiliging

Microsoft Defender for Cloud speelt hier een centrale rol.

Het Secure Score-dashboard laat zien hoe uw beveiliging er op dit moment voor staat, gebaseerd op de werkelijke configuratie van uw Azure-omgeving.

Wat u minimaal moet doen:

• Een NIS2- of ISO-27001-initiatief koppelen aan het Defender for Cloud compliance-dashboard
• Dit toewijzen op Management Group-niveau, zodat nieuwe abonnementen automatisch worden meegenomen.
• Het Regulatory Compliance Report uit Defender for Cloud levert hiervoor direct bruikbaar bewijs.

Incidentdetectie

Microsoft Sentinel dekt dit domein technisch, maar alleen installeren is niet voldoende.

Een Sentinel-workspace met alleen standaardconnectors levert nog geen echte detectie op. Artikel 21 vereist dat u aantoonbaar detecteert én reageert.

Dat betekent:

• actieve analyseregels
• automatische respons-playbooks
• logretentie van minimaal twaalf maanden.

Als u Sentinel heeft ingericht maar nog nooit een eigen analyseregel heeft gemaakt, is dat een duidelijk aandachtspunt.

Back-up en herstel

Azure Backup en Azure Site Recovery bieden de technische basis.

Maar back-ups die nooit zijn getest voldoen niet aan de eis van aantoonbaar herstel.

RTO en RPO moeten per werkbelasting worden vastgesteld en getest.

Bij een logistiek bedrijf waar ik bij een beoordeling betrokken was, bleek dat back-ups van drie kritieke applicaties al maanden niet meer liepen door een configuratiefout. Het beleid sprak over een hersteltijd van vier uur. In werkelijkheid was er geen herstel mogelijk.

Toegangsbeheer

In de praktijk gaat het hier vaak mis.

Privileged Identity Management (PIM) is de standaard voor beheer van geprivilegieerde toegang. In veel omgevingen zijn de benodigde licenties aanwezig, maar is PIM nooit daadwerkelijk geconfigureerd.

Permanente Global Administrator-rollen zonder PIM zijn in een audit vrijwel altijd een directe bevinding.

Daarnaast horen hier ook bij:

• Just-in-Time VM-toegang
• Periodieke toegangsreviews via Entra ID Governance

Versleuteling

Azure Key Vault met klantbeheerde sleutels voor gevoelige data. TLS 1.2 of hoger voor alle endpoints. Purge protection op Key Vaults.

Voor organisaties die met gevoelige data werken is dit geen ambitie, maar de ondergrens.

MFA

Multi-factor authenticatie via Conditional Access is inmiddels standaard. Voor geprivilegieerde rollen verwacht NIS2 echter phishing-resistente authenticatie, zoals:

• FIDO2-sleutels
• Certificaatgebaseerde authenticatie.

SMS of een standaard authenticator-app is hiervoor niet voldoende.

Wat een toezichthouder wil zien

NIS2-toezicht vraagt om bewijs van implementatie.

Dat betekent:

• configuratie-exports
• auditlogs
• incidentlogs
• hersteltestrapporten.

Een goed ingerichte Azure-omgeving kan dit bewijs grotendeels zelf produceren:

• Defender for Cloud compliance-rapport
• Sentinel-incidentlogs
• hersteltestrapporten
• PIM-auditlogs
• Key Vault-auditlogs
• Azure Policy-compliance via Resource Graph

Als u dit handmatig voor alle domeinen bij elkaar wilt zoeken, bent u daar al snel dagen mee bezig.

Concrete vragen voor uw platformteam

Stel deze vier vragen:

• Is PIM geactiveerd voor alle geprivilegieerde rollen?
• Heeft Sentinel actieve detectieregels voor relevante dreigingsscenario’s?
• Zijn back-ups in de afgelopen twaalf maanden getest?
• Is Defender for Cloud gekoppeld aan een NIS2- of ISO-compliance-initiatief op Management Group-niveau?

Als het antwoord op één van deze vragen “nee” of “weet ik niet” is, heeft u een duidelijke prioriteit.

Afsluiting

Organisaties die NIS2-toezicht goed doorstaan, behandelen hun Azure-configuratie als het compliance-dossier.

Niet als losse technische instellingen, maar als aantoonbaar bewijs van hoe beveiliging daadwerkelijk is ingericht.

Beleidsdocumenten beschrijven intenties. Configuratie en logs laten zien wat er echt gebeurt.

En alleen dat laatste kan een toezichthouder controleren.