Europese compliance by design

Uitgangspunt

Regelgeving als architectuuroverweging

De meeste wettelijke verplichtingen worden uiteindelijk eigenschappen van een systeem: waar gegevens staan, wie er echt bij kan, wat we loggen en waar, hoe snel we een storing vinden en hoe een component kan worden vervangen. Zolang de architectuur nog vorm krijgt, zijn die eigenschappen relatief goedkoop te regelen. Na livegang worden het helaas vaak workarounds: een extra kopie van productiedata voor een audit, een handmatige goedkeuring in “een Excel-bestand ergens”, of een log die bestaat maar die niemand kan doorzoeken.

Regelgeving als architectuurinput behandelen betekent niet dat architecten zelf de wet moeten interpreteren — dat moeten ze ook vooral niet doen. Het betekent dat juridische en compliance-analyse naast de functionele en niet-functionele eisen in het ontwerp terechtkomt. Uiteindelijk is dit teamwork. Een goede architect weet veel van compliance, maar is daarmee nog geen jurist. Mijn architectuuraanpak volgt daarom deze volgorde:

1. Breng de toepasselijke verplichtingen eerst op hoofdlijnen in kaart. Stel vast welke regelingen gelden, in welke rol (verwerkingsverantwoordelijke of verwerker, aanbieder of gebruiksverantwoordelijke, fabrikant, essentiële of belangrijke entiteit, financiële entiteit) en voor welke processen en gegevens. Dat is eerst een juridische vraag; de architect heeft de uitkomst nodig, geen zelfgemaakte juridische interpretatie.
2. Vertaal verplichtingen naar technische eisen. Maak van verplichtingen concrete, toetsbare eisen: bewaartermijnen, toegangsgrenzen, logging, hersteldoelstellingen en documentatie die op verzoek beschikbaar moet zijn. Belangrijk: test die eisen ook echt. Alleen implementeren en opschrijven is niet genoeg.
3. Maak beslissingen en afwegingen expliciet. Wettelijke eisen concurreren met kosten, gebruiksgemak en opleversnelheid. Leg de opties, de beslissing, het resterende risico en de eigenaar daarvan vast. Een bekend gat met een eigenaar en herstelplan is iets heel anders dan een gat dat niemand heeft gezien. Een besluit vastleggen maakt een wettelijke verplichting natuurlijk niet optioneel.
4. Implementeer governance en technische maatregelen. Maatregelen horen in het platform en in het opleverproces: identiteit en toegang, versleuteling, afdwingen van beleid, scheiding van omgevingen, reviewmomenten. Een beleidsdocument alleen beperkt geen toegang.
5. Toets en borg de verantwoording in beheer. Test of maatregelen echt werken (heel belangrijk), bewaak dat ze blijven werken en wijs eigenaren aan in de beheerorganisatie. Compliance is een eigenschap van het draaiende systeem en de organisatie eromheen, niet van het ontwerpdocument dat ergens in SharePoint staat.

Goede architectuur maakt compliance aantoonbaar en minder kwetsbaar. Ze garandeert die niet: organisatorische maatregelen, contracten, processen en juridische beoordelingen blijven nodig. NIS2 is een goed voorbeeld, omdat de richtlijn expliciete taken bij bestuursorganen legt. De CISO en architect kunnen de maatregelen bouwen, maar het bestuur kan de verantwoordelijkheid niet simpelweg delegeren en vergeten.

AVG

AVG: privacy en datagovernance

Reikwijdte Verordening (EU) 2016/679. Geldt voor de verwerking van persoonsgegevens door verwerkingsverantwoordelijken en verwerkers.

De AVG wordt vaak behandeld als een onderwerp voor toestemmingsformulieren en privacyverklaringen. Ik denk dat we daar als architecten beter in kunnen worden. De echte technische impact ontstaat wanneer het datamodel, de integraties en het platform worden ontworpen — idealiter dus tijdens de ontwerpfase en niet vlak voor livegang.

Wat de regelgeving voorschrijft

