ISO 27001-logbewijs voor NIS2, DORA en GDPR

De alert kwam op dinsdag om 02:17 binnen in het SOC-kanaal: meerdere mislukte aanmeldpogingen voor de geprivilegieerde gebruiker admin vanaf een nieuw IP-adres. De pogingen stopten na enkele minuten. Een junior analist registreerde de alert, ging ervan uit dat het om een fout geconfigureerd script of een systeembeheerder ging die laat doorwerkte, en ging verder.

Twee dagen later zat Maria, de CISO van een snelgroeiend fintechbedrijf, in een managementoverleg toen haar telefoon trilde. Engineering had ongebruikelijk hoog CPU-gebruik vastgesteld op een productiedatabase-instantie. Er was een nieuw ongeautoriseerd gebruikersaccount aangemaakt. De alert van 02:17 was geen fout-positieve melding. Het was het eerste zichtbare signaal van een inbraakpoging.

Het incident werd ingedamd, maar het onderzoek bracht een groter probleem aan het licht. Firewalllogboeken stonden in één systeem. Kubernetes-logboeken stonden in een ander systeem. Database-auditlogs werden afzonderlijk opgeslagen. Meerdere tijdstempels liepen minuten uiteen. Het team had gegevens, maar kon niet snel een verdedigbaar beeld geven van detectie, beoordeling, escalatie, indamming en inbreukbeoordeling.

Maria’s ISO/IEC 27001:2022-controleaudit was succesvol afgerond, maar de auditor liet één waarschuwing achter: de organisatie had beheersmaatregelen voor logging en monitoring, maar zou moeite hebben om tijdig gecorreleerd bewijs te leveren voor meldingsbesluiten onder NIS2, DORA en GDPR.

Dat is de realiteit waarmee veel organisaties in 2026 te maken hebben. Ze hebben geen loggingprobleem. Ze hebben een bewijsprobleem.

Een SIEM, EDR-platform, cloud audittrail of firewalllogboek is op zichzelf geen auditgereed bewijs. Bewijs wordt pas verdedigbaar wanneer het door beleid wordt beheerst, tegen manipulatie wordt beschermd, volgens een vast ritme wordt beoordeeld, aan incidentbesluiten wordt gekoppeld en lang genoeg wordt bewaard om gebeurtenissen te reconstrueren.

Voor ISO/IEC 27001:2022, NIS2, DORA en GDPR is de kernvraag niet langer: “Verzamelen we logboeken?” De vraag is: “Kunnen we aantonen wat er is gebeurd, wie het heeft beoordeeld, hoe het is geclassificeerd, of melding vereist was en of het management toezicht had?”

Waarom logging en monitoring een compliancevraagstuk rond bewijs zijn geworden

NIS2, DORA en GDPR hebben de zakelijke betekenis van beveiligingslogboeken veranderd.

Onder NIS2 moeten essentiële en belangrijke entiteiten passende en evenredige maatregelen voor cyberbeveiligingsrisicobeheer implementeren. Article 21 omvat incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, effectiviteitsbeoordeling, cyberhygiëne, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen, MFA en beveiligde communicatie. Article 23 introduceert een gefaseerd meldmodel, met onder meer een vroegtijdige waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur, tussentijdse updates waar relevant en een eindrapport uiterlijk één maand na de incidentmelding.

Dat model is afhankelijk van logging en monitoring. U kunt geen geloofwaardige vroegtijdige waarschuwing verzenden als u niet kunt aantonen wanneer de gebeurtenis is gedetecteerd. U kunt een significant incident niet classificeren als u de getroffen systemen, gebruikersactiviteit, impact op de dienstverlening en indammingsacties niet kunt reconstrueren.

