Welke Logging En Monitoring Vraagt NIS2?

Een organisatie ontdekt dat er iets mis is. De vragen die dan komen zijn altijd dezelfde: wanneer is dit begonnen, welke systemen zijn geraakt, welke gegevens zijn benaderd en is de aanvaller er nog? Zonder logging zijn die vragen niet te beantwoorden, en dan blijft er weinig anders over dan gissen.

Sinds 15 augustus 2026 geldt de Cyberbeveiligingswet, de Nederlandse omzetting van NIS2. NIS2 logging en monitoring zijn de basis onder twee van de drie verplichtingen: zonder registratie weet u niet dat er iets speelt (zorgplicht), en zonder registratie kunt u geen onderbouwde melding doen (meldplicht). Logs zijn niet alleen techniek, ze zijn bewijs.

Welke logging en monitoring vraagt NIS2?

De wet noemt geen lijst met verplichte logbronnen en geen bewaartermijn in dagen. Wat de wet wel vraagt, is incidentbehandeling als maatregel 2 van artikel 21, en het beoordelen van de effectiviteit van uw maatregelen als maatregel 6. Beide zijn zonder logging onmogelijk.

Denk daarbij aan drie doelen die logs vervullen. Detectie: opmerken dat er iets ongewoons gebeurt terwijl het gebeurt. Onderzoek: achteraf reconstrueren wat er is gebeurd en hoe ver het is gekomen. En verantwoording: aantonen richting toezichthouder en bestuur dat u in control bent.

Die drie doelen stellen verschillende eisen. Detectie vraagt om actuele signalen en alerting. Onderzoek vraagt om voldoende historie. Verantwoording vraagt om logs die niet achteraf zijn te wijzigen. Een logbeleid dat alleen op één van de drie is ingericht, laat u op het verkeerde moment in de steek.

Wat legt u vast in logs?

Begin bij de vraag welke gebeurtenissen u zou willen kunnen reconstrueren, en werk van daaruit terug naar de bronnen. Meer loggen is niet automatisch beter: overmatige logging kost opslag, maakt zoeken traag en verdrinkt de signalen die er wel toe doen.

De onderstaande tabel geeft de logbronnen die in vrijwel elke omgeving relevant zijn, met het doel dat ze dienen.

De laatste regel wordt vaak vergeten en is verrassend belangrijk. Een aanvaller die logging uitschakelt, hoopt daarmee onzichtbaar te worden. Als het stilvallen van een logstroom zelf een melding oplevert, wordt die actie juist een signaal.

Hoe lang bewaart u logs?

NIS2 noemt geen bewaartermijn. U bepaalt die zelf, en de onderbouwing is belangrijker dan het exacte aantal maanden. Twee overwegingen sturen die keuze.

De eerste is onderzoekstijd. Aanvallers zijn vaak weken tot maanden aanwezig voordat ze worden opgemerkt. Logs van twee weken oud helpen u dan niet. Een termijn van zes tot twaalf maanden voor beveiligingsrelevante logs is in de praktijk een werkbaar uitgangspunt, waarbij u recente logs snel doorzoekbaar houdt en oudere logs goedkoper archiveert.

De tweede is dataminimalisatie. Logs bevatten vrijwel altijd persoonsgegevens, zoals gebruikersnamen en IP-adressen. U mag ze niet onbeperkt bewaren. Stem uw termijn daarom af op de kaders die volgen uit de samenhang tussen NIS2 en de AVG, en leg de afweging tussen beide belangen vast in uw logbeleid.

Waarom is kloksynchronisatie zo belangrijk?

Zonder gelijke klokken is een tijdlijn niet te maken. Bij een incident legt u logs van een firewall, een server, een applicatie en een clouddienst naast elkaar. Loopt één van die klokken enkele minuten uit, dan lijkt de volgorde van gebeurtenissen anders dan ze was, en trekt u de verkeerde conclusie over oorzaak en gevolg.

De oplossing is eenvoudig en goedkoop. Laat alle systemen hun tijd betrekken van dezelfde betrouwbare tijdbron, gebruik een eenduidige tijdzone in logs (bij voorkeur UTC met vermelding van de zone), en controleer periodiek of alle systemen daadwerkelijk synchroon lopen.

Hoe richt u alerting in zonder te verdrinken in meldingen?

Monitoring zonder alerting is een archief, geen detectie. Maar alerting op alles leidt binnen enkele weken tot meldingsmoeheid, waarna niemand meer kijkt. Begin daarom klein, met signalen die zelden voorkomen en bijna altijd iets betekenen.

• Beheerrechten toegekend. Een nieuw account met beheerrechten buiten het normale proces om is bijna altijd het onderzoeken waard.
• Veel mislukte inlogpogingen. Een reeks mislukte pogingen gevolgd door een geslaagde poging is een klassiek patroon.
• Inloggen op ongebruikelijke tijden of vanaf ongebruikelijke locaties. Zeker bij beheeraccounts.
• Malwaredetectie op een server. Op een werkplek komt dat voor, op een server zelden.
• Back-uptaak mislukt of back-up verwijderd. Dit raakt direct uw herstelvermogen.
• Logging valt stil. Een bron die plots geen gegevens meer levert, verdient onmiddellijk aandacht.
• Verkeer tussen zones dat niet hoort. Dit is het signaal dat de scheidingen uit uw netwerksegmentatie daadwerkelijk opleveren.

