NIS2-meldplicht voor Azure-omgevingen: wat u binnen 24 en 72 uur moet rapporteren

De NIS2-meldplicht voor Azure-omgevingen verplicht u om een significant incident in drie stappen te melden: een vroege waarschuwing binnen 24 uur, een volledige melding binnen 72 uur en een eindrapport binnen één maand. Dat staat in Artikel 23 van de richtlijn, in Nederland omgezet via de Cyberbeveiligingswet. De klok begint te lopen op het moment dat u zich bewust wordt van het incident — niet wanneer het onderzoek is afgerond. De capaciteit om die termijnen te halen bouwt u in Microsoft Sentinel en Microsoft Defender XDR, en de meeste teams ontdekken de gaten pas wanneer de klok werkelijk loopt.

Iemand stuurt u om 02:14 een Sentinel-incident door. Volgens de regels heeft u dan tot ongeveer 02:14 de volgende dag om de autoriteit iets te melden. De vraag is of uw omgeving tegen die tijd een verdedigbare tijdlijn kan produceren, of dat u die uren besteedt aan reconstrueren in plaats van rapporteren.

Belangrijkste punten

• NIS2 Artikel 23 kent drie termijnen: een vroege waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en een eindrapport binnen één maand na de melding.
• De klok van 24 uur start bij bewustwording van een significant incident — het moment waarop een Microsoft Sentinel-detectieregel of een Microsoft Defender XDR-waarschuwing een mens met beoordelingsbevoegdheid bereikt.
• In Nederland meldt u bij het CSIRT en de bevoegde sectorautoriteit onder de Cyberbeveiligingswet; de nationale CSIRT-functie ligt bij het Nationaal Cyber Security Centrum (NCSC).
• Een incident is “significant” bij ernstige operationele verstoring, financiële schade of aanzienlijke schade aan anderen — niet alleen wanneer een aanvaller technisch slaagde.
• Het bewaarde bewijs — een Microsoft Sentinel-incidentexport, de detectielogica en een onveranderbare tijdlijn — is precies wat een auditor en een toezichthouder opvragen.

Wat schrijft NIS2 Artikel 23 precies voor, en wanneer start de klok?

NIS2 Artikel 23 schrijft een melding in drie fasen voor, en de eerste fase is verschuldigd binnen 24 uur na bewustwording van een significant incident. De vroege waarschuwing is bewust beknopt: u meldt dat een incident heeft plaatsgevonden, of u vermoedt dat het onrechtmatig of kwaadwillig was, en of het grensoverschrijdende gevolgen kan hebben. U hoeft de oorzaak nog niet te kennen. U moet het hebben opgemerkt.

De melding binnen 72 uur is de inhoudelijke. Die actualiseert de vroege waarschuwing met een eerste beoordeling van het incident, inclusief ernst, impact en — voor zover beschikbaar — indicatoren van compromittering. Het eindrapport, verschuldigd binnen één maand na die melding, bevat een gedetailleerde beschrijving, het soort dreiging of de grondoorzaak, de getroffen maatregelen en eventuele grensoverschrijdende gevolgen.

De bepalende uitdrukking is “bewustwording”. Voor een team dat met Microsoft Sentinel werkt, is bewustwording de tijdstempel waarop een incident overgaat van machinaal gegenereerd naar menselijk bevestigd — wanneer een analist het incident opent, of wanneer een automatiseringsregel het escaleert naar iemand die kan beoordelen of het significant is. Die tijdstempel is het belangrijkste veld in uw hele meldingsdossier, omdat elke termijn daarvandaan telt. Kan uw tooling niet precies aangeven wanneer bewustwording optrad, dan kunt u de 24-uurstermijn niet aantonen.

Wanneer is een incident “significant” onder NIS2?

Een incident is significant onder NIS2 wanneer het een ernstige operationele verstoring of financiële schade voor uw entiteit veroorzaakt of kan veroorzaken, of aanzienlijke materiële of immateriële schade aan andere personen. De uitvoeringsregeling voor bepaalde sectoren voegt concrete drempels toe — bijvoorbeeld: een incident is significant bij downtime boven een bepaalde duur, bij een bepaald aantal getroffen gebruikers, of bij een terugkerend patroon van lichtere gebeurtenissen.

De valkuil is “significant” gelijkstellen aan “datalek”. Het is breder. Een ransomware-detonatie die u indamde is significant als die de dienstverlening verstoorde. Een misconfiguratie die een klantgerichte workload urenlang offline haalde is significant, ook zonder aanvaller. Een herhaalde, automatisch gemitigeerde gebeurtenis kan door opeenstapeling significant worden.