DORA legt vergelijkbare druk op financiële entiteiten. Articles 5 tot en met 14 stellen verwachtingen vast voor governance en ICT-risicobeheer, waaronder verantwoordelijkheid van het leidinggevend orgaan, identificatie van ICT-activa, bescherming en preventie, detectie, respons en herstel, back-up, herstel, leren en communicatie. Articles 17 tot en met 23 vereisen een beheerproces voor ICT-gerelateerde incidenten dat detectie, registratie, classificatie, escalatie, melding en opvolging omvat. Articles 24 tot en met 27 behandelen testen van digitale operationele weerbaarheid. Articles 28 tot en met 31 creëren verplichtingen voor ICT-risicobeheer van derde partijen.

GDPR voegt de verantwoordingslaag rond privacy toe. Article 32 vereist passende beveiliging van de verwerking. Article 33 vereist melding van een inbreuk in verband met persoonsgegevens aan de toezichthoudende autoriteit zonder onredelijke vertraging en, waar haalbaar, uiterlijk 72 uur nadat men er kennis van heeft genomen, tenzij het onwaarschijnlijk is dat de inbreuk een risico voor betrokkenen oplevert. Article 34 kan communicatie aan getroffen betrokkenen vereisen wanneer het risico hoog is. Logboeken helpen bepalen of persoonsgegevens zijn ingezien, gewijzigd, geëxfiltreerd of blootgesteld, maar logboeken kunnen zelf ook persoonsgegevens bevatten en moeten daarom overeenkomstig worden beheerst.

ISO/IEC 27001:2022 biedt de ruggengraat van het managementsysteem. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie haar context, belanghebbenden, vereisten en ISMS-scope begrijpt. Clausules 5.1 tot en met 5.3 vereisen leiderschap, beleidsafstemming, rollen, verantwoordelijkheden en bevoegdheden. Clausules 6.1.1 tot en met 6.1.3 vereisen een herhaalbaar proces voor risicobeoordeling en risicobehandeling, waaronder risicocriteria, risico-eigenaren, behandelopties, vergelijking met beheersmaatregelen uit Bijlage A, de Verklaring van Toepasselijkheid en acceptatie van restrisico’s. Clausule 6.2 vereist meetbare informatiebeveiligingsdoelstellingen.

Daarom kan bewijs voor logging en monitoring niet alleen binnen het SOC blijven. Het hoort thuis in het ISMS, het risicoregister, de Verklaring van Toepasselijkheid, het incidentresponsproces, de workflow voor privacy-inbreuken, leveranciersgovernance en managementrapportage.

De ISO 27001-loggingsmaatregelen die auditors als eerste koppelen

In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandelt de fase Controls in Action, Step 19: Technological Controls I, logging, monitoring en kloksynchronisatie als één bewijsketen.

A.8.15 – Logging: “Logboeken die activiteiten, uitzonderingen, fouten en andere relevante gebeurtenissen vastleggen
moeten worden geproduceerd, opgeslagen, beschermd en geanalyseerd.”

A.8.16 – Monitoringactiviteiten: “Netwerken, systemen en toepassingen moeten worden gemonitord op
afwijkend gedrag en passende maatregelen moeten worden genomen om potentiële informatiebeveiligingsincidenten
te beoordelen.”

A.8.17 – Kloksynchronisatie: “De klokken van informatieverwerkende systemen die door de
organisatie worden gebruikt, moeten worden gesynchroniseerd met goedgekeurde tijdsbronnen.”

Deze beheersmaatregelen beantwoorden drie auditvragen:

Zenith Controls: The Cross-Compliance Guide Zenith Controls maakt de relatie expliciet:

“Logging vormt de onderliggende gegevenslaag voor monitoring. Beheersmaatregel 8.16 is afhankelijk van de logboeken die onder 8.15 worden gegenereerd om beveiligingsgebeurtenissen te analyseren, afwijkingen te detecteren en potentiële inbreuken te identificeren. Zonder volledige logging zijn monitoringsystemen niet doeltreffend.”

