Bankowość cloud-native w 2026 weszła w fazę audytu DORA. Rozporządzenie (UE) 2022/2554 ⧉ obowiązuje od 17 stycznia 2025. Reżim wyznaczania krytycznego zewnętrznego dostawcy (CTPP) w trybie Artykułów 28-44 otwiera się przez lata 2025-2026, a AWS, Microsoft (Azure), Google (GCP) i Salesforce znajdują się w obrębie lub blisko perymetru wyznaczania. Europejskie Urzędy Nadzoru (EBA, EIOPA, ESMA) opublikowały finalne RTS i ITS dotyczące Rejestru informacji ⧉ w 2024. Zespół Nadzoru Bankowego EBC ma jednoznaczne programy dotyczące gotowości na zakłócenia w chmurze oraz testów penetracyjnych prowadzonych pod kątem zagrożeń w priorytetach nadzorczych 2026-28 ⧉. Pytanie instytucjonalne nie brzmi już, czy dostosować strategię chmury do DORA — to jest rozstrzygnięte — lecz czy prymitywy inżynierii platformy danej instytucji produkują dowody z prędkością pipeline'u wdrożeniowego, czy raczej w plikach PDF składanych na tydzień przed egzaminem.
Podsumowanie wykonawcze / Kluczowe wnioski
- Odporność chmury w DORA w aktywnym egzekwowaniu od 17 stycznia 2025. Artykuły 6, 8, 18, 26 oraz 28-44 — wszystkie obowiązują. Ustalenia nadzorcze z pierwszej fali egzaminów wpłynęły w IV kwartale 2025. Narracja "przygotowań" jest spóźniona o dwa cykle.
- Reżim wyznaczania CTPP otwiera się. AWS, Microsoft, Google, Salesforce — wewnątrz lub blisko. Wyznaczenie daje EUN bezpośrednie kompetencje nadzorcze, w tym żądania informacji, inspekcje na miejscu i rekomendacje nadzorcze.
- Inżynieria platformy jest produktem do dostarczenia. Paved roads na Kubernetes (EKS / AKS / GKE / OpenShift), portal deweloperski w stylu Backstage, GitOps (ArgoCD lub Flux), Open Policy Agent na admisji, OpenTelemetry end-to-end. Pięć nazwanych prymitywów; brak któregokolwiek to ustalenie nadzorcze.
- Suwerenna chmura to inżynieria, nie marketing. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — każdy adresuje konkretny wymiar Schrems II + Artykuł 28 DORA; żaden nie jest rozwiązaniem pod klucz.
- Przetestowane dowody wyjścia są wymagane. Paragrafy 81 oraz 113-117 EBA/GL/2019/02. Tabletop kwartalny nie wystarczy; nadzorcy oczekują rocznego, kompleksowego testu wykonania wyjścia dla każdej krytycznej lub istotnej funkcji.
- RTO / RPO z inwentaryzacji CIF. Tier 1: 2h / 15min. Tier 2: 4h / 1h. Tier 3: 24h / 4h. Wyprowadzone z analizy wpływu biznesowego, a nie z możliwości zespołu platformy.
Dlaczego odporność chmury w DORA jest w fazie audytu #
Trzy powody, dla których narracja "przygotowań" jest w 2026 błędna.
Po pierwsze, harmonogram. DORA została opublikowana w grudniu 2022. Dwudziestoczteromiesięczny okres stosowania zakończył się 17 stycznia 2025. Finalne RTS i ITS Europejskich Urzędów Nadzoru — w tym ITS dotyczący Rejestru informacji wykorzystywany przy wyznaczaniu CTPP — zostały opublikowane w 2024. Pierwsza fala egzaminów nadzorczych przebiegła przez 2025; ustalenia dotyczące kompletności ram zarządzania ryzykiem ICT z Artykułu 6 oraz uzgodnienia rejestru z Artykułu 8 wpłynęły w IV kwartale 2025 do wielu instytucji pierwszego poziomu.
Po drugie, reżim wyznaczania CTPP. Artykuł 31 określa kryteria wyznaczenia krytycznego zewnętrznego dostawcy: systemowy wpływ w przypadku awarii, krytyczność świadczonych usług, skala i złożoność usług, substytucyjność. EUN prowadzą rejestr i publikują decyzje o wyznaczeniu. AWS, Microsoft (Azure), Google (GCP) i Salesforce znajdują się w obrębie lub blisko perymetru wyznaczania, w zależności od udziału w rynku usług finansowych w poszczególnych państwach członkowskich. Wyznaczenie daje wiodącemu nadzorcy (jednemu z EUN, przydzielonemu na dostawcę) bezpośrednie uprawnienia nadzorcze: żądania informacji na podstawie Artykułu 37, inspekcje na miejscu na podstawie Artykułu 38, rekomendacje na podstawie Artykułu 35 oraz reżim publicznego ujawniania na podstawie Artykułu 41. Banki nadzorowane w zakresie tych CTPP podlegają odpowiadającym oczekiwaniom nadzorczym dotyczącym tego, jak zarządzają tą wyznaczoną zależnością.
Po trzecie, priorytety nadzorcze EBC 2026-28. Dokument priorytetów nazywa dwa wyraźne programy, które bezpośrednio dotyczą bankowości cloud-native: gotowość na poważne zakłócenie usługi chmurowej (modelowane scenariusze nadzorcze testują zdolność instytucji do zaabsorbowania długotrwałej awarii wyznaczonego CTPP) oraz TLPT zgodny z TIBER-EU (każde ćwiczenie TIBER-EU obejmuje krytyczne i istotne funkcje instytucji, co dziś obejmuje usługi hostowane w chmurze publicznej). Fala egzaminów 2026 wytworzy ustalenia w obu obszarach.
Narracja na 2026 nie brzmi "DORA nadchodzi"; brzmi "ustalenia z egzaminów DORA trafiają do skrzynki Twojej instytucji, a decyzje z inżynierii platformy podjęte w latach 2024-2025 stanowią to, co nadzorca bada w tych ustaleniach".
Architektura indeksu 2026 #
| Warstwa indeksu | Jak wygląda "gotowość" | Wskaźnik gotowości | Tryb awarii |
|---|---|---|---|
| Dojrzałość platformy | >80% obciążeń na platformie Kubernetes typu paved road (EKS / AKS / GKE / OpenShift) z admisją typu policy-as-code, wdrożeniami GitOps, zautomatyzowanym testowaniem DR | % CIF na platformie paved road; liczba wdrożeń typu shadow; średni czas włączenia nowej usługi do platformy | Shadow-platformy z niespójnymi kontrolami; CIF działające na nie-paved infrastrukturze, niewidoczne dla uzgodnienia rejestru z Artykułu 8 |
| Integralność rejestru z Artykułu 8 | Rejestr informacji uzgadnia się automatycznie z konsumpcją API stron trzecich przez platformę + cloud-bill-of-materials; klasyfikacja krytyczności spójna z inwentaryzacją CIF instytucji | % wpisów rejestru uzgodnionych z telemetrią platformy; liczba wpisów osieroconych; kontrola integralności perymetru CTPP | EUN identyfikują zależność od wyznaczonego CTPP, której instytucja nie ujawniła w trybie Artykułu 8; ustalenie indywidualne i konsekwencja na perymetrze CTPP |
| Koncentracja chmury | Funkcje krytyczne mapowane na dostawców chmury ORAZ pod-regiony ORAZ usługi ORAZ ocenę substytucyjności; skwantyfikowana skorelowana ekspozycja między CIF | Wynik koncentracji na CIF; skorelowana ekspozycja między CIF dzielącymi region wyznaczonego CTPP | Pojedyncza awaria IAM w AWS us-east-1 wyłącza cztery CIF, które instytucja uważała za niezależnie zasilane |
| Przetestowana zdolność wyjścia | Coroczny kompleksowy test wykonania wyjścia dla każdego CIF zależnego od wyznaczonego CTPP; udokumentowane RTO / RPO spełnia cele z analizy BIA; przetestowana ścieżka przenoszalności danych | Wskaźnik zaliczonych testów na CIF; średni czas wykonania wyjścia vs cel RTO; opóźnienie ścieżki przenoszalności danych | Plan wyjścia istniejący wyłącznie jako PDF; tabletop mówi 4h RTO, rzeczywisty test pokazuje 48h za pierwszym razem |
| Obserwowalność + raportowanie incydentów | Ślady OpenTelemetry end-to-end pomiędzy usługami; zautomatyzowany pomocnik klasyfikacji 4-godzinnej z Artykułu 18 wpięty w platformę zarządzania incydentami | % ruchu CIF objętego śladami OTel; średni czas od wykrycia incydentu do decyzji o klasyfikacji z Artykułu 18 | Poważny incydent sklasyfikowany poza oknem 4-godzinnym, bo ustalenie krytyczności wymagało spotkania triage; ustalenie nadzorcze z Artykułu 18 |
| Integracja TLPT | Zakres TLPT wyprowadzony z inwentaryzacji CIF i odświeżany na bieżąco; ustalenia trafiają z powrotem do polityk platformy w trybie policy-as-code; zamknięte ustalenia produkują pakiety dowodowe gotowe dla nadzorcy | Wskaźnik zamykania ustaleń TLPT; czas cyklu od ustalenia do aktualizacji polityki | TLPT odkrywa podatność, której zespół inżynierii platformy nie potrafi naprawić w mniej niż dwóch cyklach wydawniczych |
Bieżące sygnały do śledzenia #
| Sygnał | Co oznacza dla banków | Źródło |
|---|---|---|
| DORA w aktywnym egzekwowaniu od 17 stycznia 2025 | Ustalenia nadzorcze pierwszej fali wpłynęły w IV kw. 2025; ustalenia drugiej fali oczekiwane do II półrocza 2026 | EUR-Lex ⧉ |
| Wyznaczanie CTPP otwiera się przez lata 2025-2026 | AWS, Microsoft, Google, Salesforce wewnątrz lub blisko perymetru; wyznaczenie daje EUN bezpośrednie kompetencje nadzorcze | EBA ⧉ |
| Priorytety nadzorcze EBC 2026-28 wyraźnie nazywają zakłócenie chmury | Modelowane scenariusze nadzorcze testują zdolność do zaabsorbowania długotrwałej awarii wyznaczonego CTPP | Nadzór Bankowy EBC ⧉ |
| TIBER-EU dostosowany do Artykułu 26 DORA | Zakres TLPT pokrywa krytyczne / istotne funkcje, w tym usługi hostowane w chmurze | TIBER-EU EBC ⧉ |
| Wytyczne EBA dotyczące outsourcingu (EBA/GL/2019/02) sprzęgają się z Artykułem 28 DORA | Faktyczna obecność (¶64), ocena substytucyjności (¶81), strategia wyjścia (¶113-117) — paragrafy, które nadzorcy realnie testują | EBA ⧉ |
| Projekt EU Cloud Services Scheme (EUCS) postępuje | Przyszły schemat certyfikacji suwerennej chmury w ramach EU Cybersecurity Act; projekt opublikowany przez ENISA | ENISA EUCS ⧉ |
Inżynieria platformy: pięć nazwanych prymitywów #
Dojrzałość cloud-native w 2026 sprowadza się do pięciu prymitywów inżynierskich, które wzajemnie się sprzęgają, by produkować dowody nadzorcze z prędkością pipeline'u wdrożeniowego. Brak któregokolwiek z nich to ustalenie czekające na okazję.
1. Paved roads na bazie Kubernetes #
Każdy CIF działa na zarządzanej platformie Kubernetes — EKS, AKS, GKE lub OpenShift na wyznaczonym CTPP, ewentualnie alternatywa zarządzana przez dostawcę. Zespół platformy operuje pojedynczym wzorcem golden cluster z kontrolowanym odchyleniem: węzły z udokumentowanego obrazu bazowego; izolacja typu namespace-per-team; profil pod-security-standards-restricted; polityki sieciowe; iniekcja service mesh (Istio lub Linkerd) dla uwierzytelniania i obserwowalności między usługami. Nowe usługi wchodzą na paved road poprzez szablonowy proces onboardingowy, który produkuje wpis do rejestru z Artykułu 8 jako artefakt wdrożeniowy.
2. Portal deweloperski w stylu Backstage #
Centralny portal deweloperski — referencyjną implementacją jest open-source'owy Backstage ⧉ Spotify, z różnymi alternatywami korporacyjnymi — stanowi system zapisu tego, co gdzie działa. Katalog wymienia każdą usługę, właściciela, zależności, klasyfikację krytyczności, runbook, rotację on-call. Portal sprzęga się z rejestrem z Artykułu 8: każdy wpis w katalogu mapuje się na wpis w rejestrze; wpisy bez referencji do rejestru powodują niepowodzenie CI; wpisy w rejestrze bez obecności w katalogu wyzwalają alerty wyprzedzające nadzorcę.
3. Wdrożenia GitOps przez ArgoCD lub Flux #
Wdrożenia produkcyjne idą przez kontroler GitOps — ArgoCD lub Flux to standard produkcyjny w 2026 — który uzgadnia deklaratywny stan wersjonowany w Git z działającym klastrem. Ręczne kubectl apply jest wyłączone; jedyną drogą na produkcję jest scalony pull request. Repozytorium Git to ślad audytowy; nadzorcy pytający "pokażcie konfigurację usługi X na datę Y" dostają tag Git, nie zrzut ekranu.
4. Open Policy Agent na admisji #
Open Policy Agent (OPA) siedzi w łańcuchu admisji klastra, egzekwując politykę platformy: zgodność z profilem pod-security, proweniencję obrazu, limity zasobów, obecność polityki sieciowej, replikację odpowiednią dla poziomu krytyczności, rozmieszczenie sub-regionu pod ograniczeniami suwerennej chmury. Polityki są wersjonowane w Git i objęte zarządzaniem zmianą równolegle do konfiguracji usług. Odrzucone wdrożenia produkują przeglądalne uzasadnienia, które zasilają pakiet dowodowy zarządzania zmianą.
5. OpenTelemetry end-to-end #
Każda usługa emituje ślady, metryki i logi OpenTelemetry. Zespół platformy operuje scentralizowanym pipeline'em obserwowalności — typowo Tempo lub Jaeger dla śladów, Prometheus dla metryk, Loki lub OpenSearch dla logów — który wystawia stan CIF end-to-end, mapowanie zależności i dane wejściowe do klasyfikacji incydentu. Okno 4-godzinne na klasyfikację z Artykułu 18 startuje od wykrycia; pipeline OTel skraca drogę od wykrycia do klasyfikacji do odpytania w bazie, a nie do spotkania triage.
Suwerenna chmura jako inżynieria, nie marketing #
Strategia suwerennej chmury w 2026 musi odpowiedzieć na cztery konkretne pytania Schrems II + DORA + outsourcing EBA:
- Gdzie dane są przetwarzane i przechowywane? Lokalizacja w państwie członkowskim UE; sub-region dla przepływów o wysokiej krytyczności; pisemne zobowiązania dotyczące rezydencji danych.
- Kto ma prawny dostęp do danych? Operacje wyłącznie z lokalnych pracowników; żądania dostępu zagranicznych organów państwowych objęte procedurą sądu lokalnego; przetestowana reakcja na żądania dostępu zgodnego z prawem.
- Jaki jest profil substytucyjności? Ocena substytucyjności zgodnie z ¶81 EBA/GL/2019/02; przetestowane wykonanie wyjścia; alternatywny dostawca zidentyfikowany i zakontraktowany (albo udokumentowane, dlaczego nie jest to wykonalne).
- Jaki jest model suwerenności technicznej? Klucze pod kontrolą klienta; separacja kryptograficzna; suwerenna płaszczyzna zarządzania; weryfikowalny łańcuch dostaw.
Opcje dostawców na 2026 adresujące te pytania:
- AWS European Sovereign Cloud (ogłoszony w 2023, GA oczekiwane na II półrocze 2026): fizyczny region operowany przez spółkę zależną AWS zarejestrowaną w UE; operacje i wsparcie realizowane przez rezydentów UE; klucze pod kontrolą klienta w schemacie KMS-XKS. W 2026 oczekiwane dostosowanie treści umownej z Artykułem 28 DORA.
- Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, wyłącznie Francja): Data Boundary utrzymuje dane klientów z UE w regionach UE; Bleu to suwerenna chmura francuska zgodna z SecNumCloud, działająca na stosie Microsoft Azure pod francuską kontrolą operacyjną.
- Suwerenne partnerstwa Google Cloud: Thales / S3NS we Francji (odpowiednik Bleu); T-Systems w Niemczech.
- Oracle EU Sovereign Cloud (GA 2023): wzorzec dwóch regionów (Frankfurt + Madryt) z operacjami rezydentów UE; czysto zgodny ze Schrems II.
- Dostawcy zgodni z Gaia-X (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): rodzimi dostawcy europejscy z oznaczeniem Gaia-X; mniejsza skala i ekosystem niż hiperskalery, ale brak ekspozycji na Foreign Intelligence Surveillance Act.
Decyzja strategiczna rzadko jest binarna. Banki pierwszego poziomu typowo prowadzą konfigurację hiperskaler-z-Data-Boundary dla bulk obciążeń, opcję suwerennej chmury dla wyznaczonych przepływów o wysokiej wrażliwości (np. systemy zarządzania sprawami AML / sankcji obsługujące dane osobowe rezydentów UE) oraz ścieżkę substytucyjności awaryjnej testowaną corocznie w trybie Artykułu 28 DORA.
Przetestowane wykonanie wyjścia #
Paragrafy 113-117 EBA/GL/2019/02 ⧉ to przepisy dotyczące strategii wyjścia. Treść jest jednoznaczna co do wymagań: "Instytucje i instytucje płatnicze powinny zapewnić możliwość wyjścia z umów outsourcingowych bez nieuzasadnionego zakłócenia swojej działalności gospodarczej… Strategie wyjścia powinny być również udokumentowane i przetestowane w ramach regularnych przeglądów ustaleń outsourcingowych".
Oczekiwanie nadzorcze w 2026 to coroczne, kompleksowe testowanie wykonania wyjścia dla każdego CIF zależnego od wyznaczonego CTPP. Ćwiczenia tabletop i przeglądy dokumentów nie wystarczą. Test musi wyprodukować:
- Pomiar time-to-restore: rzeczywisty czas, jaki upłynął od ogłoszenia wyjścia do odtworzenia obciążenia u alternatywnego dostawcy, w odniesieniu do celu RTO z analizy BIA.
- Dowód przenoszalności danych: przetestowany eksport danych z systemu pierwotnego, zweryfikowany pod kątem ścieżki importu dostawcy docelowego, z dowodami uzgodnienia.
- Równoważność funkcjonalna: przetestowane obciążenie działające u alternatywnego dostawcy z równoważnymi SLO.
- Dowód kosztowy: udokumentowany koszt wykonania wyjścia vs założenie kosztu odtworzenia w planowaniu awaryjnym instytucji.
Pierwsza próba kompleksowego testu wyjścia dla CIF zazwyczaj ujawnia 5-10-krotną lukę pomiędzy udokumentowanym RTO a rzeczywistym RTO. Zamknięcie tej luki to praca inżynierska na miesiące. Banki, które odkrywają ją w trakcie inspekcji nadzorczej, a nie podczas własnego rocznego cyklu testowego, czeka cykl ustaleń III kwartału, którego można było uniknąć.
Cele RTO / RPO z inwentaryzacji CIF #
Każda krytyczna lub istotna funkcja mapuje się na klasyfikację poziomu wyprowadzoną z analizy wpływu biznesowego instytucji. Poziom narzuca cele RTO i RPO, do których zobowiązuje się zespół inżynierii platformy.
| Poziom | Przykłady | RTO | RPO |
|---|---|---|---|
| Tier 1 (mission-critical) | Łączność RTGS (CHAPS / T2 / Fedwire), autoryzacja płatności detalicznych, uwierzytelnianie klientów w kanałach cyfrowych | 2 godziny | 15 minut |
| Tier 2 (critical) | Screening AML / sankcji, pipeline'y wykrywania nadużyć, autoryzacja bankomatowa, batch processing płatności | 4 godziny | 1 godzina |
| Tier 3 (important) | Raportowanie i sprawozdawczość regulacyjna, bazy wiedzy dla klientów, wewnętrzne platformy do współpracy | 24 godziny | 4 godziny |
| Tier 4 (non-critical) | Wewnętrzne systemy HR, narzędzia marketingowe, raportowanie bez kontaktu z klientem | 72 godziny | 24 godziny |
Te liczby są ilustracyjne — własna BIA instytucji produkuje własne. Produkt inżynierii platformy do dostarczenia to przetestowana regresyjnie zdolność do osiągania celów z BIA, udowodniona poprzez zautomatyzowane testowanie DR na poziomie usługi i zwalidowana corocznym testem wykonania wyjścia dla CIF zależnych od CTPP.
Co to oznacza dla różnych typów banków #
Globalne banki o znaczeniu systemowym #
Trudnym problemem jest skala w wielu liniach biznesowych: tysiące usług, setki CIF, wielokrotne ekspozycje na wyznaczone CTPP w produktach, jurysdykcjach i profilach odporności. Inwestycja to centralna zdolność inżynierii platformy — Kubernetes paved roads, portal Backstage, GitOps, OPA, OTel — która produkuje uzgodnienie rejestru z Artykułu 8, mapę koncentracji CTPP oraz zdolność wykonania wyjścia CIF po CIF bez budowania na zamówienie w każdej linii biznesowej.
Banki uniwersalne i średniej wielkości #
Inwestycja w inżynierię platformy jest na tym poziomie uzasadniona, ale jej zakres jest ograniczony: wybierz dwa lub trzy CIF o najwyższej krytyczności, zbuduj wokół nich wzorzec paved road, zaakceptuj, że legacy estate kontynuuje pod istniejącymi kontrolami w średnim terminie. Pozycjonowanie nadzorcze jest ważniejsze niż szerokość platformy — możliwość przedstawienia dowodów integralności rejestru z Artykułu 8 DORA i przetestowanego wyjścia dla trzech najważniejszych CIF pokrywa główne obawy nadzorcy.
Banki regionalne i mniejsze #
Wybór dostawcy zamiast budowy wewnętrznej. Wybierz dostawcę platformy bankowej, którego architektura natywna dla Kubernetes jest udokumentowana, którego integracja z rejestrem z Artykułu 8 jest wbudowana, a którego zobowiązania co do treści umownej z Artykułu 28 DORA są jasne. Wewnętrzna zdolność inżynierska dotyczy konfiguracji, monitoringu i reakcji na incydenty — nie budowy platformy.
Fintechy, PSP oraz dostawcy SaaS obsługujący banki #
Pytanie produktowe dla dostawców sprzedających do banków UE w 2026 brzmi, czy platforma produkuje wpisy do rejestru z Artykułu 8 i treść umowną z Artykułu 28 DORA, których potrzebuje funkcja compliance banku. Dostawcy ze strukturyzowanymi outputami wygrywają kontrakty korporacyjne; dostawcy z szablonami PDF przegrywają z konkurentami dostarczającymi strukturyzowany JSON.
Wnioski #
Odporność chmury w DORA weszła w fazę audytu. Decyzje z inżynierii platformy podjęte w latach 2024-2025 stanowią to, co cykl nadzorczy 2026 bierze pod lupę. Instytucje, które będą wiarygodne dla EBC i EBA w latach 2026-2028, to te prowadzące Kubernetes paved roads z portalami w stylu Backstage oraz wdrożenia GitOps pod admisją Open Policy Agent, z OpenTelemetry end-to-end — produkujące dowody do rejestru z Artykułu 8 jako artefakt wdrożeniowy oraz przetestowane dowody wykonania wyjścia jako roczny cykl, a nie odpowiedź na żądanie nadzorcze.
Instytucje, które tych inwestycji nie poczyniły, dowiedzą się, czy ich druga linia compliance zaabsorbuje pierwszą rundę ustaleń nadzorczych, zanim nadejdzie druga.
Mierz platformę tak, jak mierzysz każdy program operacyjny: pokrycie paved road, wskaźnik uzgodnienia rejestru, wynik koncentracji CTPP, przetestowany czas wyjścia vs cel RTO, średni czas klasyfikacji z Artykułu 18, wskaźnik zamykania TLPT. Dowody z prędkością pipeline'u; pakiety dokumentacyjne tylko wtedy, gdy nadzorca ich zażąda.
Najczęściej zadawane pytania #
Czy odporność chmury w DORA pozostaje w fazie przygotowań w 2026?
Nie. DORA jest w aktywnym egzekwowaniu od 17 stycznia 2025. Reżim wyznaczania CTPP w trybie Artykułów 28-44 otwiera się przez lata 2025-2026. Ustalenia z egzaminów EBC dotyczące zarządzania ryzykiem ICT z Artykułu 6 i integralności rejestru z Artykułu 8 wpłynęły do wielu instytucji pierwszego poziomu w IV kwartale 2025. Pytanie nadzorcze na 2026 dotyczy dowodów z egzaminów specyficznych dla instytucji, a nie gotowości regulacyjnej.
Którzy dostawcy chmury są wyznaczeni jako CTPP?
EUN publikują decyzje o wyznaczeniu na swoich stronach. Instytucje znajdujące się w obrębie lub blisko perymetru w 2026 obejmują AWS, Microsoft (Azure), Google (GCP), Salesforce oraz niewielką liczbę innych w zależności od udziału w rynku usług finansowych w poszczególnych państwach członkowskich. Banki nadzorowane w zakresie tych dostawców mierzą się z odpowiadającymi oczekiwaniami nadzorczymi dotyczącymi zarządzania tą zależnością.
Czy suwerenna chmura eliminuje potrzebę treści umownej z Artykułu 28 DORA?
Nie. Suwerenna chmura adresuje wymiar Schrems II + rezydencji danych; treść umowna z Artykułu 28 DORA to odrębny obowiązek, który obowiązuje niezależnie od tego, gdzie dane się znajdują. Umowa z dostawcą suwerennej chmury musi w dalszym ciągu obejmować dostępność danych, bezpieczeństwo, rezydencję, prawa audytu, strategie wyjścia i ciągłość zgodnie z Artykułem 28.
Jaki jest produkt inżynierski demonstrujący odporność chmury w DORA?
Pięć sprzęgających się prymitywów inżynierii platformy: Kubernetes paved roads (zarządzany klaster z odchyleniem kontrolowanym przez polityki), portal deweloperski w stylu Backstage (katalog uzgadniający się z rejestrem z Artykułu 8), wdrożenia GitOps (ArgoCD lub Flux), Open Policy Agent na admisji, OpenTelemetry end-to-end. Dowody z prędkością pipeline'u zamiast w czasie egzaminu.
Jak często wykonanie wyjścia musi być testowane?
Coroczny kompleksowy test wykonania wyjścia na CIF zależny od wyznaczonego CTPP. Ćwiczenia tabletop i przeglądy dokumentów nie wystarczą. Test musi wyprodukować time-to-restore, dowód przenoszalności danych, równoważność funkcjonalną oraz dowód kosztowy — zmierzone wobec celów RTO i RPO z analizy BIA.
Bibliografia #
- Unia Europejska, (2022). Rozporządzenie (UE) 2022/2554 — Rozporządzenie o operacyjnej odporności cyfrowej (DORA) ⧉.
- Europejski Urząd Nadzoru Bankowego, (2019). EBA/GL/2019/02 — Wytyczne dotyczące ustaleń outsourcingowych ⧉.
- Europejski Urząd Nadzoru Bankowego, (2026). Rozporządzenie o operacyjnej odporności cyfrowej ⧉.
- Europejskie Urzędy Nadzoru, (2024). Raport końcowy w sprawie ITS dotyczącego Rejestru informacji w trybie DORA ⧉.
- Nadzór Bankowy EBC, (2025). Priorytety nadzorcze 2026-28 ⧉.
- Europejski Bank Centralny, (2024). Ramy TIBER-EU ⧉.
- ENISA, (2024). Schemat cyberbezpieczeństwa UE dla usług chmurowych (EUCS) ⧉.
- Spotify, (2020-2024). Portal deweloperski Backstage ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
Ostatnia weryfikacja .
Ostatnia weryfikacja .