DORA ICT-risicobeheer op Azure: een praktische gids voor Nederlandse financiële instellingen

Ik beoordeel Azure-omgevingen voor de kost. In elk DORA-gesprek dat ik voer gaat het eerste half uur over beleid, en pas daarna over de omgeving. Dat is precies de verkeerde volgorde.

Want beleid schrijven kan iedereen. Het bewijs dat het beleid ook echt draait, dat is het werk.

DORA ICT-risicobeheer verplicht een Nederlandse financiële instelling tot een gedocumenteerd kader (Artikelen 5 tot en met 16), een actueel ICT-assetregister, een eigen beoordeling van je ICT-derde partijen, met Microsoft vooraan als je op Azure draait, en aantoonbare continuïteit en back-up. Op Microsoft Azure vertaalt elk van die eisen zich naar een concrete dienst en een concreet bewijsstuk. Dit stuk gaat over die vertaling. Geen samenvatting van de verordening, wel wat je in je eigen omgeving inricht en daarna kunt laten zien.

Het risicobeheerkader, artikel voor artikel

Vijf werkwoorden dragen het risicobeheerkader: identificeren, beschermen, detecteren, reageren, herstellen. Artikel 5 legt de eindverantwoordelijkheid bij het bestuur, niet bij de ICT-afdeling. Artikel 6 beschrijft het kader zelf.

Losse controles volstaan niet. Artikel 6 vraagt een samenhangend geheel van strategieën, beleidslijnen, procedures en hulpmiddelen die de ICT-systemen beschermen. Artikel 7 stelt eisen aan die systemen en hulpmiddelen. Artikel 8 vraagt dat je alle ICT-ondersteunde bedrijfsfuncties en onderliggende activa in kaart brengt. Artikel 9 regelt bescherming en preventie, Artikel 10 detectie, Artikel 11 respons en herstel, en Artikel 12 back-up en herstelprocedures.

Elk van die artikelen heeft een tegenhanger in je Azure-configuratie. En daar zit het venijn. Het kader op papier is niet het kader. Het kader is wat er daadwerkelijk in de omgeving draait, en dat verschil is exact wat een audit blootlegt. Zie Azure-configuratiedrift voor waarom de gedocumenteerde en de werkelijke toestand uit elkaar lopen.

Het assetregister uit de werkelijke omgeving

Het bestandsformaat interesseert DORA niet; een spreadsheet mag. Wat niet mag is een inventaris die achterloopt, want Artikel 8(6) vraagt bijwerken bij elke ingrijpende wijziging. Daar gaat een handmatige spreadsheet in Azure bijna altijd op onderuit. Azure-omgevingen veranderen dagelijks: nieuwe resources, gewijzigde configuraties, verwijderde diensten. Een register dat je één keer per jaar bijwerkt, is binnen weken achterhaald.

“Ja maar wij hébben een assetregister, dat staat netjes in SharePoint.”

Dat geloof ik meteen. De vraag is niet of het bestaat. De vraag is wanneer het voor het laatst is vergeleken met de abonnementen zelf, en of iemand die vergelijking kan reproduceren terwijl een toezichthouder meekijkt. Bijna altijd is het antwoord daarop stil.

Azure Resource Graph lost dat op door de inventaris rechtstreeks op de werkelijke omgeving te bevragen. Elke virtuele machine, elke Azure SQL Database, elk opslagaccount, met locatie, tags en configuratie. Dat is de basis voor wat Artikel 8 vraagt: alle ICT-ondersteunde bedrijfsfuncties, rollen en activa identificeren (8(1)), en de inventaris bijwerken periodiek en bij elke ingrijpende wijziging (8(6)). Resource Graph ziet alleen wat jouw toegang ziet, en weet niet welke bedrijfsfunctie erop draait.

Artikel 8(4) gaat een stap verder en vraagt de afhankelijkheden tussen activa. Welke functie draait op welke resource, en waarvan hangt die af? Resource Graph toont de resources. De afhankelijkheidsanalyse, dus welke kritieke functie leunt op welke Azure SQL Database of welke Microsoft Entra ID-configuratie, tilt het register van een lijst naar een risicobeeld.

Dat register is het fundament onder Artikel 28 en Artikel 12. Zonder actuele inventaris is geen van beide aantoonbaar.

(Ik heb zelf jarenlang zo’n handmatig register verdedigd als “goed genoeg voor nu”. Het was op de dag van oplevering al niet meer waar. Slim, hè.)

Microsoft als kritieke ICT-derde partij

Artikel 28(4) vraagt je vóór elk contract te beoordelen of de dienst een kritieke of belangrijke functie ondersteunt, en of hij je concentratierisico vergroot. Artikel 29 werkt dat concentratierisico uit, inclusief de vraag of de aanbieder te vervangen is. Draai je identiteit, platform en kantoorautomatisering bij Microsoft, dan valt die beoordeling zelden mild uit.

