NIS2 voor platform teams: welke control voldoet aan welk artikel

TL;DR De Cyberbeveiligingswet geldt sinds 15 augustus 2026. Hieronder de tien maatregelen van artikel 21 gelegd op controls die echt draaien, een Kyverno-policy die er één bewijst, de meldtermijnen als drie Prometheus-alertingrules, en de vier plichten waar geen YAML onder past. De eerste run van die policy vond in m’n eigen cluster zeven pods waarvan ik had gezworen dat ze gemirrord waren.

De Cyberbeveiligingswet geldt sinds 15 augustus 2026. Het is de Nederlandse uitvoering van NIS2 , krap 22 maanden na de datum waarop het van de richtlijn had gemoeten, en sindsdien is de vraag op werk niet meer hypothetisch. Niemand vroeg me of het cluster veilig was. De vraag was smaller, en een stuk lastiger. Welke maatregel uit artikel 21 dekt deze control af, en waar hebben we gewoon niks?

Vrijwel elke NIS2-tekst die ik kon vinden is geschreven door mensen die nog nooit kubectl hebben getypt. Vrijwel elke Kubernetes-securitytekst doet alsof er geen wet bestaat. Deze post zit daartussenin. Hij legt de tien maatregelen van de zorgplicht op controls die draaien. Daarna een policy die blokkeert, en de meldtermijnen als alerting rules die afgaan terwijl je er nog wat aan kunt doen.

Ik ben engineer, geen jurist. Elke juridische bewering hieronder komt uit de Cyberbeveiligingswet, het Cyberbeveiligingsbesluit of Richtlijn (EU) 2022/2555, alle drie gelezen op 2026-09-20. Artikelen worden vernummerd en ministers publiceren sectorregelingen. Controleer de bron voordat je een boete riskeert op mijn samenvatting.

De scope-test van vijf minuten

Sla de flowcharts van de adviesbureaus maar over. Drie vragen beslissen het voor de meeste organisaties.

Ben je een overheidsorganisatie? Cbw artikel 8, eerste lid, onderdeel h maakt provincies, gemeenten, waterschappen en kwalificerende gemeenschappelijke regelingen van rechtswege essentiële entiteit. Geen omvangstoets, geen risicobeoordeling. Een dorp van 9.000 inwoners zit in dezelfde categorie als een landelijke telecomaanbieder. Dat is een Nederlandse keuze, en precies de afwijking waar mensen op stuklopen. NIS2 artikel 2, vijfde lid, onderdeel a laat decentrale overheden optioneel. Nederland nam die optie en ging nog een stap verder. Ministeries en zbo’s van de rijksoverheid staan een onderdeel hoger, in 8 lid 1 onder g.

Ben je groot genoeg? Voor de rest verwijst de wet naar Aanbeveling 2003/361/EG . Onder de 50 medewerkers en onder EUR 10 miljoen op zowel omzet als balanstotaal val je erbuiten, tenzij een van de omvangsonafhankelijke categorieën je alsnog raakt. Middelgroot, 50 tot 249 medewerkers of voorbij die EUR 10 miljoen, levert belangrijke entiteit op vanuit beide bijlagen. Boven het middelgrote plafond, 250 medewerkers of EUR 50 miljoen omzet met een balanstotaal boven EUR 43 miljoen, wordt een bijlage 1-entiteit essentieel, terwijl bijlage 2 belangrijk blijft hoe groot je ook wordt.

Ben je omvangsonafhankelijk? Gekwalificeerde vertrouwensdienstverleners, TLD-registries, DNS-dienstverleners en aanbieders van openbare elektronische communicatienetwerken en -diensten vallen eronder ongeacht het aantal medewerkers. Kritieke entiteiten aangewezen onder de Wwke net zo.

Sommige organisaties vallen er helemaal buiten. Defensie, de inlichtingen- en veiligheidsdiensten, het Openbaar Ministerie, de politie en de veiligheidsregio’s, plus de rechtspraak, beide Kamers en De Nederlandsche Bank. Ze houden het recht op bijstand van het NCSC onder artikel 96.

