Open-source GRC voor BIO2, NIS2 en AI Act: de bewijslus blijft een gat

De Nederlandse publieke sector staat voor een ongemakkelijke stapel. Per 1 januari 2026 geldt de Cyberbeveiligingswet, die de NIS2-richtlijn implementeert en een meldplicht binnen 24 uur voor ernstige incidenten introduceert. Op dezelfde organisaties rust de Baseline Informatiebeveiliging Overheid (BIO2), die de Rijksinformatiebeveiligingsnorm 2 (RIB/NOREA-tradition) praktisch maakt. En de EU AI Act is sinds 2 augustus 2026 in volle omvang van toepassing, met de hoog-risico verplichtingen die vanaf augustus 2027 gelden. Dat is niet drie problemen. Dat is één fundamenteel probleem: drie compliance-kaders die over dezelfde controls heen vallen, met drie soorten bewijsvoering, en maar één CISO-budget.

De verleiding is dan groot om te zoeken naar één platform dat alles dekt. Drie open-source-initiatieven springen daarbij in beeld: CISO Assistant (4.400 sterren, zelf te hosten GRC-platform), de Awesome EU AI Act-verzameling (een curated lijst van tools en bronnen) en de NIS2 SME-toolkit (templates voor het midden- en kleinbedrijf). Het verhaal dat bij deze drie hoort is verleidelijk: een open-source stapel die van risico-inventarisatie via NIS2-compliance tot AI Act-verantwoording één samenhangend geheel maakt.

Dat verhaal verdient een nuchtere toets. Want de werkelijkheid is genuanceerder: een van deze drie is een volwassen platform, een tweede is een index, en de derde is een verzameling sjablonen met expliciete juridische beperkingen. Wie ze als één "stapel" behandelt, verwart een menu met een maaltijd.

Wat er werkelijk op tafel ligt

CISO Assistant (intuitem/ciso-assistant-community) is een volwassen, zelf te hosten GRC-platform van Intuitem, gepubliceerd onder AGPL-3.0 met een commerciële Pro/Enterprise-laag. Het platform claimt ondersteuning voor meer dan 200 raamwerken; de daadwerkelijk uitgeschreven lijst in de README telt er 126, waaronder BIO2 (item 91), NIS2, de NIS2-implementatiewet van Nederland (item 122), ISO/IEC 27001:2022, DORA, NIST AI Risk Management Framework en de ENISA SME-maturiteitsbeoordeling. De kernontwerpkeuze is het decoupleren van compliance van securitycontrols: een control kan in meerdere raamwerken vallen zonder dat de implementatie wordt gedupliceerd. Het platform is API-first, biedt risico-inventarisatie en herstel-tracking ingebouwd, en ondersteunt aangepaste raamwerken via een eigen syntax.

Awesome EU AI Act (GenAI-Gurus/awesome-eu-ai-act) is een curated lijst (een "awesome"-verzameling) van meer dan honderd tools, bronnen, sjablonen en richtlijnen rond de EU AI Act, gepubliceerd onder CC0. Het bevat Nederlandse publieke relevantie, zoals het Algoritmekader van het ministerie van Binnenlandse Zaken, en een reeks specifieke AI Act-tools: risk-classificatoren, Annex IV-technische-documentatiegeneratoren, FRIA-sjablonen en het Microsoft Agent Governance Toolkit.

NIS2 SME-toolkit (paolocarner/nis2-sme-toolkit) is een verzameling van vier sjablonen van BARE Consulting, gericht op organisaties van 50-250+ medewerkers zonder eigen compliance-team: een gap-assessment-tool in Excel, een bestuursbriefing, een incident-response-playbook en een informatiebeveiligingsbeleid-template. Belangrijk detail: de auteur is een vCISO-consultant en de toolkit verwijst door naar zijn eigen commerciële dienst voor de interactieve versie. De licentie is CC BY 4.0.

De drie zijn dus geen gelijkwaardige "stapel". Ze opereren op drie verschillende niveaus van een GRC-stapel: een platform dat workflows automatiseert, een index die je vertelt welke tools bestaan, en een template-set die je sjablonen geeft. Wie ze combineert, moet de brug ertussen zelf bouwen.

Het samenwerkingsprobleem, formeel

De centrale vraag is niet "welke tool is het beste", maar of de drie samen een functioneel gesloten compliance-lus vormen. Laten we die lus formeel definiëren.

