ENS, NIS2, DORA, AI Act, RGPD, eIDAS, Data Act, ISO 27001, NIST, CIS — voor veel technische teams begint het regelgevingskaartje steeds meer op een eindeloze lijst met afkortingen te lijken, die vaak pas laat op tafel komen: bij een aanbesteding, een audit, een financiële klant, een certificering of een beveiligingsincident.
De meest voorkomende fout is om elk framework als een losstaand project te zien. Eén team implementeert het ENS, een ander bereidt ISO 27001 voor, de juridische afdeling controleert RGPD, beveiliging bespreekt NIS2, productteams kijken naar de AI Act, en inkoop vraagt naar leveranciers. Het resultaat is meestal een berg documenten, dubbele controles en bewijzen die verstrooid liggen over e-mails, tickets, spreadsheets en systemen die niet met elkaar verbonden zijn.
Voor een technische organisatie is de meest nuttige aanpak niet te starten vanuit de normen zelf, maar vanuit de werkelijke architectuur: welke diensten levert de organisatie, welke data worden verwerkt, welke infrastructuur wordt gebruikt, welke derden involveren zich, welke klanten zijn afhankelijk en welk effect zou een uitval, datalek of ongecontroleerde geautomatiseerde beslissing hebben.
Van juridische matrix naar technisch dienstenlandschap
De toepassing van regelgeving hangt zelden af van één enkel label. Een bedrijf kan tegelijkertijd cloudprovider, MSP, softwareontwikkelaar, verwerker, leverancier aan de financiële sector, AI-platformexploitant en overheidsopdrachtnemer zijn — elk met eigen verplichtingen.
Het Nacional Security Scheme wordt in Spanje gereguleerd via Koninklijk Besluit 311/2022 en gaat over systemen die informatie of diensten beheren binnen de elektronische overheid en hun leveranciers. NIS2, de Richtlijn (EU) 2022/2555, verhoogt het niveau van cyberveiligheid in de EU voor essentiële en belangrijke entiteiten. DORA, Verordening (EU) 2022/2554, richt zich op operationele weerbaarheid in de financiële sector en risicobeheer ICT. De AI-verordening, Verordening (EU) 2024/1689, hanteert een risicogebaseerde aanpak voor AI-systemen.
Daarnaast bestaan horizontale normen over privacy, digitale identiteit, data en hergebruik. De RGPD reguleert de verwerking van persoonsgegevens; eIDAS behandelt elektronische identificatie en trustdiensten; de Data Act stelt regels over toegang en gebruik van data; en de Data Governance Act regelt governance en datadeling binnen de EU.
De praktische consequentie is dat je niet enkel een inventaris van systemen en assets nodig hebt, maar ook van diensten. Het is niet genoeg te weten hoeveel servers, containers, buckets, clusters of databases er zijn — je moet weten welke service elke asset ondersteunt, welke data wordt verwerkt, wie die gebruikt, welke SLA’s van toepassing zijn, welke leverancier betrokken is en welke contractuele of wettelijke verplichtingen er rusten op die component.
Een CRM met persoonsgegevens wordt niet hetzelfde beheerd als een scoringplatform met AI. Een backup van een gemeente heeft niet hetzelfde kader als een intern analytisch systeem. Een cloudprovider die diensten levert aan een financiële instelling neemt niet hetzelfde risico voor haar rekening als een bedrijfswebsite. De architectuur is de sleutel tot het verklaren van de norm.
De kern: identiteit, logs, patches, bewijzen en governance
Hoewel elke regelgeving zijn eigen terminologie hanteert, komen veel vereisten neer op vergelijkbare controles. Risicobeheer, governance, toegangscontrole, sterke authenticatie, functiescheiding, asset-inventarisatie, encryptie, kwetsbaarhedbeheer, monitoring, incidentrespons, continuïteit, leveranciersbeheer, training en audits.
Voor technische teams betekent dit de mogelijkheid om een gemeenschappelijke basis te bouwen. Het heeft weinig zin om verschillende bewijs- en controle systemen te gebruiken voor ENS, ISO 27001, DORA of NIS2 als ze allemaal vragen naar dezelfde informatie: wie heeft toegang, met welke privileges, welke wijzigingen zijn doorgevoerd, welke kwetsbaarheden bestaan, wanneer is de back-up getest, wat gebeurde er tijdens een incident, en wie keurde een uitzondering.
Moderne compliance wordt steeds meer platformengineering. IAM, MFA, PAM, SIEM, EDR, CMDB, ticketing, kwetsbaarhedenscans, CI/CD pipelines, Git repositories, cloudinventaris, secrets management, back-ups en GRC-tools moeten in één gesprek passen.
Een simpel voorbeeld: kwetsbaarhedbeheer. In een volwassen organisatie bestaat het niet uit het maandelijks exporteren van een PDF voor auditdoeleinden. Het moet een geactualiseerd inventaris, prioriteiten per service, technische verantwoordelijken, SLA’s voor remediatie, goedgekeurde uitzonderingen, tracering in tickets en bewijzen van afsluiting omvatten. Diezelfde workflow kan ook helpen bij ENS, NIS2, ISO 27001, DORA of contractuele eisen van klanten.
Hetzelfde geldt voor logs. Het is niet voldoende om gebeurtenisgegevens op te slaan — je moet vaststellen wat wordt geregistreerd, hoe lang, met welke integriteit, wie toegang heeft, hoe alerts worden gecorreleerd en hoe een tijdlijn wordt gereconstrueerd na een incident. Voor operationele veiligheid is het dagelijks werk; voor juridische en compliance-doeleinden is het bewijsvoering.
Bij AI ligt er een extra uitdaging. De AI Act verplicht een risk-based aanpak, inclusief gebruiksdoel, documentatie, menselijke supervisie, datatracering, lifecycle management en risicobeoordeling. Technisch betekent dat een overgang van “model integratie” naar “kennis van het specifieke model, data, doel, controles, metrics, limieten en verantwoordelijken”.
Compliance als code: minder documenten, meer operationeel
De volgende stap is om delen van compliance te automatiseren en te integreren in de operationele processen. Niet alles kan geautomatiseerd, maar veel bewijzen kunnen automatisch gegenereerd worden vanuit de dagelijkse operatie.
Een MFA-beleid is zinloos als de identity console niet toont dat privileged accounts dubbele authenticatie gebruiken. Back-upprocedures moeten bewijs van herstelmechanismen bevatten. Versleutelingsbeleid is ineffectief als buckets publiek zijn, volumes onbeveiligd of geheime gegevens in repositories staan. Een leveranciersmatrix is nutteloos zonder koppeling aan contracten, risicobeoordelingen, subonderaannemers en exit-plannen.
De kern van compliance as code is het integreren van controlemechanismen op de plek waar technologie wordt ontwikkeld en gebruikt: policies in repositories, controles in pipelines, infrastructure-as-code validaties, detectie van onveilige configuraties, automatische bewijzen en dashboards per dienst. Het vervangt niet juridisch advies of de beoordeling van de CISO, maar verkleint de kloof tussen wat het bedrijf zegt te doen en wat de systemen daadwerkelijk uitvoeren.
Het verandert ook de relatie tussen legal en IT. IT-advocaten moeten verder gaan dan enkel contractclausules, en begrijpen afhankelijkheden in cloud, dataverwerking, rolverdeling, activity logs, AI-architectuur, incidenten en supply chain. Tegelijkertijd moeten technische teams de regelgeving niet zien als een last, maar begrijpen dat veel verplichtingen goede engineering- en security-praktijken zijn die wettelijk worden geëxpliciteerd.
De uitdaging voor 2026 is niet alleen het kennen van alle afkortingen. Het is het ontwikkelen van een model dat snel antwoord kan geven op vragen als: voor deze dienst, met deze data, deze klanten en leveranciers, welke risico’s lopen we? Welke controles bewaken die, en welke bewijzen kunnen we morgen tonen?
Organisaties die dit goed aanpakken, zullen geen dertien complianceprogramma’s naast elkaar hebben, maar een solide gezamenlijke basis met specifieke lagen voor diensten, sectoren en risico’s. Dat scheidt een organisatie die slechts auditen van een die bouwt aan een compliance-gedreven architectuur.
Veelgestelde vragen
Wat moet een technisch team eerst doen bij zoveel normen?
Enkel en alleen: in kaart brengen welke diensten er zijn en afhankelijkheden. Voordat je controles opstelt, is het belangrijk om te weten welke systemen elke dienst ondersteunen, welke data ze verwerken, wie die gebruikt en welke derden erbij betrokken zijn.
Helpt ISO 27001 om ENS, NIS2 of DORA af te dekken?
Het biedt een goede basis voor security management, maar vervangt niet het specifieke analyseproces van elk raamwerk. ENS, NIS2 en DORA hebben eigen verplichtingen die expliciet moeten worden vertaald.
Wat betekent compliance as code?
Het toepassen van compliance-controles automatisch of semi-automatisch binnen de operationele lijnen: pipelines, infrastructure-as-code, inventarisatie, monitoring, toegangsbeheer en bewijzen gegenereerd door systemen.
Hoe beïnvloedt de AI Act de technische teams?
Het dwingt tot betere documentatie en governance van AI-systemen, vooral bij hoog-risico applicaties. Dit omvat doelstelling, data, menselijke supervisie, tracering, wijzigingsbeheer, risicoraming en toewijzing van verantwoordelijkheden.
Bron: Contractadvocaten