Neem identiteit. Microsoft Entra ID authenticeert de hele organisatie. Valt het uit, dan authenticeert niets wat ervan afhangt. Tel bij je eigen tenant eens na hoeveel dat is. Een kritieke functie met zeer lage substitueerbaarheid.

Geen grensgeval.

Een voorbeeldbeoordeling, voor een bank die haar kerntransacties op AKS draait:

Microsoft-dienst	Ondersteunde functie	Substitueerbaarheid	Criticaliteit
Microsoft Entra ID	Identiteit en toegang	Zeer laag	Kritiek
Azure Kubernetes Service	Kerntransactieverwerking	Laag	Kritiek
Azure SQL Database	Systeem van registratie	Laag	Kritiek
Microsoft 365 (Exchange Online)	Interne communicatie	Matig	Belangrijk

Eén regel “Microsoft Corporation” in je register volstaat niet. Artikel 28(3) vraagt een register van alle contractuele afspraken voor ICT-diensten. De toezichthouder kan het geheel of delen ervan opvragen, en je rapporteert jaarlijks over nieuwe afspraken. Dat register werkt op het niveau van de diensten die functies ondersteunen. Artikel 28(4) vraagt daarbovenop bij elk nieuw contract of het je concentratierisico vergroot, en Artikel 28(8) een exitstrategie voor elke dienst onder een kritieke of belangrijke functie. Probeer die laatste maar eens te schrijven voor Entra ID.

Het concrete voorbeeld staat in Microsofts eigen incidentrapport van 30 augustus 2023: een stroomstoring legde de koeling in de regio Australia East stil, en meerdere diensten gingen mee onderuit. Geen Nederlandse regio, wel hetzelfde mechanisme. Identiteit, rekenkracht en opslag falen niet onafhankelijk als ze dezelfde regio en dezelfde leverancier delen. Zie DORA Artikel 28 en Microsoft als kritieke derde partij voor de volledige opbouw van het register.

Continuïteit en back-up onder Artikel 12

Drie diensten dragen dit op Azure: Azure Backup voor gegevensbescherming, Azure Site Recovery voor uitwijk van werklasten, en geo-redundante opslag voor herstel over regio’s heen. Elk levert een eigen, exporteerbaar bewijsstuk. Artikel 12(1) vraagt back-upbeleid en herstelprocedures. Artikel 12(2) vraagt dat je back-up en herstel periodiek test, en Artikel 11(6) dat je de continuïteits- en herstelplannen minstens jaarlijks test.

RTO en RPO horen per werklast in het beleid, niet als één globaal getal. Een betaalmotor en een interne wiki delen geen hersteldoel. Azure Site Recovery repliceert ondersteunde Azure Virtual Machines continu. De RPO die je daadwerkelijk haalt hangt af van de schrijfbelasting, en die meet je in de test, niet in de documentatie. Azure SQL Database biedt point-in-time herstel binnen de bewaartermijn, plus actieve geo-replicatie naar een secundaire kopie. Die replicatie is asynchroon: bij een failover kun je de laatste transacties kwijt zijn, dus ook daar hoort een gemeten getal in het beleid.

Het bewijs is niet het configuratiescherm. Het is het testrapport.

Een test-uitwijk in Azure Site Recovery levert dat rapport: de gerepliceerde werklast start in een geïsoleerd netwerk, wordt gevalideerd en weer afgebroken. Dat is het periodieke testen van Artikel 12(2), mits je vastlegt dat de applicatie na de uitwijk ook werkte en welke RTO en RPO je haalde. Een geslaagde job is nog geen gevalideerd herstel. Hoe vaak? DORA zegt “periodiek”, met minstens jaarlijks voor de plannen (Artikel 11(6)). Voor kritieke functies kies ik een kwartaal. Dat is mijn keuze, geen wettelijke eis. Geo-redundante opslag van West Europa naar Noord-Europa geeft je een tweede kopie in een andere regio. Dat is nog niet de scheiding van Artikel 12(3): wie met eigen systemen herstelt, doet dat op systemen die gescheiden zijn van de bron. De Nederlandse tekst zegt ‘fysiek of logisch’, de Engelse ‘physically and logically’; ik zou op beide sturen. Een replica onder hetzelfde opslagaccount en dezelfde beheerrechten is fysiek gescheiden, maar logisch niet. Zie DORA Artikel 12 op Azure voor de exacte bewijsstukken per dienst.

Welk bewijs komt er op tafel?

Reproduceerbaar, actueel, en herleidbaar tot de werkelijke omgeving. Concreet: een actueel ICT-assetregister, een register van ICT-derde partijen, en gedateerde testrapporten van back-up en herstel. DNB en de AFM houden toezicht op DORA-naleving; voor de grootbanken ligt het directe toezicht bij de ECB. DNB vroeg in maart 2026 de registers op bij de instellingen waarvoor zij bevoegd is, los van de jaarlijkse melding van nieuwe afspraken.

