Sebastien Rousseau
Neem contact op ›

Cloud Native Banking in 2026: Kubernetes, DORA, Sovereignty, and the End of the VM vs Container Divide

Cloud native for banks has matured from container adoption to regulated platform engineering: Kubernetes, VM coexistence, data portability, DORA supervision, cloud dependency reviews, and operational resilience now define the architecture.

7 min. leestijd

Cloud-native bankieren in 2026: Kubernetes, DORA, soevereiniteit en het einde van de scheidslijn tussen VM en container

Cloud-native bankieren is in 2026 geen discussie meer over de vraag of banken cloud mogen gebruiken. Het is een gereguleerde platform-engineering-discipline: hoe je kritieke diensten draait over containers, virtuele machines, datafabrics, AI-workloads en cloudleveranciers heen, terwijl je operationele veerkracht aantoont onder DORA (Digital Operational Resilience Act) en vergelijkbare regimes. IBM bestempelt 2026 als de eerste echte toezichtstest van DORA, met cloudafhankelijkheidsbeoordelingen, cyberveiligheidsinspecties, threat-led penetration testing en direct toezicht op kritieke derde partijen (IBM).

Managementsamenvatting / Belangrijkste conclusies

  • DORA heeft het cloudgesprek veranderd. 2026 brengt direct EU-toezicht op kritieke derde partijen en gerichte beoordelingen van de cloudleveranciersafhankelijkheden van banken (IBM).
  • Kubernetes is de platformlaag, niet het hele antwoord. Banken hebben Kubernetes nodig voor elasticiteit, automatisering en AI/ML-workloads (Artificial Intelligence / Machine Learning), maar tegelijk co-existentie met VM's (Virtual Machines), omdat core banking, betalingen, trading en risicosystemen nog steeds op geharde gevirtualiseerde estates draaien (Red Hat).
  • De scheidslijn tussen VM en container vervaagt. Red Hat positioneert OpenShift en Portworx als een uniform model waarin VM's en containers beleid, data, back-up, disaster recovery en governance-controls delen (Red Hat).
  • Cloudsoevereiniteit is nu een ontwerpbeperking. Banken zetten soevereiniteit in om jurisdictionele controle, operationele autonomie, sleutelbeheer, datalocatie en cloudconcentratierisico te beheersen (Red Hat).
  • AI heeft cloud-native urgent gemaakt. Fraudedetectie, liquiditeitsanalyse, realtime personalisatie en toezichtsrapportage vragen steeds vaker elastische rekenkracht dicht bij gevoelige data (Red Hat).
  • Een exitstrategie is geen pdf. Onder hedendaagse toezichtsverwachtingen hebben banken geteste portabiliteit, afhankelijkheidskaarten, contractueel bewijs, herstelprocedures en realistische migratiepaden voor kritieke functies nodig.
  • Het architectuurdoel is gecontroleerd cloud-native. Het winnende bankplatform geeft ontwikkelaars selfservice-levering, terwijl het audit, encryptie, dataresidentie, veerkrachttesten, functiescheiding en controles op derde partijen automatisch afdwingt.

Waarom 2026 het toezichtsjaar voor cloud-native is #

DORA is van toepassing sinds januari 2025, maar in 2026 wordt de toezichtsmacht pas echt zichtbaar. IBM merkt op dat de eerste lijst van kritieke derde partijen in november 2025 is aangewezen en dat 2026 directe betrokkenheid brengt van de Europese toezichthoudende autoriteiten, contractbeoordelingen, inspecties ter plaatse en analyses van cloudafhankelijkheid (IBM).

Daarmee verschuift de bewijslast. Een bank kan niet langer beweren dat een clouduitval enkel een leveranciersprobleem is. De financiële instelling blijft verantwoordelijk voor de veerkracht van kritieke functies, ook als die functies afhankelijk zijn van hyperscalers, SaaS-leveranciers (Software-as-a-Service), dataplatformen en managed-securitydiensten.

De basislijn voor cloud-native bankieren in 2026 #

1. Kubernetes als operationele laag #

Kubernetes biedt banken deployment-automatisering, elasticiteit, beleidsafdwinging, containerorkestratie en een gemeenschappelijke abstractie over private cloud, public cloud en soevereine omgevingen. Voor nieuwe workloads — vooral AI-gedreven fraudedetectie, realtime personalisatie, liquiditeitsanalyse en toezichtsrapportage — is dit de natuurlijke control plane geworden (Red Hat).

