NIS2 artikel 21: wat de tien maatregelen concreet betekenen

Artikel 21 van de NIS2-richtlijn (EU-richtlijn 2022/2555) beschrijft de tien minimummaatregelen die essentiële en belangrijke entiteiten moeten nemen om hun netwerk- en informatiesystemen te beheersen. Het is geen technische lijst en geen audit-pakket. Het is een opsomming van governance- en risicofuncties die aantoonbaar in jullie organisatie moeten staan, met bestuurlijke verantwoordelijkheid voor wat erop gebeurt en wat eronder ligt. Dat is een ander register dan de meeste cybersecurity-checklists die in de Nederlandse praktijk circuleren, en het verklaart waarom een ISO 27001-certificering of een doorlopende pentest-cyclus artikel 21 niet automatisch afdekt.

Wat staat er in artikel 21 lid 2?

Artikel 21 lid 1 verplicht het bestuur tot het nemen van passende technische, operationele en organisatorische maatregelen, evenredig aan de risico's. Lid 2 maakt expliciet wat dat ten minste betekent. De tien maatregelen zijn EU-wettekst en hebben overal in de Unie dezelfde reikwijdte. Wat er per lidstaat verschilt is de toezichthouder en de handhavingspraktijk, niet de norm.

Hieronder de tien maatregelen, geparafraseerd in werktaal, met per maatregel wat er feitelijk geleverd moet worden om aantoonbaarheid te halen. Dit is wat jullie programma moet kunnen laten zien aan een onderzoeker, een auditor of een verzekeraar.

Beleid voor risicoanalyse en informatiebeveiliging. Een vastgesteld beleid dat beschrijft hoe risico's worden geïdentificeerd, geclassificeerd, geaccepteerd of gemitigeerd, met een bestuurlijk besluit op acceptatie. Niet een document op de plank, een vastgestelde lijn van risico naar maatregel waar het bestuur jaarlijks op tekent.

Incidentafhandeling. Een werkende incidentprocedure inclusief detectie, classificatie, escalatie, beheersing, herstel en evaluatie. Aantoonbaarheid hier is een log van afgehandelde incidenten en hun lessen, niet een policy-document met fasenamen.

Bedrijfscontinuïteit en crisismanagement. Continuïteitsplannen die getest zijn, met back-up en herstel die feitelijk werken bij verlies van systemen of locaties, gekoppeld aan een crisisorganisatie die buiten oefenrondes ook bij echte uitval functioneert. De test telt, niet de aanwezigheid van het plan.

Toeleveringsketen-beveiliging. Beheersing van risico's bij leveranciers en dienstverleners, inclusief afspraken over hun beveiliging en de verifieerbaarheid daarvan. Cloudleveranciers, beheerders, software-leveranciers, alles wat onder een verwerkers- of dienstverleningsrelatie valt en raakt aan jullie kritieke systemen. Contractuele clausules zonder periodieke verificatie tellen niet als beheersing.

Beveiliging bij aanschaf, ontwikkeling en onderhoud. Beveiliging als kwaliteitseigenschap in de hele lifecycle van systemen, inclusief het melden, beoordelen en herstellen van kwetsbaarheden. Dit raakt aan ontwikkel-, inkoop- en beheerprocessen, niet alleen aan een vulnerability scanner.

Effectiviteit van het cyberrisicobeheer. Beleid en procedures om te beoordelen of de getroffen maatregelen ook daadwerkelijk werken. Een interne audit of een review-cyclus die specifiek kijkt of de risico-aanpak het effect heeft dat ervan verwacht wordt, met bijsturing als bewijs.

Basis-cyberhygiëne en training. Operationele basismaatregelen (patching, configuratie-beheer, fundamentele toegangsmaatregelen) plus structurele bewustwording en training voor medewerkers en bestuurders. Eenmalige e-learning is geen training-functie, het is een datum in een register.

Cryptografie en versleuteling. Beleid en gebruik van cryptografie waar dat passend is, inclusief sleutelbeheer. De vraag is niet of er versleuteld wordt, maar of de sleutels onder beheer staan en of het beleid de keuze tussen wel en niet versleutelen onderbouwt.

Personeelsbeveiliging, toegang en assetbeheer. Beheersing van wie binnenkomt, wie wat mag zien of veranderen, en welke middelen waar staan. Identity- en accessmanagement, screening waar passend, en een actuele assetregister-lijn die aansluit op de risico-analyse uit maatregel 1.

Multi-factor-authenticatie, beveiligde communicatie en noodcommunicatie. Sterke authenticatie voor relevante systemen, beveiligde spraak-, video- en tekstcommunicatie, en een werkende noodvoorziening voor het geval primaire communicatiemiddelen uitvallen. Het laatste onderdeel wordt het vaakst overgeslagen en is in een incident het eerste dat blijkt te ontbreken.

Deze tien maatregelen zijn de minimum-set. Lid 3 voegt toe dat de implementatie evenredig moet zijn aan de specifieke risico's, de schaal van de entiteit en de waarschijnlijkheid en ernst van incidenten. Het Nederlandse Cybersecuritycentrum (NCSC) heeft op vergelijkbare onderwerpen handreikingen gepubliceerd die invulling geven aan onder meer continuïteit, toeleveringsketen en incidentafhandeling, en die mogen jullie naast jullie eigen analyse leggen. De norm is artikel 21, de invulling is de jouwe.

Waarom de tien maatregelen geen technische lijst zijn

