Technische maatregelen voor je website onder NIS2

Waarom de wet geen instellingen noemt

Zoek in de Cyberbeveiligingswet naar een TLS-versie, een headernaam of een wachtwoordlengte en je vindt niets. De wet benoemt tien zorgplichtmaatregelen op het niveau van beleid en proces, en laat de invulling aan jou. Het NCSC zegt het zo: organisaties zijn zelf verantwoordelijk voor het vaststellen welke maatregelen passend zijn, en risicomanagement vormt daarbij de basis.

Dat is geen vaagheid maar opzet: een datacenter en een gemeentelijke informatiesite lopen niet hetzelfde risico, dus dezelfde voorgeschreven instelling zou voor de een te weinig en voor de ander te veel zijn. Een deel van de uitwerking komt alsnog, via het Cyberbeveiligingsbesluit en ministeriële regelingen per sector. Wat daar niet in staat, vul je in met wat vakgenoten redelijkerwijs doen, en dat is precies wat hieronder staat.

Acht technische maatregelen, met de instelling erbij

Per maatregel: wat je instelt, welke waarde gangbaar is, en onder welke zorgplichtmaatregel hij valt. De letters verwijzen naar artikel 21 lid 2 van de NIS2-richtlijn, waar de tien maatregelen die het NCSC benoemt op teruggaan.

• Transportbeveiliging (sub h). Https op elk pad, een geldig certificaat, en een redirect van http naar https. Volg de TLS-richtlijnen van het NCSC: in de versie van mei 2025 staat TLS 1.3 op Goed en is TLS 1.2 teruggezet naar Voldoende; TLS 1.0 en 1.1 horen uit te staan. Zet HSTS aan met een max-age van minstens een half jaar.
• Securityheaders (sub e). Een Content-Security-Policy die daadwerkelijk iets tegenhoudt in plaats van alles toestaat, X-Content-Type-Options op nosniff, een Referrer-Policy, en clickjackingbescherming via frame-ancestors. Een header die er staat maar niets weigert, telt niet als maatregel.
• Geheimen buiten de browser (sub i). Geen API-sleutels of tokens in je JavaScript-bundle, en geen publiek opvraagbare .env, .git of back-upbestanden. Een sleutel die ooit in een bundle heeft gestaan is gelekt, ook nadat je hem eruit haalt: draai hem om in plaats van hem te verwijderen.
• Kwetsbaarhedenbeheer (sub e). Een afgesproken termijn waarbinnen je kritieke updates uitvoert, automatische meldingen op je dependencies, en een security.txt volgens RFC 9116 met een contactadres en een expires-datum die je bijhoudt. Een verlopen expires maakt het bestand ongeldig.
• Externe herkomsten (sub d). Elk script, font, tagmanager en CDN dat je pagina inlaadt voert code uit in de browser van je bezoeker. Houd een inventaris bij van wie dat zijn, host wat je zelf kunt hosten, en zet Subresource Integrity op wat van buiten blijft komen.
• E-mailbeveiliging (sub h). SPF, DKIM en DMARC op je domein, met een DMARC-beleid dat verder komt dan p=none. Doe dit ook op domeinen waarvandaan je nooit mail verstuurt: juist die zijn aantrekkelijk om uit jouw naam mee te spoofen, en niemand mist ze.
• Authenticatie op beheer (sub j). Meervoudige authenticatie op je CMS, je hosting, je DNS-beheer en je certificaatuitgifte; het NCSC noemt passkeys expliciet als invulling. Wie je DNS overneemt, neemt je website over, ongeacht hoe de site zelf beveiligd is.
• Logging met een bewaartermijn (sub b). Je moet binnen 24 uur kunnen vertellen wat er gebeurd is. Dat vraagt toegangs- en wijzigingslogs die lang genoeg bewaard blijven, en een kloppende klok op je servers: zonder betrouwbare tijdstempels valt een tijdlijn niet te reconstrueren.

De volgorde waarin je ze inricht

Alle acht tegelijk is geen plan. Deze volgorde levert de meeste risicoreductie per uur werk op, en elke stap is af te ronden voordat de volgende begint.

• Vandaag, binnen een uur: meervoudige authenticatie op je DNS-beheer en je hosting. Dit is de enige stap waarbij een fout je hele domein kost.
• Vandaag, binnen een uur: kijk of er sleutels in je bundle staan of configuratiebestanden publiek opvraagbaar zijn. Vind je iets, dan gaat het omdraaien van die sleutel voor op al het andere op deze lijst.
• Deze week: TLS en HSTS goedzetten en de securityheaders toevoegen. Draai een Content-Security-Policy eerst in report-only mee, anders breek je je eigen site voordat je weet wat hij inlaadt.
• Deze week: een security.txt plaatsen en DMARC aanzetten, eerst op p=none om te zien wat er onder je domein verstuurd wordt, daarna aanscherpen.
• Deze maand: de inventaris van externe scripts, het patchproces op papier, en de bewaartermijn van je logs. Dit is het deel dat blijft werken als jij er niet bent.

