NIS2 en DORA voor platformteams: wat je daadwerkelijk moet bouwen.
Waar NIS2 en DORA samenkomen op het platform
NIS2 en DORA zijn verschillende regelgevingen met verschillende bereiken. NIS2 dekt sectoren voor kritieke infrastructuur: energie, water, financiën, zorg, digitale infrastructuur. DORA dekt financiële entiteiten specifiek: banken, verzekeraars, betalingsverwerkers en hun ICT-derde-partij-aanbieders. De overlap voor EU-platformteams is smaller dan de compliance-consultingbranche suggereert, maar het overlappende deel is precies waar het platform-engineering-werk leeft.
Beide regelgevingen vereisen vier dingen van platformteams: de mogelijkheid significante incidenten binnen 24 tot 72 uur te detecteren en te melden, een gedocumenteerde afhankelijkheidskaart van kritieke services en hun ICT-aanbieders, bewijs van testen van operationele veerkracht, en toegangscontrole en auditlogboeken die toereikend zijn om te reconstrueren wie wat deed tijdens een incident.
Als je platform al OpenTelemetry draait, een service-catalogus onderhoudt, game days uitvoert en alle control-plane-acties naar een onveranderbaar doel logt, ben je 70 tot 80 procent compliant met de platform-niveaucontroles van beide regelgevingen. De ontbrekende 20 tot 30 procent is voornamelijk documentatiestructuur en bewaarbeleid, geen nieuwe engineering.
De vier platformcontroles die je werkelijk nodig hebt
Controle één: incidentpijplijn. Een gedocumenteerd, getest escalatiepad van alert tot respons tot melding. De pijplijn moet voldoen aan de 72-uur-meldingsdrempel van NIS2 artikel 23 en de 4-uur-initiëlemelding van DORA artikel 19. Als je huidige on-call-runbook geen regelgevingsstap bevat, voeg er een toe. De alert gaat af, de on-call reageert, de respons wordt gelogd naar je onveranderbaar auditspoor, en de melding aan de nationale bevoegde autoriteit of toezichthouder triggert vanuit dezelfde workflow. Geen apart complianceproces nodig.
Controle twee: afhankelijkheidsregister. Een machineleesbare kaart van je kritieke services, de ICT-aanbieders waarvan ze afhankelijk zijn en de contractuele status van die relaties. DORA artikel 28 vereist een register van ICT-derde-partij-dienstverleners. NIS2 artikel 21 vereist supply chain-beveiligingsmaatregelen. Het register is een YAML-bestand in je platform-repo: aanbiedernaam, servicefunctie, kritikaliteitsclassificatie, contractreferentie, exit-planreferentie. Bijgewerkt via PR, elk kwartaal geaudit. De auditor leest de YAML direct.
Controle drie: veerkrachtstesten. Beide regelgevingen vereisen bewijs dat je herstel van verstoringen hebt getest. De platformbijdrage is een game day-programma: elk kwartaal gepland per kritieke service, scenario-gedreven, output gelogd naar een gestructureerd record. Game days als code draaien betekent dat het bewijs automatisch wordt gegenereerd als bijproduct van normale operaties. Het game day-log is het compliance-bewijs.
Controle vier: auditlogboek en toegangscontrole. CloudTrail, Azure Monitor of het equivalent moet alle control-plane-acties vastleggen met onveranderbare bewaring van minimaal 3 jaar voor DORA. Alle menselijke toegang tot productie moet via een gefedereerde identiteitsprovider met tijdsgebonden referenties verlopen. Geen gedeelde wachtwoorden, geen langdurige toegangssleutels. Het toegangscontrolemodel moet controleerbaar zijn: wie heeft toegang tot wat en wanneer hebben ze die voor het laatst gebruikt.
Waar NIS2 en DORA uiteenlopen op het platform
DORA stelt strengere eisen aan ICT-aanbieders-relaties dan NIS2. DORA artikel 30 vereist contractuele bepalingen in elke ICT-derde-partij-overeenkomst over audittoegansrechten, ondersteuningsverplichtingen bij incidenten en exit-assistentie. Als je infrastructuur een beheerde dienst gebruikt van een aanbieder die deze voorwaarden niet accepteert, vereist DORA-compliance dat je migreert of onderhandelt. Dit is een commerciële en juridische kwestie, maar het platformteam moet weten welke aanbieders in scope zijn.
NIS2 stelt sectorspecifieke controles die DORA niet stelt. Als je organisatie kritieke infrastructuurdiensten exploiteert, vereist NIS2 artikel 21 supply chain-beveiliging die zich uitstrekt tot het beoordelen van de beveiligingspraktijken van je softwareleveranciers en -aanbieders, niet alleen je ICT-dienstverleners.
Voor mid-market-bedrijven die cloudplatforms bouwen voor financiële dienstverlening: DORA's ICT-risicokader is de meest prescriptieve standaard. Voor mid-market-bedrijven in zorg, energie of publieke sector: NIS2 is de meest veeleisende. De vier platformcontroles hierboven voldoen aan beide op het overlappende vlak. De afwijkende vereisten worden het best behandeld met juridisch advies naast het platformwerk.
"Als je platform OpenTelemetry draait, een service-catalogus onderhoudt, game days uitvoert en control-plane-acties logt, ben je 70 tot 80 procent compliant met de platformcontroles van NIS2 en DORA."
Maikel Vlasman / Cloud Architect
De 90-daagse implementatievolgorde
Weken 1 tot 4: audit wat je hebt. Breng je huidige monitoring en alertering in kaart tegen de incidentpijplijn-vereisten. Lijst je kritieke ICT-afhankelijkheden op tegen de vereisten voor het afhankelijkheidsregister. Identificeer de gaten. De meeste teams stellen vast dat de monitoring toereikend is en de logging bestaat, maar de documentatie ontbreekt of verouderd is.
Weken 5 tot 8: bouw de ontbrekende controles. Dit betekent doorgaans: de regelgevingsstap toevoegen aan het on-call-runbook, het afhankelijkheidsregister in YAML schrijven en naar de platform-repo committen, en de eerste game day plannen als die de afgelopen 90 dagen niet heeft plaatsgevonden.
Weken 9 tot 12: genereer en bewaar het bewijs. Voer de eerste game day uit. Exporteer het afhankelijkheidsregister. Exporteer de auditlog-bewaarconfiguratie. Dit is het evidence pack: een map in de platform-repo met een README die elk artefact koppelt aan het specifieke artikel en lid dat het voldoet.
Vanaf week 12: handhaaf de cadans. Kwartaallijkse game days. Kwartaallijkse afhankelijkheidsregister-review. Jaarlijkse toegangscontrole-audit. Het bewijs genereert zichzelf vanuit het platform. Compliance wordt een bijproduct van het correct draaien van het platform, niet een afzonderlijk jaarlijks project.