De fout is om Kubernetes als bestemming te zien. Voor banken is het de substraatlaag onder een beheerst ontwikkelaarsplatform.

2. Convergentie van VM en container #

De meeste banken kunnen het kernlandschap niet snel herschrijven. Betaalengines, handelssystemen, kredietscoring, risicomodellen en core-bankingplatformen blijven afhankelijk van geharde VM-estates. Red Hat stelt dat banken een uniform platform nodig hebben waarop VM's en containers samen kunnen draaien, met minder dubbele architectuur en uitgelijnde controles voor beleid, opslag, back-up en herstel (Red Hat).

Dit is de praktische brug tussen legacy-veerkracht en cloud-native snelheid. Banken kunnen aanpalende diensten als eerste verplaatsen, data-afhankelijke AI-workloads colokeren en brittele herschrijvingen in kritieke systemen vermijden.

3. DORA-klare operationele veerkracht #

IBM zegt dat de toezichtsprioriteiten voor 2026 onder meer omvatten: opvolging van tekortkomingen op het gebied van ICT-beveiliging (Information and Communication Technology) en uitbesteding, on-site-inspecties voor cyberveiligheid en risico op derde partijen, threat-led penetration testing, beoordelingen van ICT-changemanagement en analyses van cloudafhankelijkheid (IBM).

Veerkracht moet dus toetsbaar zijn. Architectuurdiagrammen volstaan niet. Banken hebben bewijs nodig uit failover-oefeningen, incidentsimulaties, back-up-restores, afhankelijkheidskaarten, hersteltijdtesten en governance-workflows.

4. Soevereiniteit als platformcapaciteit #

Cloudsoevereiniteit is meer dan dataresidentie. Het omvat juridische controle, operationele controle, controle over encryptiesleutels, jurisdictie van supportpersoneel, workloadplaatsing en de mogelijkheid om kritieke diensten te continueren wanneer een wereldwijde leverancier of geopolitiek proces verstoring veroorzaakt. Red Hat omschrijft soevereiniteit als jurisdictionele controle en operationele autonomie voor banken die te maken hebben met uiteenlopende regelgeving, zoals GDPR (General Data Protection Regulation), DORA en nationale cloudregels (Red Hat).

De cloud-native consequentie is dat workloadrouting, secretsbeheer, sleutelbeheer, dataclassificatie en beleidsafdwinging programmeerbaar moeten zijn.

De bankplatformstack #

Laag voor ontwikkelaarservaring #

Een cloud-native platform van bankgrade niveau moet geplaveide wegen aanbieden: golden paths, templates, dienstcatalogi, geautomatiseerde deployment-pipelines, observability-defaults, policy-as-code, standaard secretsintegratie en goedgekeurde datapaden. Ontwikkelaars zouden niet voor elke release met elke controle-eigenaar moeten hoeven onderhandelen.

Het platform moet het compliant pad het snelste pad maken. Dat is het enige model dat schaalt over duizenden diensten.

Controlelaag #

De controlelaag omvat identiteit, toegangsbeheer, functiescheiding, encryptie, sleutelbewaring, netwerkbeleid, image-signing, software bill of materials, kwetsbaarheidspoorten, runtime-security, logging en bewijsgeneratie. Hier worden DORA, NIS2 (Network and Information Security Directive 2), GDPR, uitbestedingsregels en interne modelrisicobeleidsregels uitvoerbare controles.

Dit is waar veel banken falen. Ze nemen containers in gebruik, maar laten controles als handmatige goedkeuringen buiten het platform staan.

Datalaag #

Stateful workloads zijn het lastigste onderdeel van cloud-native bankieren. Het argument van Red Hat voor convergentie tussen VM en container leunt zwaar op een uniforme datafabric en beleidsgedreven back-up, replicatie, failover en herstel over VM's en containers heen (Red Hat).

Voor banken moet de datalaag drie vragen beantwoorden: waar staat de data, wie beheert de sleutels en hoe herstelt de dienst zich als de infrastructuur uitvalt?

Architectuurtabel: cloud-native voor banken #