Wat je niet hoeft in te richten

Rond NIS2 wordt veel verkocht dat de wet niet vraagt. Passend betekent ook passend bij je omvang en je risico, en dus soms: niet doen.

• Geen verplichte webapplicatiefirewall. Een WAF kan een passende maatregel zijn, maar de wet noemt geen enkel product. Voor een site waar de basis hierboven nog niet staat, is het een pleister op de verkeerde plek.
• Geen verplichte pentest. De wet vraagt passende maatregelen op basis van een risicobeoordeling en schrijft geen specifiek onderzoek voor. Een pentest kan zo'n maatregel zijn; verplicht is hij niet.
• Geen certificering of keurmerk. De RDI stelt het expliciet: keurmerken bewijzen niet dat een organisatie aan de wet voldoet, en alleen een toezichthouder kan vaststellen of de regels worden nageleefd.
• Geen eigen securityteam dat dag en nacht meekijkt, tenzij je risico dat rechtvaardigt. Wat je wel nodig hebt is een afspraak over wie er kijkt en wanneer, en het vermogen om binnen 24 uur te melden.
• Geen maatregel zonder afweging. Besluit je iets niet te doen, leg dan vast waarom je dat risico aanvaardt. Dat is zelf een stuk bewijs: een ongedocumenteerde keuze is bij een audit niet te onderscheiden van vergeten.

Van instelling naar bewijs

Een ingestelde maatregel en een aantoonbare maatregel zijn twee verschillende dingen. Bij een audit, een klantvragenlijst of een incident is de vraag zelden hoe je iets geconfigureerd hebt, maar wanneer je voor het laatst gemeten hebt dat het er nog zo bij staat.

De helft van de lijst hierboven is van buiten meetbaar, en dat deel kun je nu laten controleren. Wat overblijft is het werk dat alleen jij kunt doen: het patchproces, de leveranciersinventaris, de bewaartermijn van je logs en de afwegingen die je hebt vastgelegd.

• Controleer gratis in zestig seconden: TLS-versies, het certificaat en HSTS
• Controleer gratis in zestig seconden: de securityheaders en je Content-Security-Policy
• Controleer gratis in zestig seconden: sleutels in je bundle en publiek staande configuratiebestanden
• Controleer gratis in zestig seconden: SPF, DKIM en DMARC op je domein
• Loop daarna de NIS2-checklist voor je website langs en bepaal per punt wie het oplost
• Wil je eerst de wettelijke kant zien, lees dan welke eisen NIS2 aan je website stelt

Veelgestelde vragen

Welke technische maatregelen schrijft NIS2 voor je website voor?

Geen enkele bij naam. De Cyberbeveiligingswet vraagt passende maatregelen op basis van je risicobeoordeling en benoemt tien zorgplichtmaatregelen op procesniveau. Voor een website vertaalt dat zich in de praktijk naar acht dingen: transportbeveiliging, securityheaders, geen geheimen in de browser, kwetsbaarhedenbeheer, controle op externe scripts, e-mailbeveiliging, meervoudige authenticatie op beheeraccounts en logging met een bewaartermijn.

Welke TLS-versie moet ik draaien?

De wet noemt er geen; het NCSC wel. In de TLS-richtlijnen van mei 2025 staat TLS 1.3 op Goed en is TLS 1.2 teruggezet naar Voldoende. TLS 1.0 en 1.1 horen uit te staan. Praktisch: zet 1.3 aan, houd 1.2 aan zolang je bezoekers die nodig hebben, en plan alvast het moment waarop je hem uitzet.

Is een WAF of een pentest verplicht onder NIS2?

Geen van beide. De wet schrijft geen producten en geen specifiek onderzoek voor, maar maatregelen die passen bij je risico. Een webapplicatiefirewall of een pentest kan zo'n maatregel zijn, zeker bij een applicatie die gevoelige gegevens verwerkt. Ze vervangen de basisinrichting niet: een WAF voor een site zonder werkende securityheaders lost het verkeerde probleem op.

Hoe leg ik vast dat een maatregel passend is?

Door de afweging op te schrijven, niet alleen de uitkomst. Noteer welk risico je ziet, welke maatregel je daartegen neemt, en wat het zou kosten om verder te gaan. Besluit je iets niet te doen, leg dan vast waarom je dat risico aanvaardt. Een gedocumenteerde keuze is verdedigbaar; een ongedocumenteerde is bij een audit niet te onderscheiden van vergeten.

Hoe vaak controleer ik of de instellingen nog kloppen?

De wet noemt geen frequentie, maar vraagt wel dat je de effectiviteit van je maatregelen beoordeelt, en daarvoor heb je meer dan een meting nodig. Werkbaar ritme: na elke release die de site raakt, en anders maandelijks. Certificaten verlopen, dependencies verschuiven en een header verdwijnt bij een deploy zonder dat iemand het merkt.