Zenith Controls classificeert ISO/IEC 27002:2022 control 8.15, Logging, als een detectieve beheersmaatregel ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid. De maatregel wordt gemapt op het cyberbeveiligingsconcept Detect en op beheer van informatiebeveiligingsgebeurtenissen. Logging wordt ook verbonden met Monitoringactiviteiten, Beoordeling en besluitvorming over informatiebeveiligingsgebeurtenissen en Kloksynchronisatie.

Voor control 8.16, Monitoringactiviteiten, classificeert Zenith Controls deze als detectief en correctief, gemapt op Detect en Respond. De maatregel verbindt monitoring met monitoring van leveranciersdiensten en gebeurtenisbeoordeling, wat essentieel is voor cloud-, SaaS-, managed service- en uitbestedingsomgevingen.

De praktische boodschap is eenvoudig. Logboeken leveren de feiten. Monitoring identificeert afwijkingen. Kloksynchronisatie maakt de feiten betrouwbaar over systemen heen. Gebeurtenisbeoordeling zet alerts om in besluiten.

Hoe auditgereed logbewijs er daadwerkelijk uitziet

Auditgereed bewijs is geen map met screenshots. Het is een samenhangend spoor dat het ontwerp van beheersmaatregelen, de werking ervan en de besluitvorming aantoont.

Een volwassen bewijsdossier voor logging en monitoring bevat meestal het volgende:

Clarysec’s enterprise Beleid voor logging en monitoring Beleid voor logging en monitoring formuleert dit rechtstreeks:

“Dit beleid is essentieel ter ondersteuning van ISO/IEC 27001 clausule 8.1 en beheersmaatregelen uit Bijlage A 8.15 (Logging), 8.16 (Monitoringactiviteiten) en 8.17 (Kloksynchronisatie), en is rechtstreeks gemapt op wettelijke verplichtingen onder GDPR, NIS2, DORA en COBIT 2019.”

Uit sectie “Doel”, beleidsclausule 1.3.

Hetzelfde beleid stelt de operationele verwachting vast:

“Richt centrale logging- en alarmeringssystemen in (bijv. SIEM) om verdachte activiteit vrijwel realtime te aggregeren, te correleren en te escaleren.”

Uit sectie “Doelstellingen”, beleidsclausule 3.4.

Voor kleinere organisaties vertaalt Clarysec’s mkb-Beleid voor logging en monitoring Beleid voor logging en monitoring - mkb hetzelfde principe naar proportionele vereisten:

“De IT-supportverlener moet een regulier schema voor logbeoordeling definiëren en volgen:”

Uit sectie “Governancevereisten”, beleidsclausule 5.1.1.

Het definieert ook bewaartermijnen en bescherming:

“Logboeken moeten ten minste 12 maanden worden bewaard, tenzij een langere bewaartermijn wettelijk of contractueel vereist is, of gerechtvaardigd is als onderdeel van een actief incident of juridisch geschil.”

Uit sectie “Governancevereisten”, beleidsclausule 5.2.1.

“Logboeken moeten worden opgeslagen op schrijfbeveiligde locaties en toegang moet uitsluitend worden beperkt tot geautoriseerd personeel.”

Uit sectie “Governancevereisten”, beleidsclausule 5.3.1.

Voor NIS2 en DORA kan een baseline van 12 maanden voor bewijs het verschil maken tussen een geloofwaardige reconstructie en een mislukt onderzoek. Voor GDPR ondersteunt dit de verantwoordingsplicht, terwijl gegevensminimalisatie, toegangscontrole en discipline rond bewaartermijnen vereist blijven.

De ontbrekende brug: gebeurtenisbeoordeling en meldingsdrempels

Veel organisaties verzamelen logboeken en genereren alerts op afwijkingen, maar falen op het beslismoment.

Was de alert alleen een beveiligingsgebeurtenis, of werd het een informatiebeveiligingsincident? Was het significant onder NIS2? Was het een major ICT-related incident onder DORA? Waren persoonsgegevens betrokken? Is analyse voor melding van een inbreuk onder GDPR vereist?