Leg per alert vast wie hem ontvangt, binnen welke tijd erop wordt gereageerd en wat de vervolgstap is. Een melding zonder eigenaar is geen maatregel.

Wat is de link met de meldplicht?

Hier komt alles samen. Bij een significant incident moet u binnen 24 uur een vroege waarschuwing doen, binnen 72 uur een volledige incidentmelding en binnen een maand een eindrapport indienen bij het CSIRT en de bevoegde toezichthouder. Die termijnen zijn kort.

De 72-uursmelding vraagt om inhoud: wat is er gebeurd, wat is de vermoedelijke oorzaak, welke gevolgen heeft het en welke maatregelen heeft u genomen. Zonder logs kunt u die vragen niet onderbouwd beantwoorden, en wordt uw melding een verzameling aannames. Logs leveren de tijdlijn waarop uw melding rust.

Ook de eerste beoordeling hangt van logging af. De vraag of u te maken heeft met een significant incident beantwoordt u op basis van omvang en impact, en die stelt u vast uit uw registraties. Neem het ophalen van de relevante logs daarom op als expliciete stap in uw incident response plan, en oefen dat samen met de meldtermijnen van 24 en 72 uur.

Hoe beschermt u logs tegen manipulatie?

Logs die een aanvaller kan wissen, zijn geen bewijs. Een aanvaller met beheerrechten op een server kan de logs op die server aanpassen. Daarom hoort een kopie van beveiligingsrelevante logs zo snel mogelijk naar een aparte, afgeschermde plek te gaan.

Drie maatregelen doen het meeste werk. Stuur logs door naar een centrale voorziening in een andere zone. Beperk het aantal mensen dat logs kan wijzigen of verwijderen tot een minimum, en log ook die handelingen. En zorg dat de centrale logopslag niet met dezelfde beheeraccounts te benaderen is als de systemen die de logs leveren.

Veelgestelde vragen over NIS2 logging en monitoring

1. Hoe lang moet ik logs bewaren voor NIS2?

NIS2 noemt geen concrete bewaartermijn. U bepaalt die zelf op basis van uw risicoanalyse en de tijd die u nodig heeft om een incident te kunnen onderzoeken. Zes tot twaalf maanden voor beveiligingsrelevante logs is een werkbaar uitgangspunt. Houd daarbij rekening met dataminimalisatie, want logs bevatten vrijwel altijd persoonsgegevens.

2. Heb ik een SIEM nodig om aan NIS2 te voldoen?

Nee, de wet schrijft geen product voor. Voor kleinere organisaties kan centrale logverzameling met een beperkt aantal alertregels voldoende zijn. Belangrijker dan het gereedschap is dat logs centraal en beschermd worden bewaard, dat er daadwerkelijk iemand naar signalen kijkt en dat de opvolging is vastgelegd.

3. Moet ik alles loggen?

Nee, en dat is ook onverstandig. Overmatige logging kost opslag, maakt onderzoek traag en levert ruis op waardoor echte signalen verdwijnen. Log gericht: aanmeldingen, beheerhandelingen, remote toegang, beveiligingsdetecties, back-uptaken en verkeer tussen netwerkzones dekken het grootste deel van de behoefte af.

4. Mag ik het gedrag van medewerkers monitoren onder NIS2?

Beveiligingslogging is toegestaan, maar u blijft gebonden aan privacywetgeving en aan afspraken met de ondernemingsraad. Log met een beveiligingsdoel, niet om prestaties te beoordelen. Leg het doel, de bewaartermijn en de toegang tot logs vast in beleid, en informeer medewerkers erover.

5. Wat als ik na een incident geen logs blijk te hebben?

Dan meldt u wat u wel weet, binnen de termijn, en geeft u aan wat u niet heeft kunnen vaststellen. Een melding uitstellen omdat het beeld nog onvolledig is, is geen optie. Het ontbreken van logging is bovendien op zichzelf een tekortkoming in de zorgplicht die de toezichthouder kan meewegen.

Conclusie

Logging is de minst zichtbare maatregel uit uw NIS2-traject en tegelijk de maatregel waar u op het moeilijkste moment het meest aan heeft. Zonder registratie merkt u een incident laat op, kunt u de omvang niet vaststellen en staat u met lege handen op het moment dat de meldtermijn loopt. Met registratie heeft u een tijdlijn, en daarmee zowel een besluit als een onderbouwing.

Begin bij de bronnen uit de tabel, regel kloksynchronisatie, kies een bewaartermijn en leg die vast, en start met een handvol alerts die er echt toe doen. Wilt u het onderliggende logbeleid en de bijbehorende procedures niet zelf schrijven, dan bevat het NIS2 compliance pakket deze documenten uitgewerkt en aangesloten op de tien maatregelgebieden. De 176 NIS2 document templates leveren de bijbehorende formulieren, en met de digitale Coach werkt u stap voor stap naar een aantoonbaar ingerichte zorgplicht.