Softwareontwikkelingsuitdagingen in de financiële sector aanpakken

Als je de engineering leidt bij een bank, verzekeraar of betaalbedrijf in de EU, dan is de grond verschoven op 17 januari 2025. Dat is de dag waarop de Digital Operational Resilience Act (DORA) juridisch van toepassing werd, en daarmee zijn een reeks vage "compliance"-ambities omgezet in harde, juridische verplichtingen op softwareniveau met verantwoording tot op bestuursniveau. De uitdagingen in softwareontwikkeling voor de financiële sector zijn in naam niet veranderd, maar wel in gewicht. Dit is een briefing over de drie uitdagingen die de leveringsplanning nu domineren: regulatoire weerbaarheid als eigenschap van code, het beheersen van een open-source supply chain die je niet meer in de hand hebt, en snel leveren zonder stilzwijgend stabiliteit in te ruilen.

DevOps-levenscyclusdiagram met de fasen plannen, bouwen, testen, releasen, deployen, beheren en monitoren die in elkaar terugkoppelen voor gereguleerde softwarelevering

Regulatoire compliance is nu een engineering-eis, geen juridische bijzaak

Het oude denkkader behandelde regelgeving als een poort die het juridisch team bezat en waar engineering doorheen liep. DORA breekt die overdracht af. De verordening geldt voor vrijwel elke financiële entiteit in de EU, waaronder banken, verzekeraars, betaal- en e-geldinstellingen, beleggingsondernemingen en aanbieders van cryptodiensten, en schrijft ICT-risicobeheer voor met expliciete bestuurlijke verantwoording, toezicht op externe ICT-leveranciers, melding van grote incidenten en threat-led penetratietesten (Mayer Brown, 2025). Lees die lijst als een systeemeisendocument, want dat is precies wat het is. "Toezicht op externe ICT-leveranciers" betekent dat je een actuele, accurate inventaris nodig hebt van elke leverancier en afhankelijkheid in je kritieke pad. "Melding van grote incidenten" binnen een krappe termijn betekent dat je observability- en on-call-tooling snel een verslag van regulator-niveau moeten kunnen produceren, niet een postmortem die een week later uit het geheugen is opgeschreven.

Wat vroeger vage strafbepalingen waren, is nu een concreet bedrag op tafel. Onder DORA kan niet-naleving leiden tot boetes tot 2% van de totale wereldwijde jaaromzet, of EUR 10 miljoen voor individuen (SureCloud, 2025). Dat cijfer is de reden waarom "we hardenen het later wel" geen verdedigbaar standpunt meer is. De praktische zet is om compliance een eigenschap van code te maken: codeer controls als policy-as-code in de pipeline, behandel je software bill of materials en leveranciersregister als levende artefacten die de build-tooling onderhoudt, en koppel incidentdetectie aan de meldingstermijn in plaats van aan een kwartaalreview. Weerbaarheidstesten is geen eenmalige auditgebeurtenis; bouw het in de release-cadans zodat het bewijs dat de regulator vraagt een bijproduct is van hoe je toch al levert.

Open source is nu het platform, en governance is het lastige deel

De verschuiving naar open source in de financiële sector is geen trend meer om over te discussiëren; het is het substraat waarop alles draait. Meer dan 85% van de banken, verzekeraars en financiële dienstverleners breidt hun open-source-gebruik uit (FINOS 2024 State of Open Source in Financial Services). Voor een engineering director is de interessante bevinding in dat onderzoek niet de adoptiegraad, maar de governance-kloof. Bedrijven met een Open Source Program Office of een zichtbare open-source-leider stimuleren veel vaker zowel het gebruik (62% tegenover 29%) als de bijdrage, terwijl het handhaven van security-beleid en regulatoire compliance een van de meest gerapporteerde uitdagingen blijft. Vertaald: het verschil tussen veilig en roekeloos open-source-gebruik is organisatorisch, niet technisch. De teams die winnen, hebben een benoemde eigenaar en een beleid, niet alleen een permissieve licentie om pakketten binnen te halen.