Dat beslismoment mappt op ISO/IEC 27002:2022 control 5.25, Beoordeling en besluitvorming over informatiebeveiligingsgebeurtenissen. Zenith Controls beschrijft 5.25 als de triagefunctie tussen ruwe monitoringalerts en formele incidentafhandeling. De maatregel verbindt 5.25 met incidentmanagementplanning, monitoringactiviteiten, respons op informatiebeveiligingsincidenten en logging. 5.25 wordt ook gemapt op GDPR Articles 33 en 34 voor inbreukmelding en risico-evaluatie, op NIS2-incidentmelding en classificatiecriteria, en op DORA-classificatie van major ICT-related incidents.

Clarysec’s Incidentresponsbeleid Incidentresponsbeleid ondersteunt dat escalatiepunt:

“Als een incident leidt tot bevestigde of waarschijnlijke blootstelling van persoonsgegevens of andere gereguleerde gegevens, moeten Juridische Zaken en de DPO de toepasselijkheid beoordelen van:”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.4.1.

Voor mkb-organisaties stelt het Incidentresponsbeleid - mkb Incidentresponsbeleid - mkb de technische bewijsvereiste vast:

“Loggingsystemen moeten zodanig worden geconfigureerd dat zij voldoende detail vastleggen ter ondersteuning van onderzoek.”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.4.1.

Hier wordt GDPR Article 33 operationeel. De vraag is niet alleen of persoonsgegevens zijn ingezien. De vraag is of logboeken, monitoringalerts en incidentregistraties de DPO in staat stellen een tijdige en verdedigbare inbreukbeoordeling uit te voeren.

NIS2 Article 23 en DORA Articles 17 tot en met 23 leggen vergelijkbare druk op. Meldtermijnen zijn afhankelijk van bewustwording, classificatie en materialiteitsbeoordeling. De organisatie moet kunnen aantonen wanneer de alert is gegenereerd, wanneer deze is beoordeeld, wie deze heeft beoordeeld, welk besluit is genomen en wanneer escalatie heeft plaatsgevonden.

Een bewijsoefening van 60 minuten voor onderzoek naar een geprivilegieerde aanmelding

Een nuttige manier om gereedheid van bewijs te testen is een realistisch scenario oefenen vóór de audit of het incident.

Scenario: een geprivilegieerd beheerdersaccount meldt zich om 02:13 UTC aan vanuit een ongebruikelijk land. Vijf minuten later probeert het account toegang te krijgen tot een exportfunctie voor klantgegevens. Voorwaardelijke toegang blokkeert de sessie en er wordt een alert gegenereerd.

Doel: produceer binnen 60 minuten een bewijspakket dat detectie, beoordeling, escalatie, besluitvorming en afsluiting aantoont.

Stap 1: Bevestig dat de gebeurtenis in logboeken bestaat

Gebruik het Beleid voor logging en monitoring om vereiste logbronnen te identificeren: logboeken van identiteitsproviders, cloudbeheerlogboeken, applicatielogboeken, databaselogboeken, endpointlogboeken en firewall- of secure-access-logboeken.

Exporteer de gebeurtenisregistratie met tijdstempel, gebruikers-ID, bron-IP, apparaat, actie, resultaat en correlatie-ID. Als de gebeurtenis alleen in één console bestaat en niet in het SIEM of de logcollector, leg dat dan vast als een beheersingshiaat.

Zenith Blueprint Step 19 beveelt aan te waarborgen dat kritieke systemen logboeken doorsturen naar het SIEM of de centrale logcollector en te valideren dat bewaartermijnen in lijn zijn met het beleid.

Stap 2: Toon aan dat monitoring dit heeft gedetecteerd

Toon de SIEM-alert, EDR-alert of alert voor identiteitsbescherming. Neem de regelnaam, ernst, tijdstempel, triggervoorwaarde en meldroute op. Als de organisatie handmatige beoordeling gebruikt, toon dan het dagelijkse rapport en de goedkeuring van de beoordelaar.