Het verschil zit tussen “wij hebben beleid” en “wij tonen het bewijs binnen minuten”. Daar zit de volwassenheid van een ICT-risicoprogramma, en verder nergens. Een assetregister dat verzoend is met de werkelijke abonnementen, waarin elke kritieke Azure SQL Database ook echt terugkomt, laat controle zien. Een register dat Microsoft één keer noemt zonder uitsplitsing laat het tegendeel zien.

De stukken die je klaar wilt hebben liggen:

• het ICT-assetregister (Artikel 8);
• het register van contractuele afspraken (Artikel 28(3));
• de exitstrategie per kritieke dienst (Artikel 28(8));
• de criticaliteits- en concentratiebeoordeling;
• het meest recente test-uitwijkrapport (Artikel 12(2) en 11(6)).

De verzoening tussen het gedocumenteerde en het werkelijke is het lastigste deel, omdat Azure-omgevingen niet stilstaan. Als je één ding uit dit stuk meeneemt: begin daar, niet bij het beleidsdocument.

Waarom ik hier een tool voor ben gaan bouwen

Ik leverde beoordelingsrapporten op waarin het assetregister van de klant en de werkelijke abonnementen elkaar structureel niet raakten, en de reconstructie daarvan kostte elke keer opnieuw dagen handwerk. Dat werk is saai, foutgevoelig en volstrekt herhaalbaar, wat betekent dat het niet door een mens gedaan hoort te worden. Daarom bouwde ik Platform Architecture Authority: het leest de Azure-omgeving read-only uit en legt naast elkaar wat je registers beweren en wat je abonnementen werkelijk bevatten. Het vervangt het oordeel van de persoon die het ICT-risico bezit niet, het haalt alleen het verzoeningswerk weg waardoor registers verouderen.

De korte versie

• Het risicobeheerkader (Artikelen 5-16) legt de eindverantwoordelijkheid bij het bestuur, niet bij ICT.
• Artikel 8 vraagt een actueel assetregister; Azure Resource Graph levert dat rechtstreeks uit de werkelijke omgeving.
• Of Microsoft diensten levert onder jouw kritieke functies, beoordeel je zelf (Artikel 28(4) en 29); dat staat los van de EU-aanwijzing onder Artikel 31.
• Artikel 12 vraagt back-up en herstel en periodiek testen (12(2)); Artikel 11(6) vraagt de plannen minstens jaarlijks te testen.
• Wat er uiteindelijk op tafel moet komen is reproduceerbaar bewijs, geen beleidsdocumenten.

Veelgestelde vragen

Geldt DORA voor alle Nederlandse financiële instellingen? Voor een breed scala aan entiteiten: banken, betaalinstellingen, verzekeraars, beleggingsondernemingen en kredietinstellingen. De omvang van de verplichtingen is evenredig aan de aard en het risicoprofiel van de instelling. Het risicobeheerkader van de Artikelen 5-16 geldt in beginsel voor alle entiteiten in scope, met een vereenvoudigd kader (Artikel 16) voor een beperkte groep, zoals kleine, niet-verweven beleggingsondernemingen.

Voldoet een spreadsheet als ICT-assetregister onder Artikel 8? Juridisch wel: DORA schrijft inhoud en actualiteit voor, geen bestandsformaat. In de praktijk loopt een handmatige spreadsheet in een omgeving die dagelijks verandert binnen weken achter, en Artikel 8(6) vraagt bijwerken bij elke ingrijpende wijziging. Een inventaris uit Azure Resource Graph is herleidbaar tot wat er werkelijk draait; de koppeling aan bedrijfsfuncties voeg je zelf toe.

Is Microsoft automatisch een kritieke ICT-derde partij onder DORA? Inmiddels wel, op EU-niveau: sinds 18 november 2025 staat Microsoft Ireland Operations Limited op de lijst van aangewezen kritieke derde aanbieders van ICT-diensten (Artikel 31). Dat ontslaat je niet van je eigen beoordeling onder Artikel 28: de aanwijzing zegt dat Microsoft voor de sector kritiek is, niet welke van jóuw functies erop leunen. De eerste bepaal je niet zelf. De tweede voer je zelf uit en documenteer je.

Hoe vaak moet herstel worden getest onder Artikel 12? Artikel 12(2) vraagt periodiek testen van back-up en herstel, zonder frequentie; Artikel 11(6) vraagt de continuïteits- en herstelplannen minstens jaarlijks te testen. Voor kritieke of belangrijke functies verdedig ik een kwartaal. Leg de frequentie, evenredig aan de criticaliteit, vast in het back-upbeleid.

DORA beloont de instelling die het bewijs op orde heeft. Het beleid schrijven is het eenvoudige deel. Het gedateerde, geslaagde testrapport dat herleidbaar is tot je werkelijke Azure-omgeving, dat is het deel dat standhoudt bij onderzoek.