Voor een Azure-omgeving is de praktische zet om deze drempels in Microsoft Sentinel vast te leggen in plaats van ze om 02:14 aan interpretatie over te laten. U definieert wat “ernstige operationele verstoring” voor uw diensten betekent — een SLA-overschrijdingsvenster, een aantal getroffen Microsoft Entra ID-accounts, een Microsoft Azure-resourcegroep die uitvalt — en laat de regellogica kandidaten markeren. Een mens neemt de beslissing over significantie; de tooling zorgt dat de kandidaat die mens op tijd bereikt.

Hoe detecteert en rapporteert u dit met Microsoft Sentinel en Defender XDR?

U bouwt de meldcapaciteit in Microsoft Sentinel door detectieregels die signaleren, automatiseringsregels die orkestreren en Logic App-playbooks die handelen te combineren — met Microsoft Defender XDR die gecorreleerde waarschuwingen aanlevert. Het doel is de afstand verkleinen tussen het optreden van een gebeurtenis en het moment dat een mens met meldbevoegdheid ervan weet.

De onderdelen, in de volgorde waarin ze afgaan:

• Microsoft Defender XDR correleert signalen over endpoint (Microsoft Defender for Endpoint), identiteit (Microsoft Defender for Identity), e-mail (Microsoft Defender for Office 365) en cloud-apps tot één incident, en stuurt dat via de Microsoft Defender XDR-connector naar Microsoft Sentinel.
• Microsoft Sentinel-detectieregels — gepland of near-real-time (NRT) — signaleren de condities die u als significant hebt gedefinieerd. Een NRT-regel draait ongeveer elke minuut, wat telt als uw budget 24 uur is en u de eerste uren niet aan querylatentie wilt verliezen.
• Microsoft Sentinel-automatiseringsregels treden in werking bij het aanmaken van een incident. Ze stellen de ernst in, wijzen een eigenaar toe, voorzien het incident van een NIS2-kandidaat-label en starten de klok door het tijdstip van bewustwording vast te leggen.
• Logic App-playbooks voeren de meldmechaniek uit: bericht in het SecOps-kanaal, ticket aanmaken, en de inhoud van de vroege waarschuwing opstellen uit de entiteiten van het incident. Een playbook kan de velden vooraf invullen die het portaal van de autoriteit verwacht, zodat de mens bewerkt in plaats van schrijft tegen de deadline.

Het nuttigste artefact dat deze pijplijn oplevert is een verdedigbare tijdlijn. Microsoft Sentinel registreert de incidentactiviteit — wanneer het is aangemaakt, bevestigd, geëscaleerd en gesloten — en die registratie kunt u exporteren. Die export verandert “we denken dat we het rond 02:00 opmerkten” in “bewustwording vastgelegd om 02:14:07; vroege waarschuwing om 09:30 ingediend; binnen het venster van 24 uur”. Combineer dit met de driftdetectie uit Azure-configuratiedrift, zodat een misconfiguratie die een incident wordt al eerder wordt opgemerkt.

Een eerlijke kanttekening: tooling detecteert en registreert tijden. Het beslist niet over significantie en schrijft niet het regelgevende narratief. Een mens bezit beide. Wat de pijplijn garandeert, is dat die mens de tijd en het bewijs heeft om het werk goed te doen.

Waar meldt u in Nederland, en onder welke wet?

In Nederland meldt u een significant incident bij het CSIRT dat voor uw sector is aangewezen en bij uw sectortoezichthouder, onder de Cyberbeveiligingswet — de Nederlandse wet die NIS2 omzet. De nationale CSIRT-functie en een groot deel van de operationele coördinatie liggen bij het Nationaal Cyber Security Centrum (NCSC). Welke toezichthouder de melding ontvangt, hangt af van uw sector; essentiële en belangrijke entiteiten worden in de wet aan hun bevoegde autoriteit gekoppeld.

De mechaniek telt, want de klok van 24 uur pauzeert niet terwijl u uitzoekt wie u moet mailen. Leg de meldbestemming, het portaal of contactkanaal en de verantwoordelijke interne eigenaar vóór een incident vast — niet tijdens. Zet de bestemming in het playbook. Zet de eigenaar in de wachtdienst.

Melden is bovendien een doorlopende verplichting, geen eenmalige indiening. De vroege waarschuwing, de melding binnen 72 uur en het eindrapport binnen één maand zijn actualiseringen van hetzelfde incident, dus uw bewijsdossier moet alle drie ondersteunen vanuit één doorlopende bron — precies de reden waarom een exporteerbaar Microsoft Sentinel-incident de juiste ruggengraat is.

Welk bewijs bewaart u, en in welke vorm?