Het enterprise Beleid voor logging en monitoring maakt hiervan een rolverantwoordelijkheid:

“Beoordeelt dagelijkse rapportages en zorgt ervoor dat afwijkingen worden geanalyseerd, gedocumenteerd en waar nodig geëscaleerd.”

Uit sectie “Rollen en verantwoordelijkheden”, beleidsclausule 4.2.3.

Stap 3: Toon aan dat escalatie binnen beleidstermijnen heeft plaatsgevonden

Voor mkb-organisaties is de escalatievereiste expliciet:

“Alerts met hoge prioriteit moeten binnen 24 uur worden geëscaleerd naar de GM en de privacycoördinator.”

Uit sectie “Handhaving en naleving”, beleidsclausule 8.1.2.

Voor enterprise-teams kan bewijs bestaan uit een incidentticket, Teams- of Slack-escalatieregistratie, paginglogboek, e-mailmelding, SOC-overdrachtsnotitie of case-managementvermelding.

Stap 4: Classificeer de gebeurtenis

Gebruik de 5.25-logica voor gebeurtenisbeoordeling uit Zenith Controls. Leg vast of de alert een beveiligingsgebeurtenis, informatiebeveiligingsincident, inbreuk in verband met persoonsgegevens, significant NIS2-incident of DORA major ICT-related incident is.

De classificatienotitie moet antwoord geven op:

• Was authenticatie succesvol of geblokkeerd?
• Is geprivilegieerde toegang gebruikt?
• Zijn klantgegevens ingezien, gewijzigd of geëxfiltreerd?
• Zijn gereguleerde diensten verstoord?
• Zijn kritieke ICT-activa getroffen?
• Zijn leveranciers of verwerkers betrokken?
• Voldoet de gebeurtenis aan interne meldingsdrempels?
• Is melding aan de DPO, Juridische Zaken, een toezichthouder of klanten vereist?

Stap 5: Bouw een betrouwbare tijdlijn op

Kloksynchronisatie wordt vaak genegeerd totdat een onderzoek vastloopt. Zenith Blueprint Step 19 stelt dat gesynchroniseerde tijd essentieel is voor gebeurteniscorrelatie, omdat logboeken uit verschillende systemen tijdens incidentanalyse op elkaar moeten aansluiten.

Neem NTP-configuratiebewijs op voor identiteitsplatformen, clouddiensten, servers, endpoints, databanken, firewalls en het SIEM. Normaliseer tijdstempels waar mogelijk naar UTC.

Stap 6: Sluit af of escaleer

Als de gebeurtenis is ingedamd en er geen gegevens zijn ingezien, documenteer dan afsluiting, geleerde lessen en preventieve actie. Als de gebeurtenis een incident wordt, koppel deze dan aan incidentrespons, juridische toetsing en eventuele meldingsworkflows voor NIS2, DORA of GDPR.

Bescherm tot slot het bewijs. Clarysec’s Beleid voor audit en compliancemonitoring Beleid voor audit en compliancemonitoring stelt:

“Alle auditlogs, bevindingen en herstelrapportages moeten worden bewaard, versleuteld en beschermd tegen manipulatie.”

Uit sectie “Handhaving en naleving”, beleidsclausule 8.5.1.

Deze ene oefening levert bewijs op voor Bijlage A.8.15, A.8.16, A.8.17, ISO/IEC 27002:2022 control 5.25, verantwoordingsplicht voor inbreuken onder GDPR, incidentafhandeling onder NIS2 en classificatie van ICT-incidenten onder DORA.

Cross-compliancekaart voor bewijs voor ISO 27001, NIS2, DORA en GDPR

De sterkste nalevingsprogramma’s bouwen geen afzonderlijke bewijssets per raamwerk. Ze bouwen één bewijssysteem dat vanuit meerdere auditperspectieven kan worden bekeken.