• Beginselen voor elke verwerking (art. 5), waaronder doelbinding, minimale gegevensverwerking, opslagbeperking en integriteit en vertrouwelijkheid. De verwerkingsverantwoordelijke moet kunnen aantonen dat aan de beginselen is voldaan (verantwoordingsplicht, art. 5 lid 2).
• Een rechtsgrond voor elke verwerking (art. 6). Worden gegevens zonder nieuwe toestemming of een passende grondslag in EU- of lidstatelijk recht voor een nieuw doel gebruikt, beoordeel dan of dat doel verenigbaar is met het oorspronkelijke doel (art. 6 lid 4). Klein praktisch voorbeeld: als Copilot inkomende e-mails gaat scannen, beoordeel dan of die verwerking past bij het vastgelegde doel en de rechtsgrond. “De data stond al in Outlook” is geen beoordeling.
• Gegevensbescherming door ontwerp en door standaardinstellingen (art. 25) en een beveiligingsniveau dat past bij het risico (art. 32).
• Een register van verwerkingsactiviteiten (art. 30), een gegevensbeschermingseffectbeoordeling (DPIA) wanneer een verwerking waarschijnlijk een hoog risico oplevert (art. 35), verwerkersovereenkomsten (art. 28) en regels voor doorgifte buiten de EER (hoofdstuk V).

Wat dit betekent voor de architectuur

• Gegevensstromen. Breng in kaart waar persoonsgegevens binnenkomen, worden gekopieerd of verrijkt en het systeem verlaten. Neem integraties, analyseplatforms, logs, back-ups en testomgevingen mee. Het hoofd-CRM is zelden de verrassing; die vergeten export of oude testkopie meestal wel.
• Minimalisatie in het datamodel. Leg alleen de attributen vast die een proces nodig heeft en gebruik buiten productie geanonimiseerde of gepseudonimiseerde gegevens. Productiedata kopiëren naar testomgevingen kan in strijd zijn met doelbinding als het gebruik niet is beoordeeld en passende waarborgen ontbreken.
• Doelbinding op de grenzen. Koppel integraties en datasets aan vastgelegde doelen. Bestaande gegevens doorzetten naar rapportages, een dataplatform of een AI-model kan veranderen hoe en waarom ze worden verwerkt. Beoordeel dat bewust in plaats van elke nieuwe integratie automatisch als uitbreiding van het oude doel te zien.
• Toegangsbeheer. Pas minimale rechten toe via rollen, eigenaarschap en beperkingen op veldniveau (bijvoorbeeld beveiligingsrollen, business units en kolombeveiliging in Dataverse). En beoordeel bevoorrechte accounts en serviceaccounts regelmatig; “niemand weet wat dit account doet” is geen beveiligingsmodel.
• Bewaren en verwijderen. Ontwerp bewaartermijnen en verwijdering over integraties en kopieën heen. Een contact uit het CRM verwijderen terwijl dezelfde gegevens in een data lake, een export en drie testomgevingen blijven staan, lost niet veel op.
• Enterprise-AI en persoonsgegevens. Prompts, opgehaalde documenten en gegenereerde output kunnen allemaal persoonsgegevens bevatten. Bronnen voor grounding moeten bestaande rechten respecteren. Het gebruik van interne gegevens met AI is een verwerking waarvoor het doel, de rechtsgrond, de verenigbaarheid en de waarborgen moeten worden beoordeeld. Zie het verborgen AVG-probleem in enterprise-AI.

NIS2

NIS2: cyberbeveiliging en architectuur

Reikwijdte Richtlijn (EU) 2022/2555. Geldt via nationale wetgeving voor essentiële en belangrijke entiteiten in de genoemde sectoren.

NIS2 is geen boodschappenlijst waarop je MFA, een SIEM en een back-upproduct afvinkt om daarna “compliant” te schrijven. Organisaties binnen de reikwijdte moeten cyberbeveiligingsrisico’s beheersen met passende en evenredige maatregelen, en het bestuur draagt daarbij expliciete verantwoordelijkheid. Omdat NIS2 een richtlijn is, blijft de nationale implementatie belangrijk; reikwijdte, toezicht en details kunnen per lidstaat verschillen.

Wat de regelgeving voorschrijft