Het onderscheid tussen die twee categorieën telt zwaarder dan het lijkt. De RDI houdt proactief toezicht op essentiële entiteiten, en dat betekent dat ze informatie kunnen opvragen of gewoon langskomen. Bij belangrijke entiteiten gebeurt toezicht vooral achteraf, en Cbw artikel 81 beperkt het handhavingsinstrumentarium tot gevallen waarin de autoriteit al aanwijzingen van een overtreding heeft. Ben je essentieel, dan heeft de toezichthouder dus geen incident nodig om je beleid op te vragen. Die kan gewoon vragen.

De tien maatregelen, in kaart gebracht

Artikel 21, derde lid noemt tien maatregelen. Cbb artikelen 6 tot en met 18 maken er concrete verplichtingen van, dus het besluit is wat je leest als je wilt weten wat “incidentenbehandeling” op papier betekent. Zo landen ze op een cluster.

Twee dingen vielen me op. Cbb artikel 17 voegt een plicht toe waar artikel 21, derde lid met geen woord over rept. Je moet gerichte waarschuwingen, beveiligingsadviezen en threat intelligence opvolgen. Lees je de NCSC-advisories al en patch je erop, dan voldoe je, maar alleen als je kunt laten zien wat je hebt gedaan. En Cbb artikel 4 haalt de digitale entiteitstypen helemaal uit artikelen 6 tot en met 18, omdat Uitvoeringsverordening (EU) 2024/2690 ze al dekt. Cloud-, datacenter-, CDN-, managed service- en managed security-aanbieders lezen dus die verordening.

Zit je in de sector overheid, dan gaat de regeling verder en noemt ze het raamwerk bij naam: NEN-EN-ISO/IEC 27001:2023 voor het managementsysteem, en de maatregelen van NEN-EN-ISO/IEC 27002:2022 minus 5.32 en 5.34, plus de relevante BIO2 -maatregelen. Gelijkwaardige raamwerken mogen, als ze hetzelfde niveau halen.

De kleinste policy die een maatregel bewijst

Maatregel d is waar een cluster iets kan wat een beleidsdocument niet kan. Ketenbeveiliging begint bij weten waar elke image vandaan komt, en een admission controller maakt daar een eigenschap van het cluster van in plaats van een goed voornemen.

Ik gebruik hier Kyverno voor, omdat de policy een Kubernetes-resource is en in Git naast al het andere leeft. De kleinste bruikbare versie is een registry-allowlist:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: registry-allowlist
  annotations:
    policies.kyverno.io/description: >-
      Cbw art. 21 lid 3 onder d, ketenbeveiliging. Tegelijk de voorwaarde om
      art. 21a te overleven: een leveranciersverbod is alleen te doen als je
      van elke image de herkomst kent.
spec:
  background: true
  rules:
    - name: only-approved-registries
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: >-
          Images komen alleen van registry.example.nl (Cbw art. 21 lid 3 onder d).
        pattern:
          spec:
            =(ephemeralContainers):
              - image: "registry.example.nl/*"
            =(initContainers):
              - image: "registry.example.nl/*"
            containers:
              - image: "registry.example.nl/*"

Kyverno 1.13 verplaatste failureAction naar de rule. Op 1.12 en ouder heet het spec.validationFailureAction, en zo staat het in de oudere policies in mijn repo nog steeds.

Het commando dat bewijst dat hij blokkeert:

$ kubectl run test --image=nginx:1.27

Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/default/test was blocked due to the following policies

registry-allowlist:
  only-approved-registries: 'validation error: Images komen alleen van
    registry.example.nl (Cbw art. 21 lid 3 onder d). rule only-approved-registries
    failed at path /spec/containers/0/image/'

Die uitvoer is het artefact. Een toezichthouder die vraagt hoe ik m’n keten beheers krijgt die policy en die weigering, met een tijdstempel erbij. Dat geef ik liever af dan een alinea in een Word-bestand.

Draai hem eerst op Audit. Met background: true scant Kyverno wat er al draait, en kubectl get policyreport -A vertelt je dan hoeveel van je cluster geweigerd zou zijn. Bij mij leverde de eerste run zeven pods op die van Docker Hub trokken. Ik had gezworen dat die allemaal gemirrord waren.

