Je database is geen iCloud, ook niet onder NIS2

Je pakt je iPhone en ziet de melding dat je iCloud-opslag bijna vol is. Je tikt op “Meer opslag” en gaat van 50GB naar 200GB. Een jaar later naar 2TB. Ondertussen staan er veertien bijna identieke foto’s van dezelfde zonsondergang in je bibliotheek, plus screenshots van parkeertickets uit 2019 en een paar video’s van de binnenkant van je broekzak. Alles bewaard, voor de zekerheid. Zoek je die ene foto van de verjaardag van je moeder, dan ben je een kwartier aan het scrollen.

Edco Wallet, medeoprichter en eigenaar van OptimaData, ziet bij databases precies hetzelfde patroon. Daar heet de fotobibliotheek audit-logging, en door NIS2 staat die knop bij steeds meer organisaties op “alles”.

Edco Wallet

Co-Founder & eigenaar

Telefoonnummer E-mailadres

Waarom organisaties alle auditing aanzetten

Sinds 15 augustus 2026 geldt de Cyberbeveiligingswet, de Nederlandse uitwerking van NIS2. Organisaties die eronder vallen, moeten aantoonbaar in control zijn. Bij een significant incident doe je binnen 24 uur een eerste melding. Je moet kunnen herleiden wat er is gebeurd en laten zien dat je de toegang tot je systemen beheerst. Zonder logging lukt dat niet. De reflex is dus begrijpelijk: zet alle auditing aan, dan zit je in ieder geval goed.

Toch vraagt de wet iets anders. NIS2 gaat uit van passende maatregelen op basis van risico’s. Nergens staat dat je elke transactie in je database moet vastleggen. ISO/IEC 27001:2023 + A1:2024, de norm waar veel organisaties hun NIS2-aanpak op bouwen, werkt op dezelfde manier. Je bepaalt eerst welke risico’s je loopt en richt je logging daarop in. In de praktijk gaat het vaak precies andersom.

De gevolgen van onbeperkt loggen

Bij een klant kwamen we een productiedatabase van 60GB tegen. Om compliant te zijn stond alle audit-logging aan. De database legde elke transactie vast, ook de duizenden routineklussen die voor compliance niets toevoegen. Na een paar jaar stond er 500TB aan logdata naast die database van 60GB. Dat is ruim achtduizend keer zo veel. Ik noemde dit voorbeeld al kort in mijn blog over NIS2 en AI-koppelingen, maar het verdient een eigen verhaal.

De opslagrekening is dan nog het kleinste probleem. Elke transactie levert extra schrijfwerk op, en dat merken je gebruikers in de responstijden van hun applicaties. Je back-ups en restores duren langer, dus je hersteltijd loopt op, terwijl continuïteit juist een van de pijlers van NIS2 is. Wil je bij een incident weten wie wat heeft gedaan, dan graaf je met een meldtermijn van 24 uur door een berg van 500TB. Die berg is bovendien zelf een risico, want auditlogs bevatten vaak gevoelige gegevens. Logdata die niemand beheert, is gewoon een extra plek waar het mis kan gaan.

Doelgericht loggen als middenweg

Log je te weinig, dan kun je niet aantonen wat er is gebeurd en voldoe je niet aan NIS2. Log je alles, dan betaal je met opslag, performance en overzicht. Het werkbare midden noemen wij doelgericht loggen. Je legt vast wat je bij een incident nodig hebt en laat de rest weg.

Doelgericht loggen in vijf stappen

Doelgericht loggen richt je in vijf stappen in. De eerste zet je op papier, nog voordat je iets aan je instellingen verandert.

Bepaal wat je moet kunnen aantonen. Denk aan inlogpogingen, acties van beheeraccounts, wijzigingen in rechten en rollen, schemawijzigingen en toegang tot gevoelige tabellen. Dat wil je bij een incident kunnen reconstrueren. Een SELECT op de productcatalogus hoort daar meestal niet bij.
Gebruik de filters van je database. PostgreSQL met pgAudit, SQL Server Audit en de auditplugins van MySQL en MariaDB filteren op gebruikers, objecten en soorten acties. Die mogelijkheden bestaan al jaren, maar blijven vaak liggen omdat je “alles aan” sneller instelt. In PostgreSQL ziet doelgericht loggen er bijvoorbeeld zo uit: met pgaudit.log = ‘ddl, role’ leg je schemawijzigingen en wijzigingen in rechten en rollen vast, en laat je gewone SELECT’s en INSERT’s met rust.
Houd logs weg bij je productiedatabase. Stuur auditdata naar een aparte omgeving of een SIEM. Dat ontlast je productieomgeving, en je logs blijven veilig als er iets met de database zelf gebeurt.
Leg een retentiebeleid vast. Spreek af hoe lang je welke logs bewaart. Daarna archiveer je ze op goedkope opslag en ruim je op wat je niet meer nodig hebt. Net als bij die fotobibliotheek: niet elke zonsondergang hoeft voor altijd in de cloud.
Test of je er iets mee kunt. Doe de proef. Kun je binnen een uur achterhalen wie gisteren de rechten op je klantentabel heeft gewijzigd? Lukt dat niet, dan heb je wel logging, maar nog geen aantoonbaarheid.

Auditinrichting die meegroeit met je risico’s

We zien dagelijks omgevingen waarin auditing uitstaat, en omgevingen waarin het zo ruim aanstaat dat het een probleem op zich is geworden. Auditing is Day 2-werk. Je applicaties veranderen, je rechtenstructuur verschuift en je risico’s schuiven mee, dus je inrichting moet meebewegen. Dat hoort bij een gezonde datafundering. Wij helpen je aan een auditinrichting die past bij je risico’s, die je performance heel laat en waarmee je bij een incident snel antwoord hebt.

Twijfel je of jouw auditing doorschiet? Plan een vrijblijvend gesprek, dan kijken we samen naar je inrichting. Voordat je database je iCloud-abonnement achternagaat.