NIST Cybersecurity Framework 2.0 kan helpen dit als communicatielaag te operationaliseren. De zes functies, GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND en RECOVER, laten zien dat logging en monitoring vooral in DETECT en RESPOND zitten, maar afhankelijk zijn van governance, inzicht in bedrijfsmiddelen en risicoprioriteiten.

NIST CSF 2.0-profielen kunnen ook een roadmap voor 2026 ondersteunen. Een Current Profile kan de huidige loggingdekking en alertvolwassenheid tonen. Een Target Profile kan de vereiste dekking definiëren voor gereguleerde systemen, geprivilegieerde activiteit, leveranciersplatformen en omgevingen met persoonsgegevens. Het verschil daartussen wordt het herstelplan.

Leveranciers- en cloudlogboeken: het bewijsprobleem dat auditors steeds vaker testen

In moderne audits hebben de lastigste loggingvragen vaak betrekking op uitbestede platforms.

Kunt u authenticatielogboeken van uw cloudprovider raadplegen? Worden SaaS-beheerdersacties gelogd? Zijn database-auditlogs ingeschakeld in beheerde diensten? Bewaart uw MSSP alerts lang genoeg? Vereisen contracten medewerking bij incidenten? Kunnen leveranciers logboeken snel genoeg leveren voor NIS2- of DORA-meldtermijnen? Zijn verwerkerslogboeken beschikbaar voor inbreukbeoordeling onder GDPR?

Zenith Controls verbindt Monitoringactiviteiten, control 8.16, met Monitoring van leveranciersdiensten, control 5.22. Ook wordt monitoring gemapt op ISO/IEC 27005:2024 clausule 10.5, waarin monitoring en beoordeling van risicobehandelingsplannen en beheersmaatregelen centraal staan, en op ISO/IEC 27035-2:2023 clausule 7.3, waar continue monitoringmechanismen informatiebeveiligingsgebeurtenissen detecteren en incidentbeheer activeren.

DORA maakt leverancierslogging bijzonder belangrijk voor financiële entiteiten, omdat ICT-risicobeheer van derde partijen leveranciersregisters, contractuele afspraken, onderuitbestedingsrisico, concentratierisico en exitstrategieën omvat. NIS2 Article 21 plaatst beveiliging van de toeleveringsketen binnen maatregelen voor cyberbeveiligingsrisicobeheer. GDPR kan leverancierslogboeken doorslaggevend maken wanneer een incident bij een verwerker kan uitgroeien tot een voor de verwerkingsverantwoordelijke meldplichtige inbreuk in verband met persoonsgegevens.

Een praktische clausule voor leverancierslogging moet het volgende vereisen:

• Beveiligingsrelevante auditlogs voor authenticatie, wijzigingen in privileges, beheerdershandelingen, API-toegang, gegevensexport en configuratiewijzigingen.
• Logretentie afgestemd op beleid, wettelijke plichten en contractrisico.
• Tijdsynchronisatie en normalisatie van tijdzones.
• Bescherming tegen manipulatie en beperkte toegang tot logboeken.
• Medewerking bij incidenten binnen vastgestelde termijnen.
• Levering van bewijs voor audits, onderzoeken en verzoeken van toezichthouders.
• Meldingstriggers voor verdachte toegang, servicecompromittering of gegevensblootstelling.
• Logging- en escalatieverplichtingen voor subverwerkers waar relevant.

Leverancierslogging moet vóór een incident worden geregeld, niet tijdens een incident worden uitonderhandeld.

Hoe verschillende auditors dezelfde loggingsmaatregel testen

Een goed bewijspakket moet verschillende professionele perspectieven kunnen doorstaan. Een ISO-auditor, NIS2-beoordelaar, DORA-toezichthouder, GDPR-beoordelaar en COBIT 2019- of ISACA-georiënteerde auditor kunnen naar hetzelfde SIEM-dashboard kijken, maar zij stellen verschillende vragen.