Capaciteit Cloud-native patroon Bancaire controle-eis Faalmodus
Applicatielevering Kubernetes, GitOps, templates Functiescheiding, changebewijs, rollback Snelle, maar niet-auditeerbare releases
Co-existentie met legacy Uniform VM/container-platform Beleidsconsistentie en migratiecontrole Dubbele estates met dubbel risico
Datadiensten Stateful operators en datafabric Residentie, back-up, immutabiliteit, geteste restore Stateless platform met stateful fragiliteit
Veerkracht Multi-zone, multi-region, failover DORA-bewijs en kritieke-functiekaart Clouduitval afgedaan als leveranciersexcuus
Soevereiniteit Beleidsgebaseerde workloadplaatsing Bewijs van jurisdictie en sleutelbeheer Residentie zonder operationele autonomie
AI-workloads Elastische compute dicht bij data Modelgovernance, dataminimalisatie, audit Gevoelige data verplaatst naar niet-goedgekeurde AI-diensten

Wat dit betekent per instellingstype #

Universele tier-onebanken #

Tier-onebanken moeten beheerste interne platformen bouwen over meerdere clouds, met strikte policy-as-code, dataclassificatie en workloadplaatsing. Ze hebben voldoende schaal om platform-engineering te rechtvaardigen en toezichthouders zullen van hen dieper bewijs verwachten.

Middelgrote banken #

Middelgrote banken moeten standaardiseren in plaats van maatwerk leveren. Een sterk managed Kubernetes-platform, gedisciplineerde keuze van cloudleveranciers, heldere exitstrategieën en geautomatiseerde bewijsgeneratie zijn waardevoller dan een ongerichte multicloudambitie die de instelling niet kan operationaliseren.

Financial market infrastructures #

FMI's (Financial Market Infrastructures) hebben vooral bewijs van veerkracht nodig. Zij moeten cloud-native zien als manier om herstel, observability en beheerste verandering te verbeteren, niet als pure snelheidstroef.

Fintechs en PSP's #

Fintechs en PSP's (Payment Service Providers) kunnen snel bewegen, maar mogen niet hun controlemodel ontgroeien. Naarmate ze systeemrelevant worden, gelden voor hen dezelfde verwachtingen rond veerkracht, risico van derde partijen, incidentmelding en datasoevereiniteit.

Conclusie #

Cloud-native bankieren is in 2026 een governance-architectuur. Kubernetes is essentieel, maar niet voldoende. De instellingen die slagen, laten VM's en containers convergeren waar nodig, hanteren cloud-native patronen voor nieuwe workloads, leveren bewijs van veerkracht onder DORA, beheersen datasoevereiniteit in de platformlaag en maken compliance voldoende automatisch om ontwikkelaars snel te laten werken zonder ongereguleerd risico te creëren.

Het oude debat ging over de vraag of banken naar de cloud konden. Het nieuwe debat gaat over de vraag of banken cloud-native veilig, portable en aantoonbaar genoeg kunnen maken om de diensten te draaien die er werkelijk toe doen.

Veelgestelde vragen #

Verbiedt DORA banken om de cloud te gebruiken?

Nee. DORA verbiedt cloudgebruik niet. Het maakt financiële instellingen verantwoordelijk voor ICT-risico, afhankelijkheid van derde partijen, incidentrapportage, veerkrachttesten en governance van kritieke diensten die op cloud en andere ICT-leveranciers steunen (IBM).

Waarom hebben banken nog VM's nodig als Kubernetes de toekomst is?

Banken draaien hun kritieke systemen nog steeds op VM-gebaseerde estates, waaronder betaalengines, core-bankingsystemen, handelsapplicaties en risicoplatformen. Een uniform VM/container-model vermindert duplicatie en staat gefaseerde migratie toe (Red Hat).

Wat is een echte cloud-exitstrategie?

Een echte exitstrategie omvat een afhankelijkheidsinventaris, procedures voor data-export, alternatieve runtime-opties, contractuele rechten, hersteltesten, sleutelbeheersplannen en een realistische tijdlijn voor het verplaatsen of herstellen van kritieke diensten.

Wat is de grootste cloud-native fout die banken maken?

De grootste fout is containers adopteren zonder platformcontroles. Wanneer Kubernetes de deployment-snelheid verhoogt maar geen identiteit, beleid, audit, dataresidentie, herstel en kwetsbaarheidscontroles afdwingt, versnelt het risico in plaats van het te verlagen.

Referenties #

Laatst beoordeeld .

Laatst herzien .