Als je software schrijft binnen een bank, verzekeraar, beleggingsonderneming, betaalinstelling of een andere financiële entiteit die valt onder DORA (Digital Operational Resilience Act, Verordening (EU) 2022/2554), is de verordening al van kracht voor je organisatie. Als je ICT-diensten levert die door deze entiteiten worden gebruikt, is de situatie duidelijker: DORA houdt direct toezicht op aangewezen kritieke ICT-derdepartijaanbieders, terwijl andere aanbieders voornamelijk voldoen aan DORA-verplichtingen via de contracten en due diligence die hun klanten (financiële entiteiten) doorvoeren. In veel openbare uitleg wordt DORA behandeld als een probleem voor de raad van bestuur en risicofuncties: ICT-risicokaders, veerkrachttesten, incidentrapportage aan toezichthouders, essentiële contractuele bepalingen. Die interpretatie is correct voor het grootste deel van de verordening. Voor het deel dat een engineer daadwerkelijk implementeert, is deze onvolledig.
Het onvolledige deel zijn de veerkrachtbeslissingen die in de repository leven: een circuit breaker die als "dode code" wordt verwijderd, een back-upretentie die wordt verkort om opslag te besparen, een nieuwe fraude-API die in het betalingspad wordt geïntegreerd zonder registratie, een gezondheidscontrole of waarschuwingsregel die wordt verwijderd omdat deze te veel ruis veroorzaakte. Elk van deze wijzigingen ziet eruit als normale engineering. Elk verzwakt echter een verplichting die DORA op articelniveau benadrukt. Deze handleiding is bedoeld voor ontwikkelaars die willen weten welke artikelen in een pull request verschijnen, welke vorm deze wijzigingen aannemen en hoe ze deze kunnen opsporen zonder elke review in een juridisch memo te veranderen.
Voor wie deze handleiding bedoeld is (en voor wie niet)
Je bent de doelgroep als je code schrijft voor een financiële entiteit die valt onder DORA, of als je product een ICT-dienst is die door deze entiteiten in productie wordt gebruikt (of je nu een aangewezen kritieke ICT-derdepartijaanbieder bent onder direct toezicht, of een aanbieder die voornamelijk via klantcontracten gebonden is). De reikwijdte en aanwijzing onder de verordening zijn juridische en entiteitsclassificatievragen, geen zaken die een code review beslist. Als je compliance- of juridisch team al heeft bevestigd dat DORA van toepassing is (direct of via contract), gaat deze handleiding over het technische deel van die verplichting. Als je niet zeker weet of je binnen de reikwijdte valt, stop dan hier en vraag het hen: een verkeerd antwoord betekent óf onderinvestering in een echte verplichting, óf overmatige aanpassing aan een verordening die niet van toepassing is.
Dit is geen vervanging voor een ICT-risicobeheerkader, een veerkrachttestprogramma, een incidentrapportageproces, een register van derde partijen of essentiële contractuele bepalingen met ICT-aanbieders. heygrc voert geen van deze taken uit. Het is ontworpen om het moment te signaleren waarop een wijziging in een pull request een veerkrachtgerelateerde controle verzwakt of introduceert die deze programma's als nog steeds bestaand aannemen.
De artikelen die daadwerkelijk in een diff verschijnen
Het grootste deel van DORA zal nooit als een regel applicatiecode verschijnen. Wat wel in een pull request terechtkomt, is geconcentreerd in een korte lijst van artikelen. Art. 9 (bescherming en preventie): een wijziging verzwakt toegangcontrole, encryptie, netwerksegmentatie of een andere maatregel die een kritieke ICT-functie geïsoleerd houdt. Art. 10 (detectie): logging, waarschuwingen of anomaliedetectie waar een entiteit op vertrouwt om ICT-problemen tijdig op te merken, wordt verwijderd of uitgeschakeld. Art. 11 (reactie en herstel): een retry, circuit breaker, failover, timeout of herstelpad dat een kritieke functie tijdens een verstoring actief hield, wordt als opschoning verwijderd. Art. 12 (back-up en herstel): de reikwijdte, frequentie of herstelhulpmiddelen van back-ups worden verminderd, of een nieuwe kritieke opslag wordt geïmplementeerd zonder back-uppad. Art. 17 tot en met 19 (ICT-gerelateerd incidentbeheer, classificatie en rapportage): een wijziging verwijdert identificatie, bijhouden, logging of registratie van ICT-gerelateerde incidenten (Art. 17), of verwijdert velden en signalen waar het classificatieproces (Art. 18) en de rapportage van grote incidenten (Art. 19) van afhankelijk zijn. Art. 28 (algemene beginselen voor ICT-derdepartijrisico's), inclusief het register van informatie krachtens Art. 28(3): een nieuwe contractuele regeling voor een ICT-dienst wordt in productie geïntegreerd zonder te worden geregistreerd in het register dat alle dergelijke regelingen moet omvatten. Art. 30 (essentiële contractuele bepalingen): de regeling wordt behandeld als "nog een SaaS-klant" zonder verwijzing naar het hoofdstuk contractuele bepalingen voor ICT-diensten, wat een afzonderlijke verplichting is van het register en governancewerk krachtens Art. 28.
Deze uitleg zijn eenvoudige, voor ingenieurs bedoelde samenvattingen, niet de letterlijke tekst van de verordening. De diepgaande analyse van het kader op /frameworks/dora doorloopt de veerkrachtartikelen met de wijzigingsvormen die deze triggeren. De pagina's met controles in code voor Art. 9 (bescherming en preventie) en Art. 11 (reactie en herstel) tonen uitgewerkte diffs voor afgevlatte segmentatie en een verwijderde circuit breaker. Deze handleiding richt zich op de cluster artikelen die productontwikkelaars het meest verrassen: Art. 28 en Art. 30, wanneer een handige SaaS-aanroep een productie-ICT-afhankelijkheid wordt.
Uitgewerkt voorbeeld: een schone client die een ongetraceerde ICT-derde partij wordt
Een betalingsteam wil snellere fraudebeslissingen. Een ontwikkelaar opent een pull request die een traag intern regelsysteem vervangt door een getypeerde HTTP-client voor een nieuwe externe "FraudScore" API. De client heeft timeouts, retries met backoff, gestructureerde foutafhandeling en een feature flag. Tests dekken de happy path en 5xx-fouten. De reviewopmerkingen gaan allemaal over latentiebudgetten en of de flag standaard aan of uit staat. Niets in de diff ziet er verkeerd uit als software: het is een goed opgebouwde integratie.
Wat de PR niet bevat, is een update voor het register van informatie over contractuele regelingen voor ICT-diensten (Art. 28(3)), of een verwijzing naar de essentiële contractuele bepalingen van Art. 30 die van toepassing zijn op ICT-dienstregelingen in het algemeen (Art. 30(1) en (2)). Geen van beide wacht tot iemand besluit dat de aanroep "kritiek" is. Afzonderlijk, als deze fraudecontrole op het pad zit dat betalingen autoriseert, kan de regeling een kritieke of belangrijke functie ondersteunen, wat extra verplichtingen kan triggeren, waaronder de exit-strategievereisten van Art. 28 en de concentratierisicobeoordeling van Art. 29, en de versterkte contractuele bepalingen in Art. 30(3). Het eerst implementeren van de client en later het register invullen is hoe een productieafhankelijkheid onzichtbaar wordt voor het programma dat elke ICT-dienstregeling moet bijhouden.
Dit is de vorm die een compliance-bewuste review moet opsporen: niet "is de HTTP-client correct", maar "heeft deze wijziging een ICT-dienst van een derde partij geïntroduceerd of vervangen waarvan de contractuele regeling volgens Art. 28(3) in het register moet staan". Een bevinding die Art. 28 / Art. 28(3) citeert (en Art. 30 waar contractuele bepalingen het probleem zijn) keurt de leverancier niet goed, stelt het contract niet op, classificeert de kritikaliteit niet of beslist niet over concentratierisico. Het maakt de verplichting van de derde partij zichtbaar terwijl de auteur de PR nog open heeft, zodat de register-, classificatie- en contractstappen tegelijk met de code kunnen verlopen in plaats van weken later, wanneer productieverkeer al afhankelijk is van de nieuwe aanbieder.
Waar je op moet letten tijdens de review zonder DORA-jurist te worden
Wanneer een wijziging een uitgaande afhankelijkheid toevoegt of vervangt die in productie zal draaien voor een financiële functie, stel dan drie technische vragen: is de contractuele regeling voor deze ICT-dienst al geregistreerd in ons register van informatie (Art. 28(3)), inclusief hoe de dienst is geclassificeerd en of deze een kritieke of belangrijke functie ondersteunt; zou een storing van deze aanroep een financiële dienst zodanig aantasten dat kritikaliteit en exit-planwerk van toepassing kunnen zijn; en wordt in dezelfde PR (of een gekoppelde wijziging) de interne checklist of ticket bijgewerkt die je risicoteam gebruikt wanneer een nieuwe ICT-regeling wordt geïmplementeerd, inclusief werk aan contractuele bepalingen van Art. 30 als dat is hoe je organisatie dit bijhoudt. Als het antwoord op de registervraag "nee" of "onbekend" is, is de functie onvolledig vanuit DORA-derdepartijperspectief, zelfs als deze wel compleet is als code. Kritikaliteit bepaalt hoeveel extra werk volgt; het beslist niet of de regeling in het register hoort.
Voor veerkrachtmaatregelen die je al beheert, is de aanwijzing anders: een PR waarvan de samenvatting "opschonen", "dode code verwijderen" of "kosten verlagen" is, die retries, failovers, back-ups, isolatieregels of detectiehooks op een kritiek pad verwijdert. Vraag of het systeem nog voldoet aan de veerkrachteigenschap die die maatregel bood. Art. 9, 10, 11, 12 en de incidentbeheercluster in Art. 17 tot en met 19 zijn de gebruikelijke verwijzingen als het antwoord nee is. Je hoeft de verordening niet te citeren. Je moet wel de eigenschap noemen en weigeren te mergen tot iemand verantwoordelijkheid neemt voor het herstellen van de maatregel of het documenteren van een geaccepteerde wijziging via je echte wijzigingsproces.
Waar heygrc past, en de eerlijkheidsgrens
heygrc is ontworpen om elke pull request te lezen tegen de kaders die je hebt geselecteerd, inclusief DORA als je dit hebt ingeschakeld, en om het artikel te benoemen dat een wijziging lijkt aan te raken (bijvoorbeeld Art. 28(3) voor een nieuwe ICT-dienstregeling die ontbreekt in het register, Art. 11 voor een verwijderd herstelpad). De bevinding is een reviewopmerking met het bijbehorende artikel, zodat de auteur en reviewer met volledige informatie kunnen beslissen. Het certificeert geen DORA-naleving, vervangt je ICT-risicokader niet, voert je veerkrachttesten niet uit, doet geen incidentrapportage, onderhoudt je register van derde partijen niet en stelt geen contractuele bepalingen van Art. 30 op. Dat blijven menselijke en organisatorische taken. Een groene heygrc-review is geen toezichthoudende goedkeuring; het is een vroege, op artikelen gebaseerde signalering dat een wijziging iets heeft aangeraakt waar deze programma's om geven.
Als je team al een bug- of kwaliteitsreviewer gebruikt op dezelfde pull request, houd deze dan aan. Die tools vragen of de code correct en veilig is. DORA-vragen gaan over operationele veerkracht en ICT-derdepartijverplichtingen. De FraudScore-client hierboven kan schoon, getypeerd en goed getest zijn en toch Art. 28(3) onvolledig laten. Voer beide lagen uit; geen van beide vervangt de andere.