Eén ding dat de policy aanneemt en zelf niet levert. registry.example.nl moet bestaan. Een allowlist met een registry die niemand draait blokkeert elke workload en noemt dat compliance, dus maatregel d begint bij de artifact repository. De admission rule komt daarna.

Bij mij is dat zot, een OCI-native registry die als één binary draait en upstream images op een schema synct. Twee redenen waarom dat past in een post over de zorgplicht. De CVE -search is Trivy onder de motorkap, dus maatregel e wordt beantwoord door hetzelfde component dat het artefact bewaart, en niet door een tweede tool met een eigen database die je bij moet houden. En één binary zonder database ernaast is een keten die ik van begin tot eind kan overzien, en dat is meteen de hele reden dat ik hem draai. Zelf de bits vasthouden levert nog drie dingen op. Een image blijft bestaan nadat een upstream tag opnieuw is gezet of verwijderd, en dat is het soort storing dat op een zondag een cluster omlegt. De vervangingstermijn uit artikel 21a wordt iets waar je echt naar kunt handelen, want een leverancier wisselen betekent herbouwen uit artefacten die al op je eigen schijf staan. En Cbb artikel 10 , dat om ketenbeleid en het toetsen van directe leveranciers vraagt, krijgt een grens om naar te wijzen, want de lijst directe leveranciers is de lijst upstreams waar de mirror van trekt.

Diezelfde policy is je antwoord op Cbw artikel 21a , dat in de richtlijn geen enkele tegenhanger heeft. Het laat de verantwoordelijke minister een entiteit opdragen te stoppen met de producten van een met naam genoemde partij in met naam genoemde delen van haar systemen, met een vervangingstermijn in het belang van de continuïteit. Wordt die bevoegdheid ooit gebruikt? Geen idee. De vraag eronder is het nuttige deel. Als er morgen een leverancier wordt aangewezen, kun je dan opsommen waar hun code overal draait? Met een allowlist en een image-inventaris is dat een kwestie van minuten. Met een spreadsheet weken.

De meldklok, als alerting rules

Elk ander stuk hierover laat deze termijnen proza, en je monitoring leest geen proza. Eerst de termijnen, dan de rules.

Twee valkuilen in die tabel. De maandtermijn loopt vanaf de melding, dus een trage melding op 72 uur schuift je maand op. En de Nederlandse tekst zegt niet “binnen 24 uur”. Er staat “onverwijld of, indien dat niet mogelijk is, binnen 24 uur”, dus meteen, en pas als dat echt niet kan krijg je die 24 uur. De buitengrens is gelijk aan die van de richtlijn, en de plicht om meteen te bewegen komt daar bovenop.

Een incident is significant als het een ernstige operationele verstoring of financiële verliezen veroorzaakt of kan veroorzaken, of als het andere entiteiten heeft getroffen of kan treffen door aanzienlijke schade. Sectorministers kunnen criteria toevoegen, en een besluit gericht aan één specifieke entiteit is binnen die entiteit vertrouwelijk, dus kijk naar je eigen sector en niet naar een algemene lijst.

Elke termijn in die tabel is een looptijd vanaf één moment, het moment waarop je bekend werd met het incident. Niets in je infrastructuur weet wanneer dat was, dus niets kan je vertellen dat die 24 uur bijna om zijn. De oplossing is dat moment omzetten in een getal dat je monitoring kan lezen. Een incident uitroepen pusht één gauge naar Pushgateway, met de Unix-tijdstempel van de declaratie:

cat <<'EOF' | curl --data-binary @- \
  https://pushgateway.example.nl/metrics/job/nis2/incident/INC-2026-014
# TYPE nis2_incident_declared_timestamp_seconds gauge
nis2_incident_declared_timestamp_seconds 1758394800
EOF