Laat een compliant organisatie een geordende verzameling S van securitycontrols hebben (BIO2, NIS2-Artikel-21-measures, AI-Act-hoog-risico-vereisten). Laat R de verzameling raamwerken zijn die de organisatie moet aantonen, en M: R → 2^S de mapping die aan elk raamwerk de controls koppelt die het voorschrijft. Een gesloten lus vereist drie functies:

• assess(s) ∈ [0,1]: de mate waarin control s is geïmplementeerd,
• evidence(s): het aantoonbare bewijs dat assess(s) rechtvaardigt,
• audit(S, evidence): een verifieerbare conclusie over compliance.

Een platform is "gesloten" wanneer het voor élke s ∈ S de assessment, het evidence en de auditondersteuning levert binnen één data-model. CISO Assistant levert assess en een deel van audit (het koppelt controls aan controls, raamwerken en risico's). Maar evidence, de primaire, verifieerbare onderbouwing zoals auditlogs, configuratiebewijs en penetratietestresultaten, levert het platform niet automatisch; het beheert de koppeling, niet het bewijs zelf. De NIS2 SME-toolkit levert assess (de gap-assessment) maar geen evidence en geen audit. De Awesome-lijst levert noch assess, noch audit; het vertelt je welke tools die functies kunnen vervullen.

De conclusie is scherp: geen van de drie levert evidence, en dat is precies de functie die in de Nederlandse publieke sector het duurst is. Bewijs voor toegangsbeheer (ISO/IEC 27002:2022-controle 5.15, 5.18) vereist bijvoorbeeld actieve configuratieverificatie, niet alleen een kruisje in een spreadsheet. Bewijs voor de NIS2 meldplicht vereist een operationeel incident-proces. Bewijs voor een AI-Act-risicobeoordeling vereist (voor hoog-risico systemen) een FRIA en technische documentatie. Dit sluit aan bij een eerder thema op deze site: de vraag of compliance-automatisering bewijskracht kan leveren in plaats van alleen administratie, zie hoe een multi-agent pipeline OT-documentatie in NIS2-bewijs verandert en waarom NIS2-compliance automatiseren met AI geen vanzelfsprekendheid is. Die posts tonen dat zelfs een geslaagde evidence-automatisering gebonden blijft aan de kwaliteit van wat je erin stopt, precies de grens die generieke GRC-platforms niet overbruggen. Dat is geen toolingprobleem; dat is de grens van wat generieke GRC-platforms kunnen beloven.

De kosten van die brug zijn bovendien structureel meetbaar in de omvang van de mapping. Laat |R| het aantal raamwerken zijn en |S| het aantal controls dat de organisatie onderhoudt. Een platform dat overlap tussen raamwerken automatisch herkent, reduceert het aantal te documenteren control-implementaties van Σᵣ |M(r)| (de som van de per-raamwerk-vereiste controls) tot |∪_r M(r)| (de verenigde set). Een Python-implementatie van die reductieberekening is eenvoudig:

def overlap_reduction(mappings: dict[str, list[str]]) -> tuple[int, int, float]:
    """Bereken de control-reductie door raamwerkoverlap te verenigen.

    mappings: raamwerknaam -> lijst van control-ID's die het voorschrijft.
    Retourneert (naief_totaal, verenigde_set, reductiefactor).
    """
    naief = sum(len(cs) for cs in mappings.values())
    verenigd = set().union(*mappings.values()) if mappings else set()
    return naief, len(verenigd), (naief - len(verenigd)) / naief

# BIO2 en NIS2 hebben overlappende controls rond toegangsbeheer, logging,
# incidentmanagement en cryptografie.
mappings = {
    "BIO2": ["5.15", "5.18", "8.2", "8.3"],
    "NIS2_art21": ["a", "c", "g", "i"],
    "AI_Act_high_risk": ["risk", "data_gov", "trace", "monitor"],
}
naief, verenigd, reductie = overlap_reduction(mappings)
print(f"Naief totaal: {naief}, verenigd: {verenigd}, reductie: {reductie:.0%}")

De complexiteit van de verenigingsoperatie is O(c) in het aantal controls c = Σᵣ |M(r)| met behulp van een hashset. De winst zit niet in de algoritmische complexiteit, maar in de administratieve: elke control die maar één keer hoeft te worden geïmplementeerd, scheelt voor die control een volledige compliance-documentatiecyclus. De reductiefactor is echter een bovenlimiet: hij neemt aan dat een gedeelde control exact dezelfde specificatie heeft in beide raamwerken, wat in de praktijk zelden opgaat. ISO/IEC 27002:2022-controle 5.15 (toegangsbeheer) en NIS2 Artikel 21(2)(i) (toegangsbeheer) overlap in bewoording, maar de auditvragen die een Rijksauditor stelt, zijn strenger dan die van een NIS2-auditor.

Het echte verschil: het platform versus de index

Het meest onderscheidende dat deze drie samen opleveren is niet technisch maar conceptueel. Wie ze naast elkaar legt, ziet drie complementaire waarheden over open-source compliance:

1. Een platform dekt, maar sluit de bewijslus niet. CISO Assistant is indrukwekkend in hoe het de koppeling beheert tussen raamwerk, control en risico, maar die koppeling opzetten is nog geen bewijs leveren. "Dekt BIO2" betekent niet "bewijst BIO2". De 126 raamwerken in de lijst zijn vooral mappings; of de onderliggende controls ook in de praktijk getoetst kunnen worden, hangt af van de data die je erin stopt.

2. Een index verbreedt, maar selecteert niet. De Awesome EU AI Act-lijst telt tientallen AI-Act-tools, van deterministische risk-classificatoren tot Annex-IV-generatoren. Een index die alles noemt is handig, maar verschuift het selectiewerk naar de lezer die de tools moet doorlopen. Het Algoritmekader van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties staat er terecht bij; dat het er meer dan honderd tools in één lijst zet, is een sterke illustratie van de fragmentatie die een platform juist wil oplossen.

3. Een template-set is een startpunt, geen eindpunt. De NIS2 SME-toolkit is eerlijk over haar beperkingen: "This package does not constitute legal advice, certification or guarantee of compliance." Het is een goed startpunt voor organisaties zonder compliance-capaciteit, maar een sjabloon is geen operationeel bewijs.

Hypothesen en toetsing

Laat ons de centrale bewering toetsen als een falsifieerbare hypothese.

H1: Eén open-source platform kan de compliance-lus voor BIO2, NIS2 en de AI Act sluiten zonder significante aanvulling. Falsificatie-criterium: een organisatie kan met alleen CISO Assistant een audit van een externe partij doorstaan voor alle drie de raamwerken, zonder handmatig evidence toe te voegen buiten het platform om.

Op basis van de readmes is H1 weerlegd: geen van de drie levert evidence, en CISO Assistant beheert koppelingen maar genereert geen primair bewijs. Het is denkbaar dat de Pro/Enterprise-laag dit deels adresseert, maar dat valt buiten de open-source claim en is niet verifieerbaar via de publieke bron.

H2: Open-source is voor de Nederlandse publieke sector vooral een fragmentatiebestrijder. Falsificatie-criterium: de combinatie van de drie levert een lagere totale inspanning dan het handmatig onderhouden van drie losse raamwerken.

Deze hypothese is aannemelijk maar niet bewezen. Het is structureel waarschijnlijk dat de data-modelkoppeling van CISO Assistant de administratieve overlap tussen BIO2 en NIS2 vermindert (beide bevatten vergelijkbare controles rond toegangsbeheer, logging en incidentmanagement). Maar de bewijslast bij de auditor (evidence) blijft buiten het platform, en is voor de publieke sector vaak de grootste kostenpost.

Counterfactual: wat als de drie wél een gesloten lus vormden?

Om de claim scherp te krijgen, is het nuttig het tegenovergestelde scenario te doorlopen. Stel dat een open-source platform wél evidence genereerde: het automatisch verzamelde configuratiestaten, auditlogs en penetratietestresultaten, en die koppelde aan de BIO2- en NIS2-controls. Wat zou die organisatie dan nog zelf moeten doen? Het antwoord is verrassend robuust: de interpretatie. Een geautomatiseerd evidence-systeem kan aantonen dat een firewallregel is geconfigureerd, maar niet dat die configuratie past bij de bedrijfscontext. Een Rijksauditor vraagt niet alleen "staat de regel aan", maar "is de regel passend voor het gegevensclassificatieprofiel van deze dienst, en is de uitzondering geautoriseerd?". Die kwalitatieve interpretatie is per definitie menselijke oordeelskracht. Onder de huidige AI Act-artikelen is er bovendien een expliciete eis dat de verantwoordelijke menselijke controle kan uitoefenen over een hoog-risico systeem (artikel 14.4). Dit is geen tijdelijke tooling-hiaat, maar een structurele eigenschap van externe verantwoordingsplicht.

Met andere woorden: zelfs in een gesloten lus is het platform een hulpmiddel, geen vervanging van de verantwoordingsrelatie. Dat betekent praktisch dat de "brug" tussen platform en auditor geen technisch artefact is dat je eenmalig koopt, maar een doorlopende capaciteit die elke organisatie moet onderhouden. Wie dat miskent, koopt een platform in de veronderstelling dat het de verantwoordelijkheid delegeert.

Onzekerheidsklassen

Deze analyse kent onzekerheid en moet er expliciet op worden beoordeeld; het is niet bekend hoe de tools in volledige productie-omgevingen presteren, en wat ik niet kan controleren is de commerciële laag van CISO Assistant. De analyse rust op drie bronnen met uiteenlopende betrouwbaarheid. Ten eerste de repository-README's en API-metadata (verzameld op 16 september 2026); die zijn primaire bronnen, maar veranderlijke: een README is geen formeel vastgelegde functionele specificatie. De framework-telling van 126 is een lezing van de lijst op de dag van raadpleging; die kan morgen anders zijn. Ten tweede het onderscheid assess versus evidence; dat is een conceptueel raamwerk, geen empirisch gemeten eigenschap van deze specifieke tools. Het is afgeleid van wat de README's beschrijven, niet van een functionele test. Ten derde de bewering dat "geen van de drie evidence levert"; die is gebaseerd op de publiek beschikbare documentatie. Het is denkbaar dat de commerciële Pro/Enterprise-laag van CISO Assistant meer doet, maar dat is niet via de publieke bron te verifiëren en valt buiten de "open-source" claim. Alleen de eerste bron heb ik direct geraadpleegd; de classificatie en interpretatie zijn mijn eigen gevolgtrekkingen met een midden tot hoge betrouwbaarheid, niet onafhankelijk geverifieerd door een functionele toets.

Wat de Nederlandse publieke sector hier concreet mee kan

De combinatie van de drie is bruikbaar, maar niet als kant-en-klare stapel. Een realistische, gefaseerde inzet ziet er zo uit:

1. Gebruik de Awesome EU AI Act-lijst als selectie-instrument. Voor een organisatie die aan de AI Act moet voldoen, is de lijst het snelste overzicht van bestaande tools, inclusief het Nederlandse Algoritmekader. Gebruik de lijst om te bepalen welke specifieke AI Act-tool het best past, niet om te proberen ze allemaal in te zetten.
2. Start een compliance-programma met de NIS2 SME-toolkit voor de gap-assessment. De Excel-gap-assessment geeft een eerste, snel beeld van de volwassenheid tegen de 21 maatregelen van Artikel 21(2). Dit is een laagdrempelig startpunt voor organisaties zonder compliance-team.
3. Standaardiseer de administratieve kern met CISO Assistant als platform. Zet de mapping van BIO2, NIS2 en de AI Act in één data-model, zodat overlap in controls zichtbaar wordt en niet drie keer wordt gedocumenteerd.
4. Investeer afzonderlijk in de evidence-laag. De gap tussen het platform en evidence moet worden gedicht met operationeel werk: configuratieverificatie, auditlog-integratie, incident-response-documentatie. Dat is geen tooling-inkoop maar een organisatorische verantwoordelijkheid.

De diepere vraag

Het meest interessante aan deze drie is niet wat ze samen kunnen, maar wat ze gezamenlijk zichtbaar maken: de open-source compliance-ruimte voor de EU is rijk, gefragmenteerd, en geconcentreerd op assessment, niet op evidence. Het is opvallend dat honderden tools helpen bepalen "hoe compliant ben ik", terwijl maar weinig tools helpen bewijzen "waarom ik compliant ben". Voor de Nederlandse publieke sector, waar auditors de bewijslast centraal stellen, is dat het gat dat geen open-source platform vanzelf vult.

Dat is geen argument tegen open-source GRC. Het is een argument voor een realistische verwachting: een platform kan de administratie centraliseren en overlap zichtbaar maken, maar de operationele bewijslast blijft mensenwerk. Wie dat onderscheid begrijpt, kan de drie op de juiste plaats in de lus zetten, en houdt zo controle over wat ze wel en niet moeten bewijzen.

Bronnen: de publieke README's en repository-metadata van CISO Assistant (intuitem/ciso-assistant-community op GitHub), de Awesome EU AI Act-lijst (GenAI-Gurus/awesome-eu-ai-act) en de NIS2 SME-toolkit (paolocarner/nis2-sme-toolkit), geraadpleegd op 16 september 2026 via GitHub. De framework-telling (126) en de platformbeschrijving zijn afkomstig uit de README's; de "200+ framework"-claim uit de GitHub API-metadata.