• Bestuursorganen keuren de maatregelen voor het beheer van cyberbeveiligingsrisico’s goed, houden toezicht op de uitvoering, kunnen aansprakelijk worden gesteld voor inbreuken en moeten een opleiding volgen (art. 20). Afhankelijk van de nationale implementatie kunnen bestuurders persoonlijk aansprakelijk worden gesteld. Of een bestuurdersaansprakelijkheidsverzekering dat risico dekt, hangt af van de polis en het toepasselijke recht. Dat moet dus worden gecontroleerd en niet zomaar worden aangenomen.
• Technische, operationele en organisatorische maatregelen op basis van een benadering die alle gevaren omvat (art. 21). De minimale lijst omvat risicoanalyse en beveiligingsbeleid, incidentafhandeling, bedrijfscontinuïteit inclusief back-ups en noodherstel, beveiliging van de toeleveringsketen, beveiliging bij aanschaf, ontwikkeling en onderhoud inclusief de omgang met kwetsbaarheden, beoordeling van de effectiviteit, cyberhygiëne en training, cryptografie, toegangsbeleid en beheer van bedrijfsmiddelen, en waar passend multifactorauthenticatie.
• Melding van significante incidenten: een vroegtijdige waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en uiterlijk een maand na die incidentmelding een eindverslag (art. 23). Loopt het incident dan nog, dan volgt op dat moment een voortgangsverslag en uiterlijk een maand na de afhandeling het eindverslag.

Wat dit betekent voor de architectuur

• Security by design. Modelleer dreigingen en vertrouwensgrenzen zolang het ontwerp nog kan veranderen: netwerkisolatie, private connectiviteit, gescheiden omgevingen, versleuteling en beheer van secrets. Achteraf inbouwen kan, maar is zelden goedkoop of elegant.
• Identiteit als control plane. Centraliseer identiteit (bijvoorbeeld Microsoft Entra ID), dwing voorwaardelijke toegang en MFA af, gebruik just-in-time bevoorrechte toegang en geef de voorkeur aan managed identities boven opgeslagen secrets. Service principals en technische gebruikers verdienen minstens dezelfde aandacht als mensen; soms meer, omdat jarenlang niemand naar ze kijkt.
• Logging en monitoring. Bepaal wat gelogd wordt, waar het blijft en vooral wie het beoordeelt. Meldtermijnen worden in uren gemeten. Een log die ergens bestaat maar waarmee een incident niet snel kan worden gereconstrueerd, is vooral dure opslag.
• Technische weerbaarheid. Leid hersteldoelstellingen af van de bedrijfsimpact en test het terugzetten daadwerkelijk. “We hebben back-ups” en “we kunnen de dienst binnen vier uur herstellen” zijn twee heel verschillende uitspraken.
• Toeleveringsketen. Maak afhankelijkheden van SaaS-platforms, integratiepartners en bibliotheken zichtbaar. Koppel contractuele beloften daarna aan technische maatregelen, zoals beperkte toegang en monitoring van leveranciersactiviteit. Een dienst uitbesteden betekent niet dat het risico ook weg is.
• Beveiligingsgovernance. Leg beveiligingsrelevante beslissingen en geaccepteerde risico’s vast met een eigenaar, en meet of maatregelen echt werken. Zo krijgt het bestuur bewijs in plaats van nog een groen dashboard dat op aannames draait.

Nog één keer, omdat dit verrassend vaak door elkaar loopt: MFA of een SIEM invoeren betekent niet automatisch dat aan NIS2 wordt voldaan. De maatregelen moeten bij de risico’s passen, goed worden bestuurd en in de praktijk ook echt werken.

Tijdens een actief beveiligingsincident moet de eerste prioriteit zijn om de schade te stoppen. Als een kritieke kwetsbaarheid actief wordt uitgebuit, wil ik dat engineers de getroffen systemen isoleren, de kwetsbaarheid dichten en de controle herstellen. Ik wil de mensen die het probleem oplossen zeker niet uit hun werk halen voor vergaderingen omdat iemand een rapport voor de toezichthouder nodig heeft—sorry, maar dat is de realiteit.

