Twee weken voor de livegang komt de pentest terug. Achttien bevindingen. Twaalf daarvan zijn binnen een dag opgelost: een ontbrekende header, een verlopen certificaat, een endpoint dat te veel teruggaf.
De andere zes zijn het probleem. Niet omdat ze moeilijk te begrijpen zijn, maar omdat ze geen fouten zijn. Het zijn keuzes. De gebruikers-tabel bevat het BSN omdat dat ooit handig leek. De applicatie praat met één databasegebruiker die overal bij kan. Er is geen enkele logregel die vertelt wie welk klantdossier heeft ingezien.
Dat repareer je niet in twee weken, want het zit in het ontwerp. En dat is precies waar security en privacy by design over gaan.
Het verschil tussen een bevinding en een ontwerpkeuze
Een fout patch je. Een ontwerpkeuze migreer je, en migreren doet pijn zodra er productiedata in zit.
Neem dat BSN. Weghalen betekent uitzoeken waar het overal terechtgekomen is: in back-ups, in exports, in een logbestand dat iemand ooit handig vond, in de zoekindex. Elk van die plekken is een apart gesprek. Had je het nooit opgeslagen, dan was het gesprek er niet geweest.
Dat is de kern van het idee, en het is minder verheven dan de term doet vermoeden. Het gaat niet om een veiligheidscultuur of een mindset. Het gaat erom dat je een paar beslissingen neemt vóórdat ze duur worden, op het moment dat ze nog niets kosten.
Dit jaar is het van vrijblijvend naar verplicht gegaan
De AVG zegt al sinds 2018 in artikel 25 dat je gegevensbescherming door ontwerp en door standaardinstellingen moet regelen. In de praktijk bleef dat vaak een alinea in een verwerkersovereenkomst.
Dat is in vijf weken tijd veranderd.
Op 15 augustus 2026 is de Cyberbeveiligingswet in werking getreden, de Nederlandse uitwerking van NIS2. Zo’n achtduizend organisaties vallen eronder. Die moeten zich registreren bij het NCSC, een risicoanalyse uitvoeren en daarop passende maatregelen nemen, en incidenten binnen vierentwintig uur melden bij het CSIRT. Belangrijk detail voor de directiekamer: het bestuur keurt die maatregelen goed en houdt toezicht op de uitvoering. Dat is geen delegeerbare taak.
Op 11 september 2026 zijn de meldplichten uit de Cyber Resilience Act ingegaan voor fabrikanten van producten met digitale elementen. Actief misbruikte kwetsbaarheden en ernstige incidenten moeten gemeld worden: binnen vierentwintig uur een vroegtijdige waarschuwing, binnen tweeënzeventig uur een volledige melding, en een eindrapport binnen veertien dagen nadat er een oplossing is. Dat loopt via het Single Reporting Platform naar het CSIRT en wordt gedeeld met ENISA.
Val je onder geen van beide, dan ben je er nog niet vanaf. Je klanten vallen er wel onder, en wat zij moeten aantonen schuiven ze door in hun contracten. Dat komt hoe dan ook bij je terug.
Wat vierentwintig uur eigenlijk betekent
Op die ene termijn wil ik even blijven hangen, want hij wordt makkelijk gelezen als een administratieve verplichting terwijl het een technische is.
Om binnen een dag te kunnen melden dat je actief misbruikt wordt, moet je dat kunnen zien. Dat betekent logging die je kunt doorzoeken, een idee van wat normaal verkeer is, en iemand die kijkt. De meeste organisaties die ik dit zie lezen ontdekken een inbraak doordat een klant belt of doordat er ineens spam vanaf hun domein gaat.
Auditlogging is daarmee verschoven van iets wat je erbij doet naar iets wat de wet feitelijk van je eist. Niet “we loggen alles” in een bestand dat niemand ooit opent, maar loggen dat antwoord geeft op één vraag: wie heeft wat gezien of gewijzigd, en wanneer.
Privacy by design, concreet
Los van de wet, dit is wat het in de praktijk betekent als je een systeem ontwerpt.
- Dataminimalisatie is de goedkoopste beveiliging die er is. Een veld dat je niet verzamelt kan niet lekken, hoeft niet versleuteld, staat niet in je back-up en komt niet terug in een inzageverzoek. Stel bij elk veld de vraag: wat gaat er stuk als we dit niet hebben?
- Bewaartermijnen horen in code, niet in beleid. Een bewaartermijn in een Word-document is geen bewaartermijn. Een geplande taak die daadwerkelijk verwijdert, is er wel een.
- Pseudonimiseren is niet anonimiseren. Vervang je een naam door een id maar bewaar je de sleutel, dan heb je nog steeds persoonsgegevens en gelden alle verplichtingen onverkort. Dat onderscheid wordt vaak door elkaar gehaald in gesprekken waar het juist op aankomt.
- Doelbinding zichtbaar in je datamodel. Wat je nodig hebt om te leveren staat los van wat je bewaart om te verkopen. Zitten die in dezelfde tabel, dan kun je ze ook niet los intrekken als iemand bezwaar maakt.
- Toegang tot productiedata is een ontwerpkeuze. Wie in je team kan een query op klantgegevens draaien, en staat dat ergens geregistreerd?
Security by design, concreet
- Dreigingsmodel vóór het schema vaststaat. Een uur met het team bij een whiteboard, met vier vragen: wat willen we beschermen, wie wil erbij, hoe komen ze binnen, en wat merken we ervan. Dat uur is achteraf onbetaalbaar.
- Dicht als standaard. Nieuwe endpoints, buckets en poorten beginnen gesloten en gaan bewust open. Andersom vergeet iemand het altijd.
- Minimale rechten, ook voor machines. De meeste applicaties praten met de database als één almachtige gebruiker. Dat is comfortabel tijdens het bouwen en het is precies wat een aanvaller nodig heeft.
- Sleutels met een levenscyclus. Niet in de repository, wel roteerbaar, en met een eigenaar. Een token zonder vervaldatum is een schuld die je pas ziet als hij ontploft.
- Ga ervan uit dat één laag faalt. Dat is de hele gedachte achter gelaagde beveiliging: niet dat elke muur houdt, maar dat er een tweede staat.
- Weet wat er in je software zit. Een actuele lijst van je afhankelijkheden is de enige manier om bij de volgende Log4j-achtige melding binnen een dag te kunnen zeggen of je geraakt bent.
Waarom vooraf zoveel goedkoper is
Vooraf zijn dit gesprekken. Een half uur over welke velden je opslaat, een uur over je dreigingsmodel, een beslissing over rechten die niemand nog is tegengekomen.
Achteraf zijn het datamigraties, met alles wat daarbij hoort: back-ups die je moet meenemen, klanten die je moet informeren, een leverancier die het ook nog in zijn systeem heeft staan. En bij persoonsgegevens komt daar iets bij wat je met techniek niet oplost. Gegevens die je nooit had moeten verzamelen kun je verwijderen, maar je kunt niet ongedaan maken dat ze er waren.
Hoe je het inricht zonder een programma op te tuigen
Je hebt hier geen securityafdeling voor nodig. Je hebt een paar vaste momenten nodig waarop de vraag gesteld wordt.
Bij elk nieuw onderdeel: welke gegevens raakt dit, hoe lang houden we ze, en wie kan erbij. Voordat een schema vastligt: een uur dreigingsmodel. In je pijplijn: een scan op sleutels die in de code zijn blijven staan. En één keer per kwartaal de vraag of je die vierentwintiguursmelding daadwerkelijk zou halen, met de logging die je nu hebt.
Dat is het. Geen certificeringstraject, geen dik document dat niemand leest.
Wil je weten waar je staat?
Wij lopen in drie kwartier met je door hoe jouw systeem ervoor staat op deze punten, en zeggen eerlijk wat we zien. Zit het goed, dan hoor je dat ook.
Plan een gesprek van 45 minuten of mail naar contact@3bird.nl.