De reden dat dit elk jaar zwaarder weegt, is het dreigingsoppervlak dat die afhankelijkheden vormen. Verwacht werd dat ontwikkelaars in 2024 6,6 biljoen open-source-pakketten zouden downloaden, en Sonatype heeft sinds 2019 704.102 kwaadaardige open-source-pakketten geïdentificeerd, een stijging van 156% in malware jaar-op-jaar (Sonatype 2024 State of the Software Supply Chain). Dezelfde afhankelijkheden waarmee een klein team snel beweegt, zijn de afhankelijkheden waarmee een aanvaller je build-systeem bereikt. In een gereguleerde omgeving, waar DORA je al verplicht toezicht te houden op externe ICT-risico's, is je transitieve afhankelijkheidsgraaf externe ICT-risico. De controls die hieruit volgen zijn weinig glamoureus en niet onderhandelbaar: een gegenereerde SBOM bij elke build, verificatie van herkomst en handtekening van afhankelijkheden, geautomatiseerde vulnerability-gating die de pipeline laat falen in plaats van een ticket aan te maken, en een samengesteld intern register zodat engineers geen ongecontroleerde artefacten rechtstreeks uit publieke mirrors halen. Dit is de concrete inhoud achter het label SecDevOps, en hier betaalt de security-investering zich daadwerkelijk uit.

Snel businesswaarde leveren is een platformprobleem, geen tooling-probleem

Elke financiële instelling wil sneller leveren, en de meeste grijpen naar nieuwe tools om dat te bereiken. Het bewijs uit 2024 stelt dat tooling alleen de verkeerde hefboom is, en in één geval zelfs actief contraproductief. Het 2024 DORA Accelerate State of DevOps report constateerde dat een toename van 25% in AI-adoptie correleert met een geschatte daling van 1,5% in software delivery throughput en verminderde leveringsstabiliteit, ook al verhoogt AI de individuele ontwikkelaarsproductiviteit (2024 Accelerate State of DevOps Report, via InfoQ). Dat is de centrale spanning waar de voorganger van dit artikel naar verwees zonder die te kwantificeren: snellere individuen staan niet gelijk aan een sneller systeem. Meer code die sneller wordt gegenereerd en in een delivery-pipeline wordt gevoerd die het niet veilig kan reviewen, testen en releasen, vergroot de batchgrootte en wachttijd in plaats van die te verkleinen.

Hetzelfde rapport merkt op dat slechts circa 19% van de teams elite delivery-prestaties haalt, met deployen on demand en lead times van minder dan een dag. Wat hen onderscheidt is zelden één enkele tool; het is platform engineering en developer self-service die frictie weghalen op het pad naar productie. Voor een gereguleerd finance-team is de synthese helder: investeer in het platform waarmee engineers een compliant, geteste, observeerbare wijziging kunnen leveren zonder een reeks handmatige overdrachten. Bouw de compliance-controls, de SBOM-generatie, de security-gates en de deployment-automatisering in een paved road, zodat het juiste doen ook het snelle doen is. Zo houden snelheid en stabiliteit op een afruil te zijn. Je balanceert ze niet door af te remmen; je balanceert ze door het veilige pad het standaardpad te maken.

Wat dit betekent voor je roadmap

De drie uitdagingen komen samen in één discipline: behandel regulatoire weerbaarheid, supply-chain-security en leveringssnelheid als eigenschappen van één platform in plaats van drie aparte werkstromen die door drie aparte teams worden beheerd. DORA geeft je de eisen, de open-source-data geven je het dreigingsmodel, en het DevOps-onderzoek geeft je het leveringsmodel. Bij Expeditious Software richten onze DevOps-diensten en freelance DevOps-expertise zich precies op deze integratie: we verankeren security en compliance in de pipeline zodat gereguleerde financiële software snel wordt geleverd omdat ze is gebouwd om auditeerbaar te zijn, niet ondanks dat.