Er zijn twee soorten organisaties. De eerste reageert op nieuwe regels met een reflex:"We hebben een nieuw document nodig". De tweede reageert met een vraag:"Welke vaardigheid hebben we eigenlijk nodig en hoe tonen we die aan?"
Dit artikel gaat over hoe kleine en middelgrote ondernemingen (MKB) kunnen overstappen van categorie 1 naar categorie 2, zonder te verdrinken in mappen, sjablonen en eindeloze documentatie die digitaal stof verzamelt. En ja: we praten over GDPR en NIS2/de cybersecuritywet, maar op een manier die niet de illusie wekt dat ze juridisch "door elkaar gehaald" kunnen worden, iets wat ik helaas te vaak ben tegengekomen. Dat kan niet. En dat moeten we ook niet proberen. Wat wel kan, is iets praktischers (en innovatievers): dezelfde werkelijkheid, besturing en bewijslast hergebruiken en elk regelgevend kader zijn eigen juridische conclusies laten trekken uit dezelfde feiten.
Het verschil is tussen:
"Een document dat alles pretendeert te dekken" (papieren tijger in wolvenkleren), en
"Een bewijsstructuur die alle documenten korter, duidelijker en betrouwbaarder maakt vanuit een allrisk-perspectief."
Waarom meer wetgeving vaak minder veiligheid betekent
De NIS2-richtlijn/cybersecuritywet is risicogebaseerd en proportioneel. Het zegt duidelijk dat de eisen proportioneel moeten zijn en dat disproportionele financiële en administratieve lasten vermeden moeten worden (Europees Parlement en Raad van de Europese Unie, 2022, overweging 81). Het is dus niet bedoeld om "meer mappen te creëren", maar om "betere weerbaarheid op te bouwen". Maar aangezien Zweden kampioen bureaucratie en documentatie zijn, bestaan hier risico's die aangepakt moeten worden.
In de Zweedse context heeft de regering een nieuwe cybersecuritywet voorgesteld ter implementatie van NIS2, met eisen voor maatregelen om netwerk- en informatiesystemen te beschermen en significante incidenten te melden (Regering, 2025/26). Het probleem is dat organisaties dit vaak benaderen met een documentatiestrategie die te vergelijken is met een metafoor:
Men bouwt een nieuwe verdieping bovenop een huis met scheuren en hoopt dat niemand de fundering bekijkt.
De GDPR heeft ons al geleerd dat documentatie geen "extra" is, maar een onderdeel van naleving. Dat had het in ieder geval moeten doen. De GDPR vereist dat datalekken worden gedocumenteerd zodat toezichthouders naleving kunnen verifiëren (Europees Parlement en Raad van de Europese Unie, 2016, art. 33(5)). En veiligheid in de GDPR gaat expliciet over veerkracht, herstelvermogen en testen (Europees Parlement en Raad van de Europese Unie, 2016, art. 32(1)(b)–(d)).
Dus wanneer NIS2/de cybersecuritywet erbij komt, is het risico dat men dubbele versies van hetzelfde betoog maakt, maar dan in twee verschillende sjablonen. En plotseling zijn het de documenten die alle energie opslokken, niet de cyberhygiëne in de praktijk.
Hier wil ik het tij voor u als lezer keren.
De eenvoudige weg: een bewijsstructuur, meerdere perspectieven
Dit is mijn stelling. GDPR en NIS2/de cybersecuritywet zijn twee aparte regelgevingen die voor organisaties vaak voor hoofdbrekens zorgen, maar die vaak gedeeltelijk overlappende vragen stellen over vaardigheden. Bouw daarom een gemeenschappelijke bewijsstructuur die deze vragen beantwoordt, en geef elk regelgevend kader daarna zijn eigen "omslag" in plaats van talloze bureaucratische documentatieprocessen.
Het gaat eigenlijk om drie bouwstenen.
1) Assurance Pack: "toon hoe u heeft gedacht" met bewijs, niet met proza
Noem het "Assurance Pack", "Bewijsstructuur" of "Waarheidsmap" (de laatste kan voor discussie zorgen in organisaties met sterke meningen, maar is duidelijk). Het punt is dat u stopt met het schrijven van lange documenten die alles proberen te beschrijven, en in plaats daarvan een gestructureerde verzameling maakt van:
besluiten(wat u prioriteert en waarom, mogelijk gebaseerd op kwetsbaarheidsanalyses),
vaardigheden(wat u daadwerkelijk kunt doen),
bewijs(hoe u aantoont dat het klopt).
Dit is geen onzin. De technische richtlijn van ENISA (niet-bindend, maar degelijk) is precies op dit idee gebaseerd: het geeft "voorbeelden van bewijs" en laat zien dat één bewijsstuk meerdere eisen kan ondersteunen (ENISA, 2025). Ook benadrukt het dat het een "zeer strikte" toezichtsmethode zou zijn om alle vermelde bewijzen te eisen, en dat organisaties alternatief bewijs kunnen gebruiken (ENISA, 2025).
Dit is volgens mij uw sleutel tot innovatie:
Bewijs is herbruikbaar. Documentteksten zelden.
En hier is een belangrijke, vaak gemiste juridische link: GDPR vereist dat verwerkers "voldoende garanties" bieden en dat de verwerking wordt geregeld door contracten met specifieke eisen (Europees Parlement en Raad van de Europese Unie, 2016, art. 28(1), 28(3)). Wat is in de praktijk een 'garantie'? Iets dat zowel contractueel vastgelegd als onderbouwd kan worden door besturing en bewijs (bijvoorbeeld tests, controles en audits). Dit is vaak waar discussies over overdracht en dergelijke misgaan. Wat u veronderstelt en wat u kunt garanderen met bewijs. Het Assurance Pack wordt dus de motor die zowel GDPR- als NIS2-vragen kan beantwoorden zonder telkens nieuwe documenten te hoeven maken.
2) SSA: plaats beveiliging waar het hoort, in een algemeen beveiligings- en veerkrachtschema
Om documentatie te vereenvoudigen en tegelijkertijd de daadwerkelijke weerbaarheid te verhogen, helpt het om cyberhygiëne een eigen, duidelijke plek te geven binnen de contractstructuur: een plek waar eisen voor beveiliging en veerkracht consequent worden geformuleerd – ongeacht het type leveranciersrelatie.
Dit is waar een SSA (Supplier Security & Resilience Schedule) in beeld komt. Zie SSA als een "contracttaal" voor de vaardigheden die er in het dagelijks leven toe doen: incidentmanagement, herstel en continuïteit, kwetsbaarheidsbeheer, toegangscontrole, logging en traceerbaarheid, en beheer van de leveranciersketen. NIS2 wijst juist dit soort risicobeheersmaatregelen en het supply chain-perspectief aan als kernpunten (Europees Parlement en Raad van de Europese Unie, 2022, art. 21).
De SSA is geen magische "compliance-knop". Het is iets nuttigers: een gestandaardiseerd kader voor eisen en bewijs dat hergebruikt kan worden bij aanbestedingen, leveranciersmonitoring en interne besturing. Om het proportioneel te houden, kan de SSA in niveaus worden verdeeld: een basislijn voor iedereen en een uitgebreidere versie voor kritische leveranciers. Zo hoeft u niet steeds dezelfde eisen in een nieuwe vorm uit te vinden als iemand vraagt "hoe waarborgt u continuïteit?" of "hoe weet u dat de leveranciersketen betrouwbaar is?". En het sluit mooi aan op uw Assurance Pack: SSA beschrijft wat waar moet zijn, Assurance Pack toont dat het zo is.
Hier ontstaat vaak de echte vereenvoudiging: in plaats van meer documenten krijgt u een duidelijke basislijn die hergebruikt en bijgewerkt kan worden zonder voor elke nieuwe wetgeving nieuwe mappen te maken.
3) Maak documentatie tot een bijproduct van de operatie
Dit is het moeilijkste om te doen, maar levert het meeste op.
Als documentatie een "extra project" vereist, wordt het altijd een papieren draak. Maar als documentatie de uitstoot is van hoe u werkt, wordt het onderdeel van het cyberhygiëne-DNA. GDPR artikel 32 geeft u zelfs een uitstekend model voor wat "operationeel bewijs" moet zijn: veerkracht, herstel, testen (Europees Parlement en Raad van de Europese Unie, 2016, art. 32(1)).
NIS2 artikel 21 beschrijft een breed scala aan risicobeheersmaatregelen (incidentbeheer, continuïteit, supply chain, veilige ontwikkeling, enz.) en het gaat om hetzelfde type "vaardigheden in operatie" (Europees Parlement en Raad van de Europese Unie, 2022, art. 21).
Dus in plaats van te schrijven "we hebben een backup", creëert u ritmes die bewijs genereren:
hersteltests worden vastgelegd in protocollen
incidentoefeningen worden aangetoond met leerpunten en verbeterplannen
wijzigingen in leveranciers worden gekoppeld aan risico- en kwetsbaarheidsbeoordelingen die leiden tot besluiten
kwetsbaarheidsbeheer creëert een overzichtelijk ticketproces
Dit is innovatie in de praktijk: naleving als bijeffect, niet als hoofddoel.
Fictief voorbeeld: "Pärmar & Panik AB" vindt een uitweg uit PDF-Jenga
Pärmar & Panik AB (P&P) is een middelgroot Zweeds IT-bedrijf dat managed IT levert aan kleine gemeenten en industriële bedrijven: Microsoft 365, identiteit, clientbeheer, EDR, backup en "brandweer bij calamiteiten". Ze zijn dus niet alleen leverancier, maar in feite het cyberzenuwstelsel van hun klanten.
Wanneer de cybersecuritywet/NIS2 nadert, gebeuren er drie dingen tegelijk (alsof het een klassieke Zweedse thriller is, maar dan met meer Teams-vergaderingen):
Klanten stellen nieuwe vragen bij aanbestedingen – niet om lastig te zijn, maar omdat hun eigen risico- en beheerseisen strenger worden: "Hoe werkt u aan incidentmanagement?", "Hoe snel kunt u herstellen?", "Hoe beheert u uw onderaannemers?", "Wat gebeurt er als uw EDR-leverancier wordt gecompromitteerd?"
De leveranciersketen is stilletjes gegroeid. P&P heeft meer afhankelijkheden dan ze zich herinneren: cloudplatform, remote tools, logbeheer, backup-leverancier, identiteitdiensten, ticketing, onderaannemers bij grote incidenten. Elk vormt samen een keten waarbij één schakel een heel verhaal kan worden.
Hun documentatie is "niet fout"… maar onhandelbaar. Ze hebben beleidsdocumenten, contracten, bijlagen. Maar als ze de vraag krijgen: "toon hoe u heeft gedacht", is het antwoord vaak: "Wacht, ik zoek de juiste versie."
Hier komt de ommekeer. P&P realiseert zich dat ze een keuze hebben:
Ofwel bouwen ze de Zweedse documentatiedraak: een nieuwe map voor de cybersecuritywet, een nieuwe map per klant, een nieuw addendum per leverancier.
Of ze doen iets innovatiefers: ze maken van documentatie een product en van beveiliging het DNA.
Ze kiezen voor het laatste.
Stap 1: Ze bouwen een Assurance Pack (een bewijsstructuur)
Niet als een lang rapport, maar als een gestructureerde "kaart" van hun werkwijze:
Besturing & beslissingen: wat het management heeft goedgekeurd en waarom
Risicobeeld & prioriteiten: bedreigingen, gevolgen, risicobereidheid
Vaardigheden: incidentmanagement, herstel/DR, logging, kwetsbaarheid, toegang, wijzigingsbeheer
Leveranciersketen: kritische afhankelijkheden, eisen, opvolging, wijzigingen
Bewijs: hersteltests, incidentoefeningen, wijzigingslogboeken, leveranciersbeoordelingen, post-incident reviews
Het gaat niet om "alles hebben". Het gaat erom rustig te kunnen zeggen: "Zo denken we. Dit doen we. En hier is het bewijs."
Stap 2: Ze implementeren SSA, een gemeenschappelijke "contracttaal" voor cyberhygiëne en veerkracht
In plaats van beveiligingseisen op verschillende manieren in elk contract te schrijven, creëren ze een SSA (Supplier Security & Resilience Schedule) die ze hergebruiken in klant- en leverancierscontracten. De SSA beschrijft dezelfde kern: incidentmanagement, continuïteit, logging, toegang, kwetsbaarheden, leveranciersketen, en vooral: hoe het aantoonbaar moet zijn.
Het Assurance Pack wordt de bewijsbibliotheek waar de SSA naar verwijst.
Stap 3: Ze maken documentatie tot bijproduct van de operatie
De laatste stap is het mooiste (en meest uitdagende voor de documentatiedraak): P&P stopt met het "schrijven van documenten" als apart project. Het werkt het beste als de basisprocessen aanwezig zijn: een duidelijk incidentproces, wijzigingsbeheer en verantwoordelijkheden.
Ze introduceren operationele rituelen die automatisch sporen creëren:
kwartaalhersteltests → protocollen
incidentoefeningen → verbeterplannen
leverancierswijzigingen → risicoanalyse + besluit
patch- en kwetsbaarheidsbeheer → tickets + rapporten
Dus als de volgende klant vraagt "hoe ziet uw weerbaarheid eruit?", kan P&P antwoorden zonder een nieuw Word-document te starten. Ze exporteren simpelweg de waarheid die ze al leven. En hier is het resultaat: aanbestedingen worden niet makkelijker omdat eisen verdwijnen, maar omdat P&P de eisen begrijpelijk, herbruikbaar en aantoonbaar heeft gemaakt.
Dit is geen bureaucratie. Dit is techniek.
Belangrijkste boodschap voor MKB: minder tekst, meer structuur
Als u één ding meeneemt uit dit artikel, laat het dit zijn: NIS2/de cybersecuritywet moet geen nieuwe documentatie-universums creëren. Het moet betere vaardigheden ontwikkelen via een betere bewijsstructuur.
NIS2 zelf wijst op het verminderen van administratieve lasten en zelfs het gebruik van een "single entry point" voor incidentrapportage, ook als andere wetgeving (zoals GDPR) parallelle rapportage vereist zonder de GDPR-regels te beïnvloeden (Europees Parlement en Raad van de Europese Unie, 2022, overweging 106–107).
Het is bijna alsof de EU zegt: "Bouw systemen, geen mappen."
En ENISA zegt praktisch: "Bewijs kan hergebruikt worden, u hoeft niet alles te produceren, en één bewijsstuk kan meerdere eisen ondersteunen." (ENISA, 2025). Dit is precies uw stelling, maar nu zonder risico op verwarring.
Afsluiting: de documentatiedraak sterft door... ontwerp
Er is een oude misvatting bij naleving van regels: denken dat documentatie een doel is. Dat is het niet. Het is een bewijsinstrument. Maak het daarom eenvoudig:
Bouw een Assurance Pack: feiten, besluiten, vaardigheden, bewijs.
Neem SSA op in contracten: een plek voor beveiligings- en veerkrachtseisen voor alle leveranciers.
Houd DPA als DPA: verwijs naar SSA voor beveiliging, houd de eisen aan verwerkers schoon.
Maak bewijs onderdeel van de operatie: test, oefen, registreer en laat de sporen de documentatie vormen.
Dit is geen extra bureaucratie. Dit is betere techniek. En als iemand toch zegt "we hebben nog een document nodig", kunt u vriendelijk antwoorden:
"We kunnen er zeker nog een schrijven. Maar wilt u tekst of bewijs?"
Referenties
ENISA. (2025).
Technische implementatierichtlijnen voor cybersecurityrisicobeheersmaatregelen (Versie 1.0, juni 2025).
Europees Agentschap voor Cybersecurity.
Europees Parlement en Raad van de Europese Unie. (2016).Verordening (EU) 2016/679 (Algemene Verordening Gegevensbescherming).EUR-Lex.
Europees Parlement en Raad van de Europese Unie. (2022).Richtlijn (EU) 2022/2555 (NIS2).EUR-Lex.
Regering. (2025/26).Memorie van Toelichting 2025/26:28: Sterke bescherming van netwerk- en informatiesystemen – een nieuwe cybersecuritywet.