Melden bij de autoriteiten is belangrijk, maar de directe technische respons komt eerst. Zodra de meest urgente maatregelen voor indamming lopen, moet de organisatie haar meldplichten oppakken. Dat betekent niet dat de melding onbeperkt kan worden uitgesteld. De wettelijke termijnen blijven gelden en iemand moet verantwoordelijkheid nemen om die te halen zonder de engineers in de weg te lopen. Dat is belangrijk omdat de IT-infrastructuur verbonden is met het voortbestaan van de organisatie. De melding zelf niet.

Wat mij betreft moeten complianceprocessen juist hier praktisch zijn. Tijdens een noodsituatie moet het stoppen van de aanval voorrang krijgen op papierwerk. Een meldproces dat de indamming belemmert, is slecht ontworpen.

EU AI Act

EU AI Act: AI-governance en systeemontwerp

Reikwijdte Verordening (EU) 2024/1689. De verplichtingen hangen af van de rol (aanbieder, gebruiksverantwoordelijke, importeur, distributeur) en de risicocategorie van het AI-systeem.

De AI Act reguleert AI-systemen op basis van risico. Dat klinkt eenvoudig totdat een projectteam moet bepalen wat het systeem nu precies moet doen, welke juridische rol de organisatie heeft, welke data het model gebruikt en wie kan ingrijpen als de uitkomst fout is. Dat zijn juridische vragen, maar vanaf dag één ook architectuurvragen.

Wat de regelgeving voorschrijft

• De oorspronkelijke verboden praktijken (art. 5) en de verplichting tot AI-geletterdheid (art. 4) gelden sinds 2 februari 2025. De later toegevoegde verboden in art. 5 lid 1, punten (ba) en (bb), en art. 5 leden 1a en 1b gelden vanaf 2 december 2026. Verplichtingen voor AI-modellen voor algemene doeleinden gelden sinds 2 augustus 2025; transparantieverplichtingen voor bepaalde AI-systemen, zoals melden dat iemand met AI communiceert en het markeren van gegenereerde content (art. 50), sinds 2 augustus 2026.
• De hoog-risicoclassificatie volgt uit art. 6 in combinatie met bijlage I (veiligheidscomponenten van gereguleerde producten) en bijlage III (genoemde toepassingen zoals werkgelegenheid, kredietbeoordeling en toegang tot essentiële diensten).
• Hoog-risicosystemen vereisen risicobeheer (art. 9), datagovernance (art. 10), technische documentatie (art. 11), automatische registratie (art. 12), transparantie richting gebruiksverantwoordelijken (art. 13), menselijk toezicht (art. 14) en nauwkeurigheid, robuustheid en cyberbeveiliging (art. 15). Gebruiksverantwoordelijken hebben eigen verplichtingen (art. 26), waaronder menselijk toezicht en het monitoren van de werking.
• De Digital Omnibus-wijziging van 2026 heeft de toepassing van de hoog-risico-eisen uitgesteld tot 2 december 2027 voor systemen uit bijlage III en tot 2 augustus 2028 voor systemen uit bijlage I. De eisen zelf zijn niet geschrapt.

Wat dit betekent voor de architectuur

• Risicoclassificatie als ontwerpinput. Classificeer het beoogde doel voordat modellen en platforms worden gekozen, niet twee weken voor livegang. Een gewijzigd doel of substantiële wijziging kan de rol en verplichtingen veranderen (art. 25), dus classificatie hoort in architectuurgovernance en niet alleen in een inkoopchecklist. Zie wat als hoog-risico-AI geldt.
• Datagovernance. Leg de herkomst van trainings-, evaluatie- en groundingdata vast, inclusief kwaliteit en bekende beperkingen. Gaat het om persoonsgegevens, dan geldt de AVG naast de AI Act. De ene regeling wacht niet netjes tot je klaar bent met de andere.
• Menselijk toezicht. Bouw toezicht in de gebruikerservaring: toon waarop een aanbeveling is gebaseerd, laat mensen corrigeren of stoppen en vermijd interfaces die automatisch accepteren aanmoedigen. Een zin in een beleidsdocument dat “de mens verantwoordelijk blijft” creëert nog geen betekenisvol toezicht.
• Documentatie en traceerbaarheid. Log invoer, model- en promptversies, configuratie en output goed genoeg om een beslissing te reconstrueren. Beheer de technische documentatie samen met het systeem; documentatie voor versie 1.2 helpt weinig als productie inmiddels op versie 3.7 draait.
• Monitoring. Bewaak kwaliteit, drift en incidenten tijdens gebruik en voer de bevindingen terug naar het risicobeheer. Voor aanbieders van hoog-risico-AI-systemen is dat een formele verplichting na het in de handel brengen (art. 72), maar ook daarbuiten is het gewoon verstandig engineeringwerk.
• Integratie in bedrijfssystemen. AI-componenten erven rechten, datagrenzen en faalscenario’s van de systemen eromheen. Bepaal wat er gebeurt als een model niet beschikbaar, traag of vol overtuiging fout is. Een kernproces mag niet omvallen omdat een externe model-endpoint een slechte middag heeft.