Wie artikel 21 leest als een rij vinkjes, mist het onderwerp. De tien maatregelen zijn niet tien stukken techniek. Het zijn tien functies die in de organisatie moeten staan, met bestuurlijk eigenaarschap, periodieke toetsing en bewijs dat het werkt. Maatregel 1 is geen document, het is een besluitlijn. Maatregel 6 is geen audit-rapport, het is een gewoonte om te toetsen of de andere negen daadwerkelijk effect hebben. Maatregel 10 is geen MFA-roll-out, het is de afspraak dat communicatie blijft staan onder uitval.

Dat verklaart waarom een organisatie met een gerijpte ISO 27001-implementatie nog steeds gaten kan hebben op artikel 21. ISO 27001 is een managementsysteem voor informatiebeveiliging. NIS2 vraagt een breder spectrum, met expliciete continuïteits-, ketens-, communicatie- en bestuurlijke verantwoordelijkheidsfuncties. Veel van wat ISO levert telt mee, maar de overlap is gedeeltelijk en de aantoonbaarheidstest is anders. ENISA heeft hierover een implementatie-leidraad gepubliceerd waarin de relatie tussen ISO-controls en NIS2-maatregelen wordt uitgewerkt, en die laat ook zien waar de gaten zitten.

Het tweede misverstand is dat artikel 21 een one-shot is. De richtlijn maakt evenredigheid en periodieke beoordeling onderdeel van de norm. Dat betekent dat jullie programma niet alleen moet kunnen aantonen dat er maatregelen staan, maar ook dat ze worden onderhouden, getoetst en bijgesteld op basis van wat er in de eigen sector en het eigen landschap gebeurt. Een dreigingsbeeld dat een jaar oud is, voldoet niet aan de geest van lid 3.

Wat verandert artikel 21 voor jullie programma?

Praktisch verandert het de volgorde van denken. Een programma dat begint bij tools en eindigt bij een rapportage, voldoet niet. Een programma dat begint bij risico, eindigt bij bestuurlijke acceptatie en daartussen de tien functies operationeel houdt, voldoet wel. Dat lijkt een formele wijziging, maar het verschuift in de praktijk waar tijd en budget naartoe gaan.

Drie verschuivingen zien wij in opdrachten waar artikel 21 binnen komt rollen.

Een, van technische maatregelen naar bestuurlijke besluitlijnen. Risico-acceptatie wordt expliciet en getekend. Niet één keer in een projectplan, maar als terugkerend besluitmoment met een eigenaar. Dat raakt de relatie tussen jou als CISO en het bestuur direct: artikel 20 van de richtlijn legt bestuurlijke verantwoordelijkheid voor cyberrisico vast, en lid 2 van artikel 21 is wat dat bestuur in handen moet hebben om die verantwoordelijkheid te dragen.

Twee, van interne scope naar keten-scope. Maatregel 4 dwingt om verder te kijken dan de eigen perimeter. Veel organisaties hebben de eigen omgeving redelijk in beeld en de leveranciersketen niet. Dat is geen tekortkoming op één plek, dat is een ontbrekende functie. Een derde-partij-risicoproces met periodieke verificatie, gekoppeld aan inkoop en architectuur, is wat artikel 21 hier vraagt.

Drie, van eindrapportage naar doorlopende aantoonbaarheid. Toezichthouders vragen geen jaarverslag van wat er gebeurd is. Zij vragen wat er nu staat, wat het laatst getoetst is, en wat het bestuur ervan vindt. Dat verandert het ritme van het programma. Aantoonbaarheid is geen oplevermoment, het is een staat die je kunt laten zien op een willekeurig moment.

De vraag waar het meeste mis gaat, is niet welke maatregel ontbreekt. Het is welke maatregel formeel staat en feitelijk niet werkt. Een continuïteitsplan dat al twee jaar niet getest is, een leveranciersregister dat niet aansluit op de risico-analyse, een training-functie zonder bewijs dat het gedrag heeft veranderd, een crypto-beleid waarvan niemand weet wie de sleutels beheert. Op artikel 21 word je niet afgerekend op wat er ontbreekt op papier. Je wordt afgerekend op wat ontbreekt onder de papieren werkelijkheid.

Hoe je het programma erop schikt

Een artikel 21-implementatie benader je niet als een compliance-traject, maar als een programmatische verschuiving binnen de bestaande security-functie. Dat betekent: eerst de tien maatregelen naast jullie huidige programma leggen en per maatregel beantwoorden wat er staat, wat er ontbreekt, en wat er feitelijk werkt. Daarna prioriteren op risico en bestuurlijke positie, niet op gemak. De maatregel die het meest urgent is, is bijna nooit degene die het lekkerst implementeert.

De rolverdeling die hierbij hoort is helder. De CISO is verantwoordelijk voor de aantoonbaarheid van de tien functies. Operations dragen de uitvoering van de meeste technische en operationele componenten. De CFO of bestuurder draagt de besluitlast op risico-acceptatie en op de investering die de evenredigheidsclausule oplegt. Een artikel 21-implementatie zonder formele besluiten op bestuursniveau is geen artikel 21-implementatie, het is een interne IT-actie met een nieuwe naam.

De tien maatregelen geven jullie het frame. De invulling is van jullie. De toets is of het, op een willekeurige donderdag, in een gesprek met een toezichthouder, een verzekeraar of een ketenpartner, met droge ogen kan worden uitgelegd. Niet wat er staat, maar wat er werkt, en hoe je dat weet.