Onder de NIS2-richtlijn is NIS2 Article 21 het punt waarop “we nemen cybersecurity serieus” verandert in “bewijs het maar”. NIS2 Article 21 beschrijft de minimale cybersecurity-risicobeheersmaatregelen die organisaties die onder NIS2 vallen moeten implementeren én aantoonbaar in de praktijk moeten laten werken.
EU-lidstaten kunnen verschillen in hoe zij NIS2 vertalen naar nationale wetgeving, maar de bedoeling van NIS2 Article 21 is overal gelijk: risicogebaseerde, proportionele maatregelen — ondersteund door operationeel bewijs.
Deze gids vertaalt NIS2 Article 21 naar praktische acties, concrete voorbeelden van bewijs en een Minimum Viable Evidence Pack dat mkb-organisaties kunnen opbouwen zonder onnodige complexiteit of bureaucratie.
TL;DR
NIS2 Article 21 vereist dat organisaties die onder de richtlijn vallen: passende en proportionele cybersecurity-risicobeheersmaatregelen implementeren; en kunnen aantonen dat deze maatregelen daadwerkelijk functioneren in de praktijk.
NIS2 Article 21 omvat 10 verplichte domeinen, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, supply-chain security, secure development, testing, training, cryptografie, toegangsbeheer en MFA/secure communicatie. Readiness = eigenaarschap + bewijsset + continue verbetering
Wil je hierbij gestructureerde ondersteuning, dan helpt Sunbytes Compliance Readiness je bij het opbouwen van een evidence pack en een geprioriteerde remediatie-roadmap, volledig afgestemd op NIS2 Article 21.
Wat vereist NIS2 Article 21?
NIS2 Article 21 vereist “appropriate and proportionate” cybersecurity-risicobeheersmaatregelen én het vermogen om aan te tonen dat deze maatregelen in de praktijk werken.
In gewone taal betekent dit dat cybersecurity wordt beheerd als een herhaalbaar en bestuurbaar proces:
- Risico’s worden geïdentificeerd en geprioriteerd
- Beheersmaatregelen zijn geïmplementeerd en toegewezen aan duidelijke eigenaren
- Beheersmaatregelen worden gemonitord en periodiek herzien
- Beslissingen en afwegingen worden vastgelegd
- Bewijs kan snel worden overlegd wanneer daarom wordt gevraagd
De 3 principes achter NIS2 Article 21 (zodat je niet overbouwt)
NIS2 Article 21 is bewust outcome-gedreven opgesteld. In plaats van specifieke technologieën of frameworks voor te schrijven, beschrijft het hoe organisaties geacht worden te denken over, omgaan met en bewijs leveren voor cybersecurity-risico’s.
Drie principes liggen ten grondslag aan elke maatregel binnen NIS2 Article 21. Inzicht in deze principes voorkomt onnodige over-engineering.
Risicogebaseerd, niet checklist-gedreven
NIS2 Article 21 verwacht beslissingen die zijn gebaseerd op daadwerkelijke dreigingen en bedrijfsimpact, niet op generieke templates. Je moet kunnen uitleggen waarom je een bepaald control-niveau hebt gekozen — of waarom juist niet.
Cybersecurity strekt zich uit tot de supply chain
Je bent verantwoordelijk voor risico’s die worden geïntroduceerd door leveranciers en dienstverleners, vooral wanneer zij kritieke diensten ondersteunen. Dit is een punt waarop mkb-organisaties vaak onverwacht tekortschieten.
Bewijs is belangrijker dan intentie
Toezichthouders en afnemers vragen niet wat je van plan was — ze vragen wat je kunt aantonen: logs, tickets, testresultaten, trainingsregistraties en review-notities.
Wat zijn de 10 verplichte cybersecurity-maatregelen binnen NIS2 Article 21?
NIS2 Article 21 definieert tien minimale domeinen die je moet adresseren. Het doel is geen perfecte volwassenheid, maar een verdedigbare basis die is toegewezen, gedocumenteerd en operationeel.
| Measure area | What “good enough” looks like (SME baseline) | Evidence examples buyers/regulators verify |
|---|---|---|
| 1) Risicoanalyse & security policies | Toprisico’s zijn gedocumenteerd met afgesproken behandeling | Risicoregister, goedgekeurde policies, asset-inventaris |
| 2) Incidentafhandeling | Je kunt incidenten detecteren, erop reageren en ervan leren | IR-plan, escalatiematrix, incidenttickets, PIR-template |
| 3) Business continuity & crisismanagement | Je kunt diensten herstellen | Back-upbeleid, restore-tests, RTO/RPO, DR-runbook |
| 4) Supply-chain security | Je kent je kritieke leveranciers en verwachtingen | Leverancierslijst, security-clausules, review-checklists |
| 5) Secure acquisition, development & maintenance | Security is ingebed in changes en patching | SDLC-gates, change-records, patch-SLA’s |
| 6) Effectiviteitstesten | Controls worden getest en verbeterd | Scan/pentest-samenvattingen, KPI-dashboards |
| 7) Cyberhygiëne & training | Medewerkers kennen basis cybergedrag | Trainingsmateriaal, deelname-registraties |
| 8) Cryptografie / encryptie | Data is beschermd waar het ertoe doet | Encryptiebeleid, TLS-instellingen, key-aanpak |
| 9) Toegangsbeheer, asset management & HR-security | Toegang wordt lifecycle-gecontroleerd | JML-processen, access reviews, asset-inventaris |
| 10) MFA & secure communicatie | MFA op kritieke toegang en fallback-communicatie | MFA-configuraties, admin hardening, emergency drills |
Per maatregel: wat het betekent en welk bewijs je moet voorbereiden
Risicoanalyse & beveiligingsbeleid
Je moet cybersecurity-risico’s voor kritieke systemen en diensten identificeren en vastleggen hoe deze worden beheerd. Het bewijs moet aantonen dat risico’s worden geprioriteerd en herzien, niet alleen beschreven.
Voorbeelden van bewijs: risicoanalyse-rapport, risicoregister, beveiligingsbeleid (goedgekeurd), inventaris van assets/diensten, review-notities.
Incidentafhandeling
Je hebt een werkbaar incident response-proces nodig: rollen, escalatie, acties en leerloops. Toezichthouders kijken vooral naar paraatheid: kan je team dit daadwerkelijk uitvoeren?
Voorbeelden van bewijs: incident response-plan, escalatiematrix, incidentlog/tickets, template voor post-incident review, notities van tabletop-oefeningen.
Bedrijfscontinuïteit & crisismanagement
Je moet de beschikbaarheid van diensten kunnen behouden tijdens en na incidenten. Back-ups die “draaien” zijn niet voldoende — restore-testing is de geloofwaardigheidsindicator.
Voorbeelden van bewijs: back-upbeleid, resultaten van restore-tests, RTO/RPO-definities, disaster recovery-runbook, crisiscommunicatieplan.
Supply chain-beveiliging
Je moet risico’s van derde partijen beheersen. Voor mkb-organisaties gaat een eenvoudige leveranciersinventaris + criticaliteitsclassificatie + basale verwachtingen al ver.
Voorbeelden van bewijs: leverancierslijst met criticaliteit, security-addendum/-clausules, checklist voor leveranciersreviews, procedure voor incidentcommunicatie.
Veilige systeeminkoop, -ontwikkeling en -onderhoud
Security moet onderdeel zijn van hoe je systemen inkoopt, bouwt, wijzigt en patcht — niet iets wat je er later aan vastplakt. Mkb-organisaties hebben geen zware bureaucratie nodig, maar wel herhaalbare gates.
Voorbeelden van bewijs: notities over secure SDLC, change management-registraties, patchbeleid + SLA’s, proces voor vulnerability intake/disclosure.
Effectiviteitstesten van cybersecuritymaatregelen
Je moet verifiëren dat beheersmaatregelen daadwerkelijk werken. De nadruk ligt op verbetering in de tijd, niet op continu overal penetratietesten uitvoeren.
Voorbeelden van bewijs: samenvattingen van scans/pentests, interne review-notities, KPI-dashboard (MFA-dekking, patch-SLA, restore-tests), actietracker.
Cyberhygiëne en medewerkerstraining
Awareness moet consistent en rolgericht zijn. Het bewijs is eenvoudig: materiaal + deelname + onboarding/offboarding-stappen.
Voorbeelden van bewijs: trainingsmateriaal, completion-logs, phishing-simulatie-rapport (optioneel), JML-checklist.
Cryptografie en encryptie
Waar passend moet cryptografie worden ingezet om vertrouwelijkheid en integriteit te beschermen — met name voor gevoelige data en admin-verkeer.
Voorbeelden van bewijs: encryptiebeleid, TLS-instellingen, bewijs van encryptie-at-rest, key management-aanpak (op hoofdlijnen).
Toegangsbeheer, assetmanagement en HR-beveiliging
Dit gaat over lifecycle-beheer: least privilege + joiner/mover/leaver-discipline + zichtbaarheid van assets.
Voorbeelden van bewijs: logs van toegangsreviews, JML-proces, asset-inventaris, baseline endpoint-configuraties.
Multi-factor authenticatie en veilige communicatie
MFA op kritieke systemen en admin-toegang is een basisverwachting. Daarnaast moeten veilige kanalen en noodcommunicatie zijn vastgelegd.
Voorbeelden van bewijs: screenshots/configuraties van MFA-afdwinging, admin hardening, break-glass-controls, notities van emergency channel-oefeningen.
“Minimum Viable Evidence Pack” voor mkb-organisaties onder NIS2 Article 21
Voor mkb-organisaties draait compliance met NIS2 Article 21 om het kunnen aantonen van beheersing op een geloofwaardige en proportionele manier.
Een Minimum Viable Evidence Pack is een gerichte set van policies, registraties en technisch bewijs die gezamenlijk laten zien dat toezichthouders dat je de vereiste cybersecurity-risicobeheersmaatregelen hebt geïmplementeerd, operationeel hebt gemaakt en periodiek hebt beoordeeld.
Governance & risico
Cybersecurity Risk Assessment Report
Identificeert de meest relevante cybersecurity-risico’s voor systemen en diensten en prioriteert deze op basis van impact en waarschijnlijkheid. Laat zien dat securitybeslissingen risicogebaseerd zijn en niet generiek.
Informatiebeveiligingsbeleid (door management goedgekeurd)
Definieert beveiligingsdoelstellingen, rollen en principes, met expliciete goedkeuring door het management. Toont aansprakelijkheid en governance op directieniveau aan.
Risicobehandelings- of remediatieplan
Verbindt geïdentificeerde risico’s aan mitigerende maatregelen, eigenaren en tijdslijnen. Laat zien dat risico’s actief worden beheerd en niet alleen zijn vastgelegd.
Asset-inventaris (systemen en data)
Overzicht van kritieke systemen, diensten en datatypen. Vormt de basis voor toegangsbeheer, risicoanalyse en incident response.
Incident- en continuïteitsgereedheid
Incident Response Plan (afgestemd op NIS2-meldplicht)
Beschrijft hoe incidenten worden gedetecteerd, geëscaleerd, beheerd en opgelost, inclusief beslissingsrollen en meldcriteria.
Incidentlog of Incident Report-template
Biedt een gestructureerde manier om incidenten, root causes en geleerde lessen vast te leggen. Kan ook records bevatten van tests of tabletop-oefeningen.
Bedrijfscontinuïteits- en back-upbewijs
Toont aan dat back-ups bestaan en daadwerkelijk kunnen worden hersteld. Bestaat doorgaans uit back-upbeleid en recente restore-testresultaten.
Technische en operationele beheersmaatregelen
Bewijs van toegangsbeheer en MFA
Toont aan dat toegang tot kritieke systemen is beperkt en beschermd met multi-factor authenticatie. Screenshots of configuratie-exports zijn voor mkb-organisaties doorgaans voldoende.
Patch- en vulnerabilitymanagement-registraties
Laat zien hoe kwetsbaarheden en patches worden geïdentificeerd, geprioriteerd en toegepast. Bevat policies en voorbeeldlogs of scanresultaten.
Bewijs van secure configuratie of hardening
Documenteert baseline-beveiligingsconfiguraties voor systemen of endpoints. Tool-output of screenshots zijn acceptabel voor mkb-organisaties.
Bewijs van encryptie of databescherming
Legt uit waar encryptie wordt toegepast (in transit en/of at rest) en waarom. Ondersteund door beleid en configuratievoorbeelden.
Samenvatting van penetratietest of security assessment
Levert bewijs dat securitymaatregelen op effectiviteit worden getest. Een samenvatting op managementniveau is voldoende.
Mensen & awareness
Trainingsmateriaal voor cybersecurity-awareness
Presentaties, video’s of leerplatform-content tonen aan dat medewerkers worden geïnstrueerd over basale cyberrisico’s en verwacht gedrag.
Registraties van trainingsdeelname
Overzicht van deelnemers en afrondingsdata toont aan dat training daadwerkelijk wordt gegeven en gevolgd, met vastgelegde data en deelnemers.
Joiner / Mover / Leaver-toegangschecklist
Bevestigt dat toegangsrechten consistent worden toegekend, aangepast en ingetrokken gedurende de volledige employee lifecycle.
Als je wilt begrijpen hoe deze evidence-vereisten van NIS2 Article 21 passen binnen je bredere NIS2-verplichtingen, lees dan onze NIS2 Compliance Readiness voor EU-mkb: Essential Guide + Practical Checklist voor een gestructureerd, end-to-end overzicht van de vervolgstappen.
Drie veelvoorkomende hiaten in NIS2 Article 21 Readiness
Beheersmaatregelen bestaan, maar zijn niet gedocumenteerd
Cybersecuritymaatregelen zijn vaak informeel geïmplementeerd: MFA is ingeschakeld, back-ups draaien, toegang is beperkt — maar niets staat op papier. Zonder documentatie zijn deze maatregelen moeilijk uit te leggen, te beoordelen of te verdedigen. Toezichthouders beoordelen wat aantoonbaar is, niet wat verondersteld wordt te bestaan.
Leveranciersrisico’s worden niet beoordeeld
Veel organisaties zijn sterk afhankelijk van derde partijen, maar hebben onvoldoende inzicht in welke leveranciers kritisch zijn of hoe hun risico’s worden beheerd. Contracten bevatten vaak geen expliciete security-afspraken en incidentscenario’s met leveranciers worden zelden meegenomen in plannen of oefeningen. Onder NIS2 Article 21 is dit een duidelijk en terugkerend zwak punt.
Geen bewijs van effectiviteitstesten
Zelfs wanneer beheersmaatregelen bestaan en zijn vastgelegd, kunnen organisaties vaak niet aantonen dat deze daadwerkelijk werken. Back-ups worden niet getest, incidentplannen niet geoefend en kwetsbaarheden niet systematisch beoordeeld. NIS2 Article 21 verwacht bewijs van testen, review en verbetering — niet statische controls die alleen op papier bestaan.
Hoe je je voorbereidt op NIS2 Article 21 zonder over-engineering
NIS2 Article 21 verwacht niet dat mkb-organisaties enterprise-grade securityprogramma’s opzetten. De richtlijn vereist expliciet passende en proportionele maatregelen, waarbij rekening wordt gehouden met risicoblootstelling, omvang en implementatiekosten.
De uitdaging voor de meeste organisaties is hoe je precies genoeg doet — en niet meer — terwijl je wel verdedigbaar blijft.
Een praktische manier om dit aan te pakken is door NIS2 Article 21 per vereiste maatregel te vertalen naar vier eenvoudige vragen:
- Wat moeten we implementeren?
- Hoe tonen we dit aan?
- Wie is eigenaar?
- Hoeveel inspanning kost dit realistisch gezien?
Een praktische mapping: maatregel → bewijs → eigenaar → inspanning
Deze mapping vertaalt NIS2 Article 21 van juridische tekst naar een operationele roadmap.
- Maatregel: Wat NIS2 Article 21(2)(a)–(j) expliciet vereist dat je adresseert.
- Bewijs: Wat toezichthouders, auditors of klanten redelijkerwijs kunnen verifiëren om vast te stellen dat de maatregel is geïmplementeerd en operationeel is.
- Eigenaar: De persoon die verantwoordelijk is voor het onderhouden van de maatregel en het bijbehorende bewijs. In mkb-organisaties is dit vaak één persoon met meerdere rollen (bijvoorbeeld een IT Manager die ook optreedt als Security Lead).
- Typische inspanning: Een realistische inschatting van het werk dat nodig is om een verdedigbare basis te bereiken — geen theoretische volwassenheid.
Deze aanpak zorgt ervoor dat elke vereiste een duidelijk doel, aantoonbaar bewijs en een verantwoordelijke eigenaar heeft, en voorkomt dubbel werk en onnodige complexiteit.
Begrip van de inspanningsschaal (realiteitscheck voor mkb)
Om over-engineering te voorkomen, moet inspanning consistent worden beoordeeld:
- S (Small): 1–5 werkdagen
Voornamelijk documentatie, lichte configuratie of het formaliseren van wat al bestaat. - M (Medium): 2–6 weken
Procesdefinitie, verbeteringen in tooling, opzetten van bewijs en basis-testing. - L (Large): 6–12+ weken
Afstemming tussen teams, architecturale wijzigingen, nieuwe tooling of herhaalde testcycli.
Voor de meeste mkb-organisaties vallen de meeste maatregelen uit NIS2 Article 21, wanneer pragmatisch benaderd, in Small of Medium inspanning.
Hoe Sunbytes NIS2 Article 21 Compliance Readiness ondersteunt
Sunbytes hanteert een evidence-first, toezichthouder-aligned aanpak voor NIS2 Article 21 readiness. Wij richten ons op wat autoriteiten, auditors en klanten daadwerkelijk vragen: duidelijke risico-onderbouwing, operationeel bewijs en realistische prioritering. Onze ervaring met Europese mkb-organisaties stelt ons in staat om juridische vereisten te vertalen naar praktische, verdedigbare uitkomsten.
Heb je wel policies, maar kun je niet snel bewijs leveren (logs, tickets, trainingsregistraties, restore-tests), dan richt een Sunbytes Compliance Readiness zich op het opbouwen van een evidence pack en een geprioriteerde remediatie-roadmap, volledig afgestemd op NIS2 Article 21. Plan een vrijblijvend gesprek om een Compliance Readiness-traject te bespreken.
FAQs
Niet per se “perfect”, maar je moet wel streven naar een basisniveau voor alle 10 maatregelgebieden, omdat NIS2 Article 21(2) deze als minimale vereisten benoemt.
Een praktische aanpak voor mkb-organisaties:
-
Week 1–2: eigenaren vaststellen + minimale policies + mappenstructuur voor bewijs
-
Week 3–6: implementeren van de hoogste-risico-maatregelen (MFA, back-ups/restore-tests, vulnerability handling)
-
Doorlopend: volwassenheid verhogen met meetbare KPI’s en periodieke reviews
NIS2 benoemt expliciet dat maatregelen “appropriate and proportionate” moeten zijn en noemt factoren zoals stand van de techniek, relevante standaarden, implementatiekosten, risicoblootstelling, omvang en potentiële impact van incidenten.
In de praktijk betekent “proportionate” meestal:
-
Je kunt onderbouwen waarom een maatregel op een bepaalde manier is ingericht (risicogebaseerd)
-
Je hebt bewijs dat de maatregel operationeel is (niet alleen een policy-PDF)
-
Je prioriteert maatregelen die waarschijnlijke en/of impactvolle risico’s reduceren
ISO 27001 helpt sterk, maar NIS2-readiness hangt nog steeds af van scope, specifieke verplichtingen en bewijs van operationele werking. NIS2 legt daarnaast extra nadruk op incidentmeldtermijnen (Article 23) en supply-chain practices. Zie ISO 27001 als een stevige basis — en valideer daarna de resterende hiaten tegen NIS2 Article 21/23 en nationale implementatieregels.
Een policy beschrijft intentie. Bewijs toont aan dat een maatregel echt en herhaalbaar is.
Voorbeeld: “Wij maken back-ups” (policy) versus restore-testresultaten + RTO/RPO + runbook + de laatste drie testtickets (bewijs). Evidence-readiness is waar procurement-teams en auditors doorgaans als eerste naar vragen.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