Zenith Blueprint Step 19 bereidt organisaties op deze vragen voor. Voor Logging richten auditors zich op de vraag of belangrijke beveiligingsgebeurtenissen worden gelogd en of logboeken worden bewaard, beschermd en bruikbaar zijn. Voor Monitoringactiviteiten vragen zij hoe ongebruikelijke of ongeautoriseerde activiteit wordt gedetecteerd, geëvalueerd en geëscaleerd. Voor Kloksynchronisatie kunnen zij tijdstempels tussen systemen vergelijken en onjuiste uitlijning signaleren.

Step 16: People Controls II, control 6.8, is ook relevant omdat incidentmeldingsmechanismen menselijke meldingen verbinden met technische detectie. GDPR Article 33, NIS2 Article 23 en DORA-incidentmeldingsverplichtingen zijn allemaal afhankelijk van tijdige interne escalatie.

Veelvoorkomende auditbevindingen en praktische oplossingen

De meeste bevindingen over logging en monitoring zijn voorspelbaar. Het probleem is dat organisaties ze vaak tijdens de audit ontdekken in plaats van tijdens interne testen.

Voor organisaties met beperkte middelen is de mkb-beleidsaanpak realistisch. Deze vereist geen volledig SOC vanaf dag één. Wel vereist deze vastgestelde beoordelingsschema’s, bewaring gedurende 12 maanden tenzij langer nodig is, schrijfbeveiligde opslag, beperkte toegang en escalatie van alerts met hoge prioriteit. Dat creëert een verdedigbare baseline terwijl de organisatie doorgroeit naar gecentraliseerd SIEM, geautomatiseerde correlatie en managed detection.

Metrieken die logging geloofwaardig maken voor leidinggevenden

Besturen en leidinggevenden hebben geen ruwe SIEM-gebeurtenissen nodig. Zij hebben risicorelevante assurance nodig. Omdat NIS2 Article 20 en DORA-governancevereisten verantwoordelijkheid bij leidinggevende organen leggen, moeten metrieken voor logging en monitoring onderdeel zijn van rapportage over informatiebeveiligingsgovernance.

Nuttige metrieken zijn onder meer:

• Percentage kritieke bedrijfsmiddelen dat logboeken doorstuurt naar het SIEM of de logcollector.
• Percentage gebeurtenissen met geprivilegieerde toegang dat door alarmering wordt gedekt.
• Aantal alerts met hoge prioriteit dat binnen SLA is beoordeeld.
• Gemiddelde tijd vanaf alertgeneratie tot beoordeling door een analist.
• Gemiddelde tijd vanaf detectie tot escalatie.
• Aantal gebeurtenissen dat onder het incidentresponsproces is geclassificeerd.
• Aantal gebeurtenissen waarvoor beoordeling door DPO of Juridische Zaken vereist is.
• Naleving van logretentie per systeemcategorie.
• Aantal leveranciersplatformen met contractuele toegang tot logboeken.
• Aantal systemen waarbij controles op kloksynchronisatie falen.
• Openstaande herstelmaatregelen voor logging en monitoring per risiconiveau.

Deze metrieken ondersteunen ISO/IEC 27001:2022 clausule 6.2 voor meetbare informatiebeveiligingsdoelstellingen. Zij versterken ook het toezicht door leidinggevenden onder NIS2 en DORA en de verantwoordingsplicht onder GDPR.

Uw bewijspakket voor logging en monitoring in 2026 opbouwen

Een sterk bewijspakket voor 2026 moet vóór de audit of het incident worden samengesteld. Clarysec adviseert doorgaans een gestructureerde map of een GRC-bewijsobject met de volgende onderdelen:

1. Governance en scope: ISMS-scope, belanghebbenden, toepasselijkheid van regelgeving, managementgoedkeuring en roltoewijzingen.
2. Beleid: Beleid voor logging en monitoring, Incidentresponsbeleid, Beleid voor audit en compliancemonitoring, bewaartermijneisen en escalatievereisten.
3. Risico en SoA: risicobeoordeling, risicobehandelingsplan, onderbouwing in de Verklaring van Toepasselijkheid voor A.8.15, A.8.16, A.8.17 en gerelateerde beheersmaatregelen.
4. Architectuur: SIEM- of logcollectordiagram, inventaris van logbronnen, instellingen voor cloudlogging en afhankelijkheden van leverancierslogboeken.
5. Werking van beheersmaatregelen: beoordelingsregistraties, alerts, tickets, escalatielogboeken, afsluitingsbewijs en uitzonderingen.
6. Incidentkoppeling: werkblad voor gebeurtenisclassificatie, incidentregister, DPO-beoordelingsregistratie en beslislogboek voor meldingen.
7. Integriteit en bewaartermijnen: toegangscontroles, encryptie, schrijfbeveiliging, archiefinstellingen, verwijderingscontroles en bewijs van bewaartermijnen.
8. Tijdsynchronisatie: NTP-configuratie, beveiligde baseline, monitoring van klokafwijking en aanpak voor UTC-normalisatie.
9. Leveranciersbewijs: contractclausules, assurance-rapportages van leveranciers, beschikbaarheid van cloudauditlogs en procedures voor incidentmedewerking.
10. Verbetering: interne auditbevindingen, tracker voor herstelmaatregelen, resultaten van tabletop-oefeningen, registraties van alerttuning en managementrapportages.

Het doel is niet om auditors met volume te overspoelen. Het doel is aan te tonen dat logging en monitoring als een beheerst proces functioneren: van governance tot detectie, beoordeling, escalatie, rapportage en verbetering.

Zet logboeken om in verdedigbaar compliancebewijs

Maria’s team loste het probleem niet op door nog een dashboard aan te schaffen. Het loste het probleem op door logging en monitoring om te vormen tot een bewijsmotor. Beleid definieerde de vereisten. SIEM-regels en cloudlogboeken leverden signalen. Incidentworkflows legden besluiten vast. Kloksynchronisatie maakte de tijdlijn geloofwaardig. Managementrapportage maakte het risico zichtbaar.

Dat is de standaard die organisaties in 2026 nodig hebben voor ISO/IEC 27001:2022, NIS2, DORA en GDPR.

Begin met één praktische test: neem een echte alert uit de afgelopen 30 dagen en toon end-to-end aan hoe deze is gelogd, gedetecteerd, beoordeeld, geëscaleerd, geclassificeerd, bewaard en gerapporteerd.

Als het antwoord niet overtuigend is, kan Clarysec u helpen het hiaat te sluiten.

Gebruik Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint om Step 19 voor logging, monitoring en kloksynchronisatie te implementeren, en Step 16 voor incidentmeldingsmechanismen. Gebruik Zenith Controls: The Cross-Compliance Guide Zenith Controls om Bijlage A.8.15, A.8.16, A.8.17 en ISO/IEC 27002:2022 control 5.25 te mappen op perspectieven vanuit NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT 2019.

Operationaliseer de vereisten vervolgens via Clarysec’s Beleid voor logging en monitoring Beleid voor logging en monitoring, Beleid voor logging en monitoring - mkb Beleid voor logging en monitoring - mkb, Incidentresponsbeleid Incidentresponsbeleid, Incidentresponsbeleid - mkb Incidentresponsbeleid - mkb en Beleid voor audit en compliancemonitoring Beleid voor audit en compliancemonitoring.

Logboeken zijn pas bewijs wanneer ze worden bestuurd, beschermd, beoordeeld en verbonden met besluiten. Organisaties die die keten kunnen aantonen, komen sneller door audits, reageren beter op incidenten en geven leidinggevenden vertrouwen wanneer de volgende alert om 02:17 binnenkomt.