Een NIS2-evidence pack is de documentatie die uw organisatie gebruikt om te bewijzen dat cybersecurity-risicobeheermaatregelen onder Artikel 21 niet alleen zijn vastgelegd, maar ook zijn geïmplementeerd. Voor EU-MKB’s is het probleem versnipperd bewijs: één toegangsreview in een spreadsheet, één leverancierscheck bij procurement, één incidentprocedure bij IT, en geen totaaloverzicht dat deze registraties aan Artikel 21 koppelt.
Als u uw huidige positie nog niet heeft beoordeeld, begin dan met een NIS2-gap analyse voordat u bewijs verzamelt en weet welke Artikel 21-maatregelen rood of oranje zijn. Zo niet, begin dan eerst met de gap analyse en gebruik daarna dit artikel om het evidence pack op te bouwen.
Deze gids is algemene compliance guidance. Valideer juridische interpretaties altijd met uw juridisch adviseur of bevoegde autoriteit.
TL;DR
Een NIS2-evidence pack is een gecontroleerde set van gedateerde, toegewezen en beoordeelbare documenten die bewijst dat uw organisatie Artikel 21-maatregelen heeft geïmplementeerd. Een minimum viable pack moet alle 10 maatregelgebieden van Artikel 21 dekken met Tier 1-bewijs. Tier 2-bewijs maakt het pakket sterker voor een regulator review, due diligence door een enterprise-klant of assurance op bestuursniveau.
- Tier 1-bewijs toont aan dat de maatregel bestaat en is geïmplementeerd.
- Tier 2-bewijs toont aan dat de maatregel wordt getest, beoordeeld en onderhouden.
- Een ontbrekende bewijsfolder voor één Artikel 21-maatregel moet worden behandeld als een NIS2-documentatiegap.
Wat het NIS2-evidence pack is — en het minimum viable-principe
Een NIS2-evidence pack is een gestructureerde verzameling documenten, logs, goedkeuringen, testregistraties en reviewoutputs die zijn gekoppeld aan de cybersecurity-risicobeheermaatregelen uit Artikel 21.
“Minimum viable” betekent niet zwak. Het betekent de kleinste set bewijs waarmee u de volgende stelling kunt verdedigen: “Deze maatregel bestaat, heeft een eigenaar, is waar nodig goedgekeurd en is in de praktijk toegepast.”
Een ondertekend informatiebeveiligingsbeleid is beter bewijs dan tien niet-ondertekende conceptversies. Een gedateerde toegangsreview met een eigenaar is beter dan een screenshot van gebruikersaccounts zonder context. Een leveranciersbeoordeling met bevindingen en vervolgacties is beter dan een leverancierscontract waarin staat dat “securityverplichtingen van toepassing zijn”, maar dat nooit bewijst dat die zijn gecontroleerd.
Het minimum viable evidence pack moet drie regels volgen:
- Elke Artikel 21-maatregel heeft minimaal één Tier 1-bewijsbestand.
- Elk bestand heeft een datum, eigenaar, versie en reviewcyclus.
- Elk beleid wordt waar mogelijk ondersteund door minimaal één implementatieregistratie.
Wie uw NIS2-evidence pack moet hebben — en wat zij ermee doen
De primaire gebruiker is de CTO, CISO, IT-security lead of technische eigenaar die het evidence pack opbouwt. Deze persoon heeft een praktische kaart nodig: wat moet worden verzameld, waar moet het worden opgeslagen, hoe moet het worden gelabeld en welke gaps moeten als eerste worden gesloten.
De secundaire gebruiker is de compliance officer, het bestuurslid of de auditeigenaar die zich voorbereidt op een interactie met een toezichthouder. Deze persoon moet weten of de organisatie snel bewijs kan opleveren wanneer een bevoegde autoriteit, klant of intern bestuur daarom vraagt.
Uw evidence pack moet beschikbaar zijn voor minimaal vier interne groepen:
● IT/security: om technisch bewijs en controleregistraties te onderhouden.
● Compliance/legal: om regulatory mapping en documentretentie te controleren.
● Procurement: om bewijs van leverancierssecurity te onderhouden.
● Bestuursorgaan: om risicobesluiten te beoordelen, maatregelen goed te keuren en remediation te volgen.
Voor leveranciers aan grotere enterprises heeft het evidence pack ook een commerciële functie. Enterprise-klanten kunnen NIS2-bewijs opvragen tijdens vendor due diligence, vooral wanneer Artikel 21(2)(d) over supply chain security van toepassing is.
Bewijsvereisten per Artikel 21-maatregel: Tier 1 en Tier 2
De onderstaande tabel verdeelt bewijs in twee niveaus.
- Tier 1 is het minimum viable bewijs. Het toont aan dat een maatregel bestaat en minimaal één keer is toegepast.
- Tier 2 is aanbevolen bewijs. Het toont aan dat de maatregel wordt beoordeeld, getest, verbeterd en klaar is voor een strengere audit of review door een enterprise-klant.
De technische implementatierichtlijnen van ENISA uit 2025 gebruiken ook “voorbeelden van bewijs” om organisaties te helpen NIS2-vereisten te vertalen naar bewijsregistraties. Die voorbeelden zijn guidance, geen bindende juridische tekst, maar ze zijn nuttig bij het ontwerpen van een bewijsmodel.
Het NIS2 minimum viable evidence pack — Artikel 21-bewijstabel
| Artikel 21-gebied | Maatregel | Tier 1 minimaal bewijs | Tier 2 aanbevolen bewijs | Wat een toezichthouder of klant controleert |
|---|---|---|---|---|
| Artikel 21(2)(a) | Risicoanalyse en beleid voor beveiliging van informatiesystemen | Ondertekend informatiebeveiligingsbeleid. Gedateerde cyberrisicobeoordeling. Lijst met risico-eigenaren. | Risicobehandelplan. Registraties van acceptatie van restrisico. Jaarlijkse beleidsreview. | Het beleid heeft een eigenaar, reviewdatum en goedkeuring van het management. De risicobeoordeling is actueel en gekoppeld aan herstelacties. |
| Artikel 21(2)(b) | Incidentafhandeling | Incidentresponsprocedure. Criteria voor incidenternst. Bewijs van één tabletop-oefening of test. | Incidentlog, near-miss-log, post-incident reviews, Artikel 23-notificatietemplates. | De procedure benoemt wie beslist, wie rapporteert en hoe deadlines worden gevolgd. Gebruik voor deadlines en notificatiestappen de NIS2 Artikel 23-tijdlijn voor incidentrapportage. |
| Artikel 21(2)(c) | Bedrijfscontinuïteit en crisismanagement | Bedrijfscontinuïteitsplan voor kritieke diensten. Back-upbeleid. Recovery time objectives. | Business impact analysis. BCP-testresultaten. Crisiscommunicatieplan. Registratie van disaster recovery-test. | Bewijs dekt de systemen binnen NIS2-scope, niet alleen generieke IT. Testresultaten zijn gedateerd en toegewezen aan eigenaren. |
| Artikel 21(2)(d) | Supply chain security | Beleid voor leverancierssecuritybeoordeling. Leveranciersinventaris. Bewijs van minimaal één leveranciersreview. | Risicoclassificatie van leveranciers. Contractuele securityclausules. Jaarlijkse reviewregistratie voor kritieke leveranciers. | Leveranciersreviews zijn niet theoretisch. Minimaal één benoemde leverancier is beoordeeld, met bevindingen en vervolgacties. |
| Artikel 21(2)(e) | Security bij acquisitie, ontwikkeling en onderhoud | Procedure voor secure development of procurement. Securityvereisten in één recent project of aankoop. | Documentatie van secure software development lifecycle. Code review-registratie. Resultaat van vulnerability scan. Bewijs van remediation. | Security maakt deel uit van acquisitie of delivery en wordt niet pas na livegang toegevoegd. Bewijs laat zien dat één echt project het proces heeft gevolgd. |
| Artikel 21(2)(f) | Beleid om de effectiviteit van maatregelen te beoordelen | Procedure voor beoordeling van controle-effectiviteit. Bewijs van één afgeronde control review. | Intern auditrapport. Security KPI-dashboard. Rapportage over remediationstatus. | De organisatie kan laten zien of controles werken, niet alleen dat controles bestaan. Bevindingen hebben eigenaren en deadlines. |
| Artikel 21(2)(g) | Basis cyberhygiëne en cybersecuritytraining | Cyberhygiënebeleid. Registratie van securitytraining voor medewerkers. MFA- of wachtwoordrichtlijn. | Resultaten van phishingsimulatie. Rolgebaseerde training voor beheerders en developers. Dashboard voor trainingsvoltooiing. | Trainingsregistraties sluiten aan op de medewerkerslijst. Beheerders en rollen met hoger risico krijgen specifiekere training dan algemeen personeel. |
| Artikel 21(2)(h) | Cryptografie en encryptie | Cryptografie- of encryptiebeleid. Lijst van versleutelde systemen of datacategorieën. | Procedure voor sleutelbeheer. Certificaatinventaris. Encryptiereview. | Encryptiebeslissingen zijn per systeem of datatype gedocumenteerd. Eigenaarschap en vernieuwingsverantwoordelijkheden voor sleutels zijn duidelijk. |
| Artikel 21(2)(i) | Personeelssecurity, toegangscontrole en assetmanagement | Toegangscontrolebeleid. Assetinventaris. Joiner-mover-leaver-procedure. Bewijs van één toegangsreview. | Kwartaalregistraties van toegangsreviews. Log van privileged access. Beleid voor background screening waar wettelijk toegestaan en relevant. | Toegangsrechten sluiten aan op functierollen. Vertrekkers worden verwijderd. Privileged accounts hebben strikter reviewbewijs. |
| Artikel 21(2)(j) | Multi-factor authentication en beveiligde communicatie | MFA-beleid. MFA-dekkingsrapport voor kritieke systemen. Procedure voor beveiligde communicatie. | Uitzonderingenregister. Doorlopende beoordeling van authenticatie. Test van noodcommunicatie. | MFA wordt afgedwongen waar het risico dat vereist. Uitzonderingen zijn goedgekeurd, tijdgebonden en worden beoordeeld. |
Hoe u uw NIS2-evidence pack organiseert: een aanbevolen folderstructuur
Organiseer een NIS2-evidence pack per Artikel 21-maatregel, niet per afdeling. Elke folder moet gedateerd, toegewezen en versiegecontroleerd bewijs bevatten dat aantoont dat een controle bestaat, is toegepast en een reviewcyclus heeft.
Een evidence pack faalt wanneer het moeilijk te inspecteren is. Een toezichthouder, klant of bestuurslid zou niet door e-mailinboxen, Slack-threads, Jira-tickets, SharePoint-folders en screenshots moeten hoeven zoeken om uw controlestatus te begrijpen.
Organiseer het pakket per Artikel 21-maatregel, niet per afdeling. Auditors en klanten vragen: “Laat mij uw bewijs voor toegangscontrole zien” of “Laat mij bewijs van leverancierssecurity zien.” Ze vragen niet: “Laat mij zien wat IT, HR en procurement elk apart hebben opgeslagen.”
Gebruik deze folderstructuur als praktisch startpunt:
| Folder | Doel | Voorbeeldbestanden |
|---|---|---|
| 00_scope_and_entity_classification | Definieert welke entiteiten, diensten, systemen en locaties binnen scope vallen | NIS2-scopestatement, entiteitsclassificatie, lijst met kritieke diensten |
| 01_risk_analysis_and_security_policy | Koppelt aan Artikel 21(2)(a) | Securitybeleid, risicobeoordeling, risicobehandelplan |
| 02_incident_handling | Koppelt aan Artikel 21(2)(b) | Incidentresponsplan, severity matrix, registratie van tabletop-oefening |
| 03_business_continuity | Koppelt aan Artikel 21(2)(c) | BCP, back-upbeleid, RTO/RPO-register, BCP-testbewijs |
| 04_supply_chain_security | Koppelt aan Artikel 21(2)(d) | Leveranciersinventaris, leveranciersbeoordeling, contractuele securityclausules |
| 05_secure_development_and_acquisition | Koppelt aan Artikel 21(2)(e) | SSDLC-procedure, procurement security checklist, scanbewijs |
| 06_control_effectiveness | Koppelt aan Artikel 21(2)(f) | Interne control review, auditbevindingen, remediation tracker |
| 07_cyber_hygiene_and_training | Koppelt aan Artikel 21(2)(g) | Trainingsregistraties, cyberhygiënebeleid, phishingtestrapport |
| 08_cryptography_and_encryption | Koppelt aan Artikel 21(2)(h) | Encryptiebeleid, procedure voor sleutelbeheer, certificaatregister |
| 09_access_asset_and_personnel_security | Koppelt aan Artikel 21(2)(i) | Toegangsreview, assetinventaris, JML-procedure |
| 10_mfa_and_secure_communications | Koppelt aan Artikel 21(2)(j) | MFA-rapport, uitzonderingenregister, procedure voor beveiligde communicatie |
| 11_gap_analysis_and_remediation | Verbindt bewijsgaps met actie | Gaprapport, risicogerangschikt register, remediation roadmap |
Gebruik een naamgevingsconventie die inspectie eenvoudig maakt:
[Article21-area][document-type][owner][version][date]
Voorbeeld:
A21-2i_AccessReview_ITSecurity_v1_2026-05-20.pdf
Vermijd bestandsnamen zoals:
final_policy.pdf
new_new_access_review.xlsx
supplier_security_latest.docx
Zulke namen creëren extra werk tijdens een audit. Ze maken versiebeheer ook lastig.
Bouwt u uw NIS2-evidence pack en weet u niet zeker wat ontbreekt? Sunbytes kan uw huidige documentatie beoordelen ten opzichte van Artikel 21 Tier 1-bewijsvereisten, ontbrekende bewijsregistraties identificeren en het resultaat omzetten in een evidence target list die klaar is voor remediation. Bereid uw NIS2-evidence pack voor met Sunbytes.
Wat Nederlandse organisaties moeten voorbereiden voordat de Cyberbeveiligingswet in werking treedt
Voor Nederlandse organisaties heeft het evidence pack een extra praktische functie: aantoonbaarheid. In het Engels is de dichtstbijzijnde term demonstrability. Aantoonbaarheid betekent dat uw organisatie met bewijs kan laten zien dat aan een verplichting is voldaan. Voor NIS2-readiness betekent dit dat alleen een beleid niet genoeg is. De organisatie moet registraties kunnen opleveren die laten zien dat het beleid is goedgekeurd, toegepast, beoordeeld en bijgewerkt.
Nederland implementeert NIS2 via de Cyberbeveiligingswet. De NCTV stelt dat de Cyberbeveiligingswet de huidige Wbni zal vervangen zodra deze in werking treedt. De NCTV adviseert organisaties ook om niet te wachten, maar nu al te beginnen met voorbereiding op de tien zorgplichtmaatregelen.
Totdat de Cyberbeveiligingswet formeel in werking treedt, moeten Nederlandse organisaties deze periode behandelen als readiness-tijd: scope definiëren, controle-eigenaren toewijzen en bewijs voorbereiden voor de zorgplichtmaatregelen.
Voor Nederlandse MKB’s, essentiële entiteiten en belangrijke entiteiten betekent dit dat het evidence pack vier vragen moet beantwoorden voordat een toezichthouder of klant ze stelt:
- Welke Artikel 21-maatregelen zijn van toepassing op de systemen en diensten binnen scope?
- Welk bewijs toont aan dat elke maatregel is geïmplementeerd?
- Wie is eigenaar van elk bewijsbestand?
- Wanneer is het bewijs voor het laatst beoordeeld?
Wat NIS2-bewijs zwak of ongeldig maakt
Zwak bewijs heeft meestal één van vijf gebreken.
- Ten eerste heeft het geen datum. Een ongedateerd beleid kan bewijzen dat iemand ooit een document heeft opgesteld. Het bewijst niet dat de organisatie het heeft beoordeeld in de huidige risicocontext.
- Ten tweede heeft het geen eigenaar. Als er een leveranciersbeoordeling bestaat, maar geen functie eigenaar is van de vervolgacties, stopt het bewijs bij observatie. Het bewijst geen controle.
- Ten derde ontbreekt goedkeuring waar goedkeuring nodig is. Risicoacceptatie, goedkeuring van informatiebeveiligingsbeleid en governance-registraties op bestuursniveau horen niet alleen binnen IT te staan.
- Ten vierde is het niet gekoppeld aan Artikel 21. Een folder vol nuttige documenten creëert alsnog werk als niemand kan aangeven welke maatregel elk document ondersteunt.
- Ten vijfde bewijst het ontwerp, maar niet de implementatie. Een beleid zegt wat er zou moeten gebeuren. Een toegangsreview, testresultaat, incidentlog of leveranciersreview bewijst dat er iets is gebeurd.
Een minimum viable evidence pack moet deze vijf gebreken verwijderen voordat er meer documenten worden toegevoegd.
Hoe u het evidence pack opbouwt na uw gap analyse
Begin niet met het verzamelen van elk securitydocument dat uw bedrijf heeft. Begin met de output van de gap analyse. Een praktische volgorde werkt beter:
- Bevestig de NIS2-scope: entiteiten, diensten, systemen, locaties en leveranciers.
- Koppel elke Artikel 21-maatregel aan een verantwoordelijke eigenaar.
- Identificeer bestaand Tier 1-bewijs.
- Markeer ontbrekend of zwak bewijs als rood of oranje.
- Bouw de folderstructuur voordat u nieuwe bestanden verzamelt.
- Sluit Tier 1-gaps eerst.
- Voeg Tier 2-bewijs toe waar het risico richting klant, toezichthouder of bestuur hoger is.
- Stel reviewdata vast voor elk bewijsbestand.
Deze volgorde voorkomt een veelvoorkomende fout: een groot archief bouwen dat nog steeds de eerste auditvraag niet kan beantwoorden. Als Artikel 21(2)(i) bijvoorbeeld oranje is, verzamel dan niet eerst elk HR-beleid. Vraag om het toegangscontrolebeleid, de meest recente toegangsreview, de joiner-mover-leaver-procedure, de lijst met privileged access en bewijs dat minimaal één review tot een toegangsaanpassing heeft geleid. Dat geeft uw IT-security lead een verdedigbare startset.
Zodra Tier 1 compleet is, gaat u door naar Tier 2: kwartaalreviewritme, monitoring van privileged access, uitzonderingenregister en managementrapportage.
Hoe Sunbytes ondersteunt bij het voorbereiden van een NIS2-evidence pack
Sunbytes ondersteunt de voorbereiding van NIS2-evidence packs als onderdeel van Cybersecurity Compliance Readiness.
Het werk begint met evidence mapping: wat Artikel 21 vereist, welk bewijs al bestaat, wat ontbreekt en welke gaps het hoogste audit- of klantrisico creëren. De output is geen losse lijst met aanbevelingen. Het moet een gecontroleerde evidence target list zijn: documentnaam, Artikel 21-mapping, eigenaar, status, reviewdatum en volgende actie.
Voor bedrijven die ondersteuning nodig hebben na de documentatiereview, kan Sunbytes helpen ontbrekend bewijs te vertalen naar deliverywerk. Dat kan bestaan uit toegangsreviewregistraties, workflows voor leveranciersbeoordeling, documentatie voor secure development, incidentrespons-oefeningen of remediation tracking.
Waarom Sunbytes?
Sunbytes is een Nederlands technologiebedrijf met het hoofdkantoor in Nederland en een delivery hub in Vietnam. We zijn ISO 27001-gecertificeerd en engagements kunnen werken onder een ondertekende DPA met een gedocumenteerde audittrail. Al 15 jaar helpen we klanten wereldwijd Transform · Secure · Accelerate door strategie om te zetten in deliverywerk met security ingebouwd in het proces.
- CyberSecurity Solutions helpt bedrijven risico’s te verlagen zonder delivery te vertragen via praktische securitydiensten en compliance readiness. Voor het onderwerp van dit artikel betekent dit: huidige documentatie beoordelen ten opzichte van Artikel 21-bewijsvereisten, ontbrekende bewijsregistraties identificeren en teams helpen een evidence pack voor te bereiden dat gestructureerd, gedateerd, toegewezen en audit-ready is.
- Digital Transformation Solutions helpt teams digitale producten te bouwen en moderniseren met senior engineeringondersteuning voor custom development, QA/testing, onderhoud en support. Voor NIS2-evidence preparation is dit belangrijk wanneer ontbrekende controles echt deliverywerk moeten worden: secure development-registraties, testbewijs, systeemdocumentatie of remediationtaken.
- Accelerate Workforce Solutions helpt bedrijven capaciteit en capability op te schalen via recruitment en workforce support wanneer interne teams extra uitvoeringskracht nodig hebben. Voor NIS2-readiness kan dit de people side van remediation ondersteunen wanneer uw security-, compliance- of engineeringteams extra capaciteit nodig hebben om bewijsgaps op tijd te sluiten.
Neem contact op met Sunbytes over de voorbereiding van een NIS2-evidence pack.
FAQs
Een NIS2-evidence pack is een gestructureerde set documenten en registraties die bewijst dat uw organisatie NIS2-cybersecurity-risicobeheermaatregelen heeft geïmplementeerd. Voor Artikel 21 moet het bewijs koppelen aan elk maatregelgebied, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, supply chain security, secure development, controletesting, cyberhygiëne, encryptie, toegangscontrole en MFA.
Een minimum viable evidence pack dekt alle maatregelgebieden van Artikel 21 met Tier 1-bewijs. Dat betekent meestal een gedateerd beleid of procedure, een eigenaar en minimaal één implementatieregistratie per maatregel. Als één maatregel geen bewijs heeft, behandel dat dan als een documentatiegap.
Een minimum viable evidence pack dekt alle maatregelgebieden van Artikel 21 met Tier 1-bewijs. Dat betekent meestal een gedateerd beleid of procedure, een eigenaar en minimaal één implementatieregistratie per maatregel. Als één maatregel geen bewijs heeft, behandel dat dan als een documentatiegap.
Ja, maar deze moet zorgvuldig worden gekoppeld. ISO 27001-documentatie kan veel NIS2-bewijsgebieden ondersteunen, zoals risicomanagement, toegangscontrole, leverancierssecurity, incidentrespons en controle-effectiviteit. De gap zit vaak niet in het bestaan van documenten, maar in de vraag of ze zijn gekoppeld aan Artikel 21, actueel zijn, goedgekeurd zijn en makkelijk kunnen worden opgeleverd.
Het evidence pack moet incidentafhandelingsbewijs onder Artikel 21(2)(b) bevatten, maar gedetailleerd Artikel 23-rapportagebewijs hoort in het artikel of draaiboek voor incidentrapportage te staan. Gebruik voor rapportagedeadlines en notificatiefases de NIS2 Artikel 23-tijdlijn voor incidentrapportage.
Voor een organisatie die al een gap analyse heeft uitgevoerd en bestaande securitydocumentatie heeft, kan het 4–8 weken duren om een Tier 1-evidence pack samen te stellen en op te schonen. Vanaf nul beginnen kan 8–16 weken duren, omdat sommige bewijsstukken eerst via actie moeten worden gecreëerd, zoals leveranciersreviews, BCP-tests, toegangsreviews of incidentoefeningen.
Bewijs wordt zwak wanneer het ongedateerd is, niet ondertekend is waar goedkeuring nodig is, niet toegankelijk is, niet gekoppeld is aan Artikel 21 of niet wordt ondersteund door implementatieregistraties. Een beleid kan intentie aantonen. Een gedateerd testresultaat, toegangsreview, leveranciersbeoordeling of registratie van een incidentoefening toont praktijk aan.
Voor de Nederlandse versie: ja. “Aantoonbaarheid” is de praktische standaard: uw organisatie moet compliance kunnen aantonen met documenten en registraties. Definieer het in de Engelse versie één keer als “demonstrability” en houd het hoofdartikel daarna gericht op Artikel 21-bewijs.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