U bewaart een doorlopende, manipulatiebestendige registratie van het incident: de detectielogica die afging, het tijdstip van bewustwording, de volledige tijdlijn, de betrokken entiteiten en de genomen acties. In termen van Microsoft Sentinel zijn dat de definitie van de detectieregel, het audit- en activiteitenlogboek van het incident, en een incidentexport. De vorm telt evenzeer als de inhoud — zowel een toezichthouder als een auditor wil zien dat het dossier niet achteraf is samengesteld.

Concrete bewaarkeuzes voor een Azure-omgeving:

Bewijsstuk	Bron	Waarom het telt
Tijdstip van bewustwording	Microsoft Sentinel-incidentactiviteitenlogboek	Toont dat de 24-uurstermijn is gehaald
Detectielogica	Microsoft Sentinel-detectieregel (KQL)	Toont dat het incident door ontwerp is gevangen, niet bij toeval
Incidenttijdlijn	Microsoft Sentinel-incidentexport / auditlogboek	Reconstrueert de volgorde voor het eindrapport
Betrokken entiteiten	Microsoft Defender XDR-incidentgraaf	Bepaalt de reikwijdte voor het significantieoordeel
Meldregistratie	Uitvoeringsgeschiedenis van het Logic App-playbook	Toont wat is gemeld en wanneer

Stuur de relevante logboeken naar een Log Analytics-werkruimte met een bewaartermijn die aan de eis van uw sector voldoet, en overweeg onveranderbare opslag voor de incidentexport, zodat het dossier na indiening niet kan worden gewijzigd. De Azure-architectuur governance-checklist behandelt de bredere loggingpositie waarop dit steunt.

Hier houdt het schoon produceren van bewijs op een tooling-oefening te zijn en wordt het een assessment-oefening. Platform Architecture Authority (PAA) leest uw Microsoft Azure- en Microsoft 365-configuratie en zet de gaten af tegen de NIS2-verplichtingen — waaronder de vraag of uw detectiedekking, logbewaring en exportpad werkelijk een binnen 24 uur verdedigbaar dossier kunnen opleveren — en genereert vervolgens de herstelcode die u toepast. Het vervangt niet de analist die significantie beoordeelt of het narratief schrijft; het zorgt dat het bewijs al bestaat voordat de klok start. PAA is alleen-lezen.

Veelgestelde vragen

Start de klok van 24 uur bij de aanval of bij het opmerken? De klok start bij bewustwording van een significant incident — niet wanneer het incident technisch begon. Voor een Microsoft Sentinel-pijplijn is bewustwording de tijdstempel waarop een mens met meldbevoegdheid het incident bevestigt. Die tijdstempel precies vastleggen is wat u in staat stelt aan te tonen dat de vroege waarschuwing op tijd is ingediend.

Is een vroege waarschuwing hetzelfde als het volledige rapport? Nee. De vroege waarschuwing binnen 24 uur is een korte melding dat een significant incident plaatsvond en of het kwaadwillig of grensoverschrijdend lijkt. De melding binnen 72 uur voegt een eerste beoordeling van ernst en impact toe. Het eindrapport binnen één maand bevat grondoorzaak, maatregelen en volledige impact. Het zijn drie fasen van één verplichting.

Melden we elke Microsoft Defender XDR-waarschuwing bij de autoriteit? Nee. U meldt significante incidenten, beoordeeld op operationele verstoring, financiële schade of schade aan anderen. De meeste Microsoft Defender XDR-waarschuwingen halen die drempel nooit. De pijplijn bestaat om kandidaten snel bij een mens te krijgen; de mens beslist over significantie. Zowel over- als ondermelden is een falen van dat oordeel, niet van de tooling.

Wie is in Nederland de bevoegde autoriteit? U meldt bij het CSIRT voor uw sector en bij uw sectortoezichthouder onder de Cyberbeveiligingswet. Het Nationaal Cyber Security Centrum vervult de nationale CSIRT-functie. Welke toezichthouder precies, hangt af van of u als essentiële of belangrijke entiteit bent ingedeeld en in welke sector, dus bevestig uw koppeling vóór een incident optreedt.

Hoe lang bewaren we het incidentbewijs? Minstens zo lang als de toezichts- en auditvereisten van uw sector verlangen, en behandel de incidentexport als een dossier dat ook lang na sluiting kan worden opgevraagd. Stel de bewaartermijn in Log Analytics bewust in en bewaar de definitieve export in onveranderbare vorm, zodat de integriteit buiten twijfel staat als een toezichthouder er maanden later om vraagt.

De termijnen in Artikel 23 zijn niet onderhandelbaar en wachten niet tot uw tooling bijtrekt. Bouw de detectie, de tijdstempel en de export vóórdat de klok loopt, want de nacht waarin die start is de verkeerde nacht om te ontdekken wat ontbreekt.