Voorlopig kan het verstandig zijn om AI-systemen te vermijden die mogelijk als hoog risico worden aangemerkt. De juridische situatie is nog in ontwikkeling: de EU Omnibus wijzigt de regels en de tijdlijnen blijven verschuiven. Vanwege de administratieve last en de extra architectuurinspanning zou ik alleen voor een hoog-risico-AI-systeem kiezen als de businesscase duidelijk en meetbaar is. De verwachte waarde moet opwegen tegen de extra inspanning voor compliance en IT, zowel nu als gedurende de hele operationele levensduur van het systeem.

DORA · CRA

DORA en CRA: operationele weerbaarheid en softwarebeveiliging

Reikwijdte Twee afzonderlijke verordeningen met verschillende adressaten. Beide raken de manier waarop afhankelijkheden en software gedurende hun levenscyclus worden beheerd.

DORA en de Cyber Resilience Act worden vaak in hetzelfde compliancegesprek genoemd, maar behandel ze alsjeblieft niet als uitwisselbaar. DORA gaat over de operationele weerbaarheid van financiële entiteiten, ook bij verstoringen door technologieleveranciers. De CRA gaat over de cyberbeveiliging van producten met digitale elementen en de verantwoordelijkheid van fabrikanten vóór en na marktintroductie.

De herziene richtlijn productaansprakelijkheid voegt een aparte dimensie toe: software is uitdrukkelijk een product, zodat een gebrek grond kan zijn voor een aansprakelijkheidsclaim. Zie of software een product of een dienst is.

Aanpak

Van regelgeving naar architectuurbeslissingen

Geen van deze regelingen geeft je een kant-en-klaar architectuurdiagram (helaas). Ze beschrijven uitkomsten: data met een bekend doel, risico’s die worden beheerst, incidenten die worden ontdekt, systemen die herstellen, software die wordt onderhouden en beslissingen die uitlegbaar zijn. Die uitkomsten vertalen naar iets dat een team echt kan bouwen en beheren, is architectuurwerk.

In de praktijk brengt goede architectuur vier inputs in balans die zelden precies dezelfde kant op wijzen:

• Bedrijfseisen: wat de organisatie van het systeem nodig heeft en, net zo belangrijk, waarom.
• Technische haalbaarheid: wat de platforms en het team realistisch kunnen opleveren en onderhouden, niet wat er goed uitzag in een leveranciersdemo.
• Operationele beperkingen: budgetten, kennis, het bestaande landschap en serviceniveaus. Die verdwijnen niet omdat het architectuurdiagram er netjes uitziet.
• Toepasselijke wettelijke verplichtingen: wat aantoonbaar waar moet zijn voor het systeem en het beheer ervan, met bewijs in plaats van aannames.

Mijn architectuuraanpak laat zien hoe ik deze inputs van context en eisen via patronen, technologiekeuzes en waarborgen naar realisatie en beheer breng. Die terugkoppeling is belangrijk: verplichtingen verdwijnen niet na livegang, ook niet als het projectteam dat wel doet. Blijf tegelijk praktisch. Als je ieder klein compliancedetail wilt oplossen voordat je verdergaat, kan een IT-project stilvallen. Voor mij draait het erom dat je aan de verplichtingen voldoet en de oplevering werkbaar houdt. Dat evenwicht is waar iedere architect naar zou moeten zoeken.