Pushgateway en geen scrape, want er valt niks te scrapen. Een declaratie gebeurt één keer, op één moment, en een scrapetarget moet er nog staan als Prometheus langskomt. Er zit geen proces in een hoekje te herhalen dat er een incident loopt, en zoiets schrijven is een groter klusje dan deze curl. Pushgateway houdt de waarde vast tot iets hem overschrijft of weggooit.

De grouping key in die URL, incident/INC-2026-014, komt binnen als label op de metriek. Dat label laat een rule later de declaratie van één incident naast de verslagen van datzelfde incident leggen, en zo weet een alert dat hij beantwoord is.

Daarna is de alerting rekenwerk op één getal. time() is nu, de gauge is toen, en het verschil is hoelang dit incident al loopt. Elke rule gaat af vóór z’n eigen termijn, niet erop:

groups:
  - name: nis2-reporting
    rules:
      - alert: NIS2EarlyWarningDue
        expr: |
          (time() - nis2_incident_declared_timestamp_seconds > 20 * 3600)
          unless on (incident)
          nis2_report_filed_timestamp_seconds{step="early-warning"}
        labels:
          severity: page
          runbook: nis2-reporting
        annotations:
          summary: >-
            Vroegtijdige waarschuwing voor {{ $labels.incident }} moet binnen
            4 uur de deur uit (Cbw art. 26 lid 1). Naar CSIRT én toezichthouder.

      - alert: NIS2NotificationDue
        expr: |
          (time() - nis2_incident_declared_timestamp_seconds > 68 * 3600)
          unless on (incident)
          nis2_report_filed_timestamp_seconds{step="notification"}
        labels:
          severity: page
          runbook: nis2-reporting

      - alert: NIS2FinalReportDue
        expr: |
          (time() - nis2_report_filed_timestamp_seconds{step="notification"} > 26 * 86400)
          unless on (incident)
          nis2_report_filed_timestamp_seconds{step="final"}
        labels:
          severity: ticket
          runbook: nis2-reporting

Vier uur marge op een plicht van 24 uur, vier op 72, vier dagen op de maand. Een verslag indienen ruimt z’n eigen alert op, omdat de gauge voor die stap verschijnt en de unless niet meer matcht. Wil je de redenering achter alerten op een deadline in plaats van op een metriek, dan is dat hetzelfde argument als in alerting that works. Een alert bestaat om een mens één specifiek ding te laten doen, en deze noemt dat ding in z’n summary.

Eén afhankelijkheid wil ik nog kwijt vóór de runbook, want die bepaalt of dit überhaupt werkt. Een deadline-alert is alleen de moeite als een page nog iemand in beweging krijgt. In een organisatie met alertmoeheid, waar iedereen heeft geleerd dat het meeste wat afgaat ruis is om weg te klikken, sluit NIS2EarlyWarningDue gewoon aan in de rij die niemand opent. Dan heb je een wettelijke plicht gebouwd op een kanaal dat niet meer werkt, en dat zie je pas de nacht dat het je de termijn kost.

Herken je dat, dan is de alerting de eerste klus en zijn deze drie rules de tweede. Snij het volume terug tot alles wat afgaat betekent dat iemand nú iets moet doen. Dat is het hele argument van alerting that works, en hier is het een voorwaarde.

De runbook, want één incident levert twee meldingen op

NIS2 laat een lidstaat kiezen tussen melden bij het CSIRT of de bevoegde autoriteit. Cbw artikelen 26, eerste lid en 27, eerste lid zeggen CSIRT en bevoegde autoriteit. Eén indiening op MijnNCSC dekt in de praktijk allebei omdat die wordt doorgezet, maar de wettelijke plicht loopt naar twee partijen, en welke twee hangt af van je sector. Een gemeente meldt bij het NCSC en de RDI. Een waterschap meldt bij CERT-WM , ondergebracht bij Het Waterschapshuis, en staat onder toezicht van de ILT . De zorg meldt bij Z-CERT en staat onder toezicht van de IGJ . Zoek je eigen rij op, nu, zolang er nog niks aan de hand is.

De vroegtijdige waarschuwing vraagt ook meer dan de richtlijn. NIS2 wil twee feiten, of het incident vermoedelijk kwaadwillig is en of het grensoverschrijdende gevolgen kan hebben. Cbb artikel 24 doet er vier bij, elk met “zo mogelijk” ervoor. Het vermoedelijke starttijdstip, een beschrijving van de aard en de tot dan toe merkbare gevolgen, een inschatting van de hersteltijd, en de genomen of voorgenomen maatregelen. Zeven gegevens verzamelen binnen 24 uur terwijl het ding nog brandt is een ander klusje dan er twee verzamelen, en daarom staat dit in een runbook.

# Runbook: nis2-melding

## t+0  Uitroepen
- Ken INC-JJJJ-NNN toe. Push de declared-gauge (zie de alert-annotaties).
- Bepaal significantie: ernstige operationele verstoring, financieel verlies, of
  aanzienlijke schade bij andere entiteiten. Leg zowel de redenering
  als de uitkomst vast.

## t+0 tot t+24u  Vroegtijdige waarschuwing
Zeven velden, drie uit Cbw art. 26 lid 2 en vier uit Cbb art. 24:
1. Vermoedelijk onrechtmatig of kwaadwillig?   (ja / nee / onbekend)
2. Mogelijk grensoverschrijdende gevolgen?     (ja / nee / onbekend)
3. Contactgegevens van de verantwoordelijke melder
4. Vermoedelijk starttijdstip van het incident
5. Aard en tot nu toe merkbare gevolgen
6. Ingeschatte hersteltijd
7. Genomen of voorgenomen maatregelen
Indienen op MijnNCSC. Push de early-warning-gauge.

## t+0 tot t+72u  Melding
- Actualiseer de vroegtijdige waarschuwing waar die is veranderd
- Eerste beoordeling: ernst en impact
- Indicators of compromise, voor zover beschikbaar
- Alles waarmee het CSIRT grensoverschrijdende impact kan bepalen
Push de notification-gauge. De maandtermijn start hier.

## Onverwijld  Afnemers informeren
Informeer ze als het incident de dienstverlening nadelig kan beïnvloeden, en
informeer ze over een significante cyberdreiging die hen kan raken (Cbw art. 30).

## t+1 maand  Eindverslag
Gedetailleerde beschrijving, ernst, gevolgen, vermoedelijke oorzaak, toegepaste en
lopende maatregelen, grensoverschrijdende gevolgen.
Loopt het incident dan nog? Dien een voortgangsverslag in, en daarna het eindverslag
binnen een maand nadat het incident is afgehandeld.

Je bewijs is een retentie-instelling

Cbb artikel 8 vouwt logging in incidentenbehandeling. Klinkt mild, tot je een maand later het eindverslag zit te schrijven en merkt dat je audit logs zijn weggerold.

De Kubernetes audit policy die ik draai bewaart het dure niveau alleen waar het een vraag beantwoordt die ik echt gesteld ga krijgen:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets", "serviceaccounts/token"]
      - group: "rbac.authorization.k8s.io"
        resources: ["*"]
  - level: Metadata
    omitStages: ["RequestReceived"]

Wie een secret las en wie een autorisatie wijzigde, op volle detail. De rest op metadataniveau. Stuur het naar Loki en zet de retentie voorbij de meldhorizon. Je eindverslag mag een maand na de melding komen, een voortgangsverslag schuift dat verder op, en een toezichthouder kan er daarna nog naar vragen, dus 30 dagen retentie is op voordat het eindverslag überhaupt moet. Ik houd 400 dagen aan voor de audit-stream en 30 voor applicatielogs.

De maatregelen zonder YAML eronder

Niet alles past op een control, en doen alsof dat wel zo is, daar begint compliancetheater. Deze vier passen niet.

Het opleidingscertificaat voor bestuurders. Cbw artikel 24 gaat veel verder dan NIS2 artikel 20 . Elk bestuurslid heeft de kennis nodig om risico’s te identificeren, maatregelen te beoordelen en de gevolgen daarvan in te schatten, moet die kennis aantoonbaar actueel houden, en moet een certificaat hebben met daarop zijn naam, de opleidingsdata, de behandelde onderwerpen en de naam van de aanbieder, in het Nederlands of het Engels. Zittende bestuurders hebben tot 15 augustus 2028, twee jaar na inwerkingtreding, en wie later wordt benoemd krijgt twee jaar vanaf de benoeming. Een bestuurder die niet voldoet kan onder artikel 93 persoonlijk EUR 25.000 beboet worden. Niets in de richtlijn vraagt om een certificaat, een termijn of een persoonlijke boete. Dat artikel heb ik twee keer gelezen, voor de zekerheid. Bij overheidsorganisaties is “het bestuur” het college van burgemeester en wethouders, gedeputeerde staten of het dagelijks bestuur.

Registratie, die dichter bij jouw werk ligt dan het lijkt. Cbw artikel 44 vraagt om je naam, adressen, contactgegevens, IP-reeksen, sectoren, de lidstaten waar je diensten levert en je domeinnamen, en wijzigingen moeten binnen twee weken gemeld. Dat zijn infrastructuurfeiten. Een merge request die een prefix aan je IPAM toevoegt of een domein aan je DNS-zone is een registratiegebeurtenis. Behandel hem zo en de tweewekenplicht haal je per ongeluk. Doe je dat niet, dan ontdek je op een dag dat je hem al een jaar schendt. Registreren is verplicht sinds 15 augustus 2026 en er is geen overgangstermijn.

Periodieke evaluatie, en het gat eronder. NIS2 artikel 21, vierde lid verplicht een entiteit die constateert dat ze niet voldoet om onverwijld corrigerende maatregelen te nemen. Het Nederlandse artikel 21 heeft zo’n lid niet. Het dichtstbijzijnde is Cbb artikel 18 , een periodieke beoordeling van de effectiviteit, schriftelijk vastgelegd, met bijstelling waar nodig. Dat is zwakker, en dat gat mag je zelf vullen, want drift die je op dinsdag vindt en bij de volgende kwartaalevaluatie herstelt is juridisch verdedigbaar en operationeel gênant. Dit is de ene plek waar ik de wet liever overtref dan haal. Is je infrastructuur declaratief, dan kan die evaluatie leunen op wat de repo al bewijst, en dat is het argument uit declaratieve infrastructuur als compliance-bewijs.

Leveranciers toetsen. Cbb artikel 10 vraagt om ketenbeleid en het toetsen van directe leveranciers. De registry-allowlist bewijst wat er draait. Hij zegt niks over de vraag of de leverancier erachter patcht.

Wat de wet eigenlijk van je vraagt

De Cyberbeveiligingswet naast de richtlijn leggen was interessanter dan ik had verwacht, want de Nederlandse toevoegingen zijn geen bureaucratische ruis. Ze wijzen op hetzelfde waar ik vanuit de andere kant steeds op uitkom. Elke gemeente is essentieel ongeacht omvang, omdat de schade bij uitval niet meeschaalt met het aantal medewerkers. Bestuurders dragen een persoonlijke boete, omdat een risico dat niemand in de kamer begrijpt een risico is dat niemand beheerst. En een minister kan een met naam genoemde leverancier uit met naam genoemde systemen weren, en dat is een staat die hardop zegt dat afhankelijkheid van een leverancier die je niet kunt inspecteren een nationaal risico is.

Dat laatste is het argument dat ik over m’n eigen infrastructuur al jaren maak, en nu komt het via de wet. Kun je niet opsommen wat je draait en waar het vandaan komt, dan wordt een leveranciersverbod een archeologisch project. Ik draai dingen die ik begrijp om m’n eigen redenen. Een audit is alleen de eerste keer dat iemand anders me vraagt het te bewijzen. De langere versie staat in soevereine infrastructuur.

Begin bij de tabel. Vul deze week de rijen die je kunt vullen en schrijf ook op welke leeg blijven, want een gat dat je benoemd hebt is een regel in je risicoregister en een gat dat je niet benoemd hebt is wat de toezichthouder vindt. Bij mij was rij d leeg tot die eerste Audit-run zeven pods van Docker Hub telde, en zeven is een getal dat ik kon opschrijven.

• DevOps
• Understanding