Cloud-native banking în 2026 se află în faza de audit DORA. Regulamentul (UE) 2022/2554 ⧉ este în vigoare din 17 ianuarie 2025. Regimul de desemnare a furnizorilor terți critici (CTPP) sub Articolele 28-44 se deschide pe parcursul 2025-2026, cu AWS, Microsoft (Azure), Google (GCP) și Salesforce în interiorul sau aproape de perimetrul de desemnare. Autoritățile Europene de Supraveghere (ABE, EIOPA, ESMA) au publicat RTS și ITS finale privind Registrul de Informații ⧉ în 2024. Echipa de Supraveghere Bancară a BCE are programe explicite privind pregătirea pentru perturbări cloud și testarea de penetrare condusă de amenințare în prioritățile de supraveghere 2026-28 ⧉. Întrebarea instituțională nu este dacă să alinieze strategia cloud la DORA — asta e tranșat — ci dacă primitivele de ingineria platformei ale instituției produc dovezi la viteza conductei de livrare în loc de PDF-uri asamblate cu o săptămână înaintea examinării.
Rezumat executiv / Concluzii esențiale
- Reziliența cloud sub DORA în aplicare activă din 17 ianuarie 2025. Articolele 6, 8, 18, 26 și 28-44 toate în vigoare. Constatările de supraveghere din primul val de examinări au sosit în T4 2025. Încadrarea „pregătire” este cu două cicluri în urmă.
- Regimul de desemnare a CTPP-urilor se deschide. AWS, Microsoft, Google, Salesforce — în interior sau aproape. Desemnarea oferă AES drepturi de supraveghere directă, inclusiv cereri de informații, inspecții la fața locului și recomandări de supraveghere.
- Ingineria platformei este livrabilul. Drumuri pavate Kubernetes (EKS / AKS / GKE / OpenShift), portal pentru dezvoltatori în stil Backstage, GitOps (ArgoCD sau Flux), Open Policy Agent la admitere, OpenTelemetry end-to-end. Cinci primitive denumite; orice lipsă este o constatare.
- Cloud-ul suveran este inginerie, nu brand. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — fiecare tratează o dimensiune specifică Schrems II + DORA Articolul 28; niciuna nu este un răspuns la cheie.
- Dovezi de ieșire testată obligatorii. Paragrafele 81 și 113-117 din EBA/GL/2019/02. Exercițiul trimestrial la masă este insuficient; supraveghetorii așteaptă testare de execuție de ieșire end-to-end anuală pentru fiecare funcție critică sau importantă.
- RTO / RPO din inventarul CIF. Nivelul 1: 2h / 15min. Nivelul 2: 4h / 1h. Nivelul 3: 24h / 4h. Derivate din analiza impactului asupra afacerii, nu din capacitatea echipei de platformă.
De ce reziliența cloud sub DORA este în faza de audit #
Trei motive pentru care încadrarea „pregătire” este greșită în 2026.
Întâi, calendarul. DORA a fost publicat în decembrie 2022. Perioada de aplicare de 24 de luni s-a încheiat pe 17 ianuarie 2025. RTS și ITS finale ale AES — inclusiv ITS privind Registrul de Informații folosit pentru desemnarea CTPP — au fost publicate pe parcursul anului 2024. Primul val de examinări de supraveghere s-a desfășurat pe parcursul anului 2025; constatările privind completitudinea cadrului de gestionare a riscurilor TIC Articolul 6 și reconcilierea registrului Articolul 8 au sosit în T4 2025 la mai multe instituții de nivel 1.
Al doilea, regimul de desemnare a CTPP-urilor. Articolul 31 stabilește criteriile pentru desemnarea ca furnizor terț critic: impact sistemic în caz de eșec, criticalitatea serviciilor furnizate, scara și complexitatea serviciilor, substituibilitatea. AES mențin registrul și publică deciziile de desemnare. AWS, Microsoft (Azure), Google (GCP) și Salesforce se află în interiorul sau aproape de perimetrul de desemnare, în funcție de cota de piață a serviciilor financiare per stat membru. Desemnarea conferă supraveghetorului principal (una dintre AES, alocată per furnizor) autoritate directă de supraveghere: cereri de informații sub Articolul 37, inspecții la fața locului sub Articolul 38, recomandări sub Articolul 35 și regimul de publicare sub Articolul 41. Băncile supravegheate față de acele CTPP-uri sunt supuse unor așteptări de supraveghere corespunzătoare privind modul în care gestionează acea dependență desemnată.
Al treilea, prioritățile de supraveghere ale BCE pentru 2026-28. Documentul de priorități numește două programe explicite care afectează direct cloud-native banking: pregătirea pentru o perturbare majoră a serviciilor cloud (scenariile de supraveghere modelate testează capacitatea instituției de a absorbi o întrerupere prelungită a unui CTPP desemnat) și TLPT aliniat TIBER-EU (fiecare exercițiu TIBER-EU acoperă funcțiile critice și importante ale instituției, care includ acum servicii găzduite pe cloud public). Valul de examinări din 2026 va produce constatări pe ambele.
Încadrarea pentru 2026 nu este „DORA vine”; este „constatările de examinare DORA ajung în cutia poștală a instituției voastre, iar deciziile de ingineria platformei luate în 2024-2025 sunt ceea ce supraveghetorul examinează în acele constatări.”
Arhitectura Indexului 2026 #
| Stratul indexului | Cum arată „pregătit” | Metrica de pregătire | Modul de eșec |
|---|---|---|---|
| Maturitatea platformei | >80% din volumele de lucru pe o platformă Kubernetes cu drumuri pavate (EKS / AKS / GKE / OpenShift) cu admitere policy-as-code, livrare GitOps, testare DR automatizată | % din CIF-uri pe platformă cu drumuri pavate; numărul de livrări-umbră; timpul mediu de integrare a unui serviciu nou pe platformă | Platforme-umbră cu controale inconsecvente; CIF-uri rulând pe infrastructură nepavată, invizibilă reconcilierii registrului Articolul 8 |
| Integritatea registrului Articolul 8 | Registrul de Informații se reconciliază automat cu consumul de API-uri terțe al platformei + lista materialelor cloud; clasificarea criticalității consecventă cu inventarul CIF al instituției | % intrări de registru reconciliate cu telemetria platformei; numărul de intrări orfane; verificarea integrității perimetrului CTPP | AES identifică o dependență CTPP desemnată pe care instituția nu a divulgat-o sub Articolul 8; constatare individuală și consecință la nivelul perimetrului CTPP |
| Concentrarea cloud | Funcțiile critice mapate la furnizori cloud ȘI la sub-regiuni cloud ȘI la servicii ȘI la evaluarea substituibilității; expunerea corelată între CIF-uri cuantificată | Scorul de concentrare per CIF; expunerea corelată între CIF-urile care împart o regiune CTPP desemnată | O singură pană IAM AWS us-east-1 face indisponibile patru CIF-uri pe care instituția le credea aprovizionate independent |
| Capacitate de ieșire testată | Test anual de execuție de ieșire end-to-end pentru fiecare CIF dependent de un CTPP desemnat; RTO / RPO documentat îndeplinește țintele derivate din BIA; cale de portabilitate a datelor testată | Rata de promovare a testului per CIF; timpul mediu de execuție a ieșirii față de ținta RTO; latența căii de portabilitate a datelor | Plan de ieșire care există doar ca PDF; exercițiul la masă spune RTO 4h, testul real arată 48h la prima încercare |
| Observabilitate + raportarea incidentelor | Trase OpenTelemetry end-to-end între servicii; ajutor de clasificare automatizată Articolul 18 4 ore conectat la platforma de gestionare a incidentelor | % din traficul CIF acoperit de trase OTel; timpul mediu de la detectarea incidentului la decizia de clasificare Articolul 18 | Incident major clasificat în afara ferestrei de 4 ore deoarece determinarea criticalității a necesitat o ședință de triaj; constatare Articolul 18 |
| Integrarea TLPT | Scopul TLPT derivat din inventarul CIF și reîmprospătat continuu; constatările alimentează policy-as-code al platformei; constatările închise produc pachete de dovezi gata pentru supraveghetor | Rata de închidere a constatărilor TLPT; timpul de ciclu constatare-actualizare politică | TLPT descoperă o vulnerabilitate pe care echipa de ingineria platformei a instituției nu o poate remedia în mai puțin de două cicluri de livrare |
Semnale curente de urmărit #
| Semnal | Ce înseamnă pentru bănci | Sursa |
|---|---|---|
| DORA în aplicare activă din 17 ian. 2025 | Constatările de supraveghere din primul val au sosit în T4 2025; constatările din valul doi sunt așteptate pe parcursul S2 2026 | EUR-Lex ⧉ |
| Desemnarea CTPP se deschide pe parcursul 2025-2026 | AWS, Microsoft, Google, Salesforce în interior sau aproape de perimetru; desemnarea oferă AES drepturi de supraveghere directă | ABE ⧉ |
| Prioritățile de supraveghere BCE 2026-28 numesc explicit perturbările cloud | Scenariile de supraveghere modelate testează capacitatea de a absorbi o întrerupere prelungită a unui CTPP desemnat | Supraveghere Bancară BCE ⧉ |
| TIBER-EU aliniat la Articolul 26 DORA | Scopul TLPT acoperă funcțiile critice / importante, inclusiv serviciile găzduite pe cloud | BCE TIBER-EU ⧉ |
| Ghidul ABE de externalizare (EBA/GL/2019/02) se interconectează cu Articolul 28 DORA | Prezență substanțială (¶64), evaluarea substituibilității (¶81), strategia de ieșire (¶113-117) — paragrafele pe care supraveghetorii le testează efectiv | ABE ⧉ |
| Schema UE de servicii cloud (EUCS) în progres | Viitoarea schemă de certificare a cloud-ului suveran sub Legea UE privind securitatea cibernetică; proiect publicat de ENISA | ENISA EUCS ⧉ |
Ingineria platformei: cele cinci primitive denumite #
Maturitatea cloud-native în 2026 se reduce la cinci primitive tehnice care se interconectează pentru a produce dovezi de supraveghere la viteza conductei de livrare. Lipsa oricăreia este o constatare care așteaptă să se întâmple.
1. Drumuri pavate bazate pe Kubernetes #
Fiecare CIF rulează pe o platformă Kubernetes gestionată — EKS, AKS, GKE sau OpenShift pe un CTPP desemnat, sau o alternativă gestionată de furnizor. Echipa de platformă operează un singur model de cluster „auriu” cu deviere controlată: noduri dintr-o imagine de bază documentată; izolare namespace-per-echipă; profil pod-security-standards-restricted; politici de rețea; injectare service-mesh (Istio sau Linkerd) pentru autentificare inter-serviciu și observabilitate. Serviciile noi intră pe drumul pavat printr-un flux de integrare șablonat care produce intrarea în registrul Articolul 8 ca artefact al livrării.
2. Portal pentru dezvoltatori în stil Backstage #
Un portal central pentru dezvoltatori — Backstage ⧉ open-source de la Spotify este implementarea de referință, cu diverse alternative enterprise — oferă sistemul de evidență a ceea ce rulează unde. Catalogul listează fiecare serviciu, proprietar, dependență, clasificare de criticalitate, runbook, rotație de gardă. Portalul se interconectează cu registrul Articolul 8: fiecare intrare din catalog se mapează la o intrare din registru; intrările fără referințe în registru declanșează eșec CI; intrările din registru fără prezență în catalog declanșează alerte care anticipează observațiile supraveghetorului.
3. Livrare GitOps via ArgoCD sau Flux #
Livrarea în producție rulează printr-un controler GitOps — ArgoCD sau Flux este standardul de producție în 2026 — care reconciliază o stare declarativă versionată în Git cu clusterul în execuție. kubectl apply manual este dezactivat; singura cale către producție este un pull request fuzionat. Repository-ul Git este jurnalul de audit; supraveghetorii care întreabă „arătați-mi configurația serviciului X la data Y” primesc un tag Git, nu o captură de ecran.
4. Open Policy Agent la admitere #
Open Policy Agent (OPA) stă în lanțul de admitere al clusterului aplicând politica platformei: conformitatea profilului pod-security, proveniența imaginii, limitele de resurse, prezența politicii de rețea, replicarea adecvată nivelului de criticalitate, plasarea sub-regiunii sub constrângerile cloud-ului suveran. Politicile sunt versionate în Git și gestionate prin schimbare alături de configurațiile serviciilor. Livrările respinse produc raționamente verificabile care alimentează pachetul de dovezi pentru managementul schimbării.
5. OpenTelemetry end-to-end #
Fiecare serviciu emite trase, metrici și jurnale OpenTelemetry. Echipa de platformă operează o conductă centralizată de observabilitate — tipic Tempo sau Jaeger pentru trase, Prometheus pentru metrici, Loki sau OpenSearch pentru jurnale — care expune sănătatea CIF end-to-end, maparea dependențelor și intrările de clasificare a incidentelor. Fereastra de clasificare de 4 ore Articolul 18 începe cu detectarea; conducta OTel scurtează calea de la detectare la clasificare la o interogare, nu la o ședință de triaj.
Cloud-ul suveran ca inginerie, nu ca brand #
Strategia de cloud suveran în 2026 trebuie să răspundă la patru întrebări specifice de externalizare Schrems II + DORA + ABE:
- Unde sunt procesate și stocate datele? Locație în stat membru UE; sub-regiune pentru fluxurile de criticalitate înaltă; angajamente de rezidență a datelor în scris.
- Cine are acces legal la date? Operațiuni exclusiv cu angajați locali; cererile de acces ale guvernelor străine supuse procesului instanțelor locale; răspuns testat la cererile de acces legal.
- Care este profilul de substituibilitate? Evaluarea substituibilității EBA/GL/2019/02 ¶81; execuție de ieșire testată; furnizor alternativ identificat și contractat (sau documentat de ce nu este fezabil).
- Care este modelul de suveranitate tehnică? Chei controlate de client; separare criptografică; plan de management suveran; lanț de aprovizionare auditabil.
Opțiunile de furnizori din 2026 care răspund la aceste întrebări:
- AWS European Sovereign Cloud (anunțat 2023, GA așteptat S2 2026): regiune fizică operată de o filială AWS rezidentă în UE; operațiuni și asistență cu rezidență în UE; chei controlate de client prin modelul KMS-XKS. Aliniere a conținutului contractual Articolul 28 DORA în curs în 2026.
- Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, exclusiv Franța): Data Boundary păstrează datele clienților UE în regiuni UE; Bleu este cloud-ul suveran francez aliniat SecNumCloud care rulează stack-ul Microsoft Azure sub control operațional francez.
- Parteneriatele suverane Google Cloud: Thales / S3NS în Franța (echivalent Bleu); T-Systems în Germania.
- Oracle EU Sovereign Cloud (GA 2023): model cu două regiuni (Frankfurt + Madrid) cu operațiuni rezidente în UE; conformitate Schrems II curată.
- Furnizori aliniați Gaia-X (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): furnizori nativi UE cu etichetare Gaia-X; scară și ecosistem mai mici decât hyperscalerii, dar fără expunere la Foreign Intelligence Surveillance Act.
Decizia strategică este rareori binară. Băncile de nivel 1 rulează tipic o configurație hyperscaler-cu-Data-Boundary pentru majoritatea volumelor de lucru, o opțiune de cloud suveran pentru fluxurile desemnate cu sensibilitate înaltă (de ex. sistemele de gestionare a cazurilor AML / sancțiuni care procesează date personale ale rezidenților UE) și o cale de substituibilitate de contingență testată anual sub Articolul 28 DORA.
Execuție de ieșire testată #
Paragrafele 113-117 din EBA/GL/2019/02 ⧉ sunt prevederile privind strategia de ieșire. Textul este explicit privind ce este necesar: „Instituțiile și instituțiile de plată ar trebui să se asigure că pot ieși din acordurile de externalizare fără perturbări nejustificate ale activităților lor de afaceri… Strategiile de ieșire ar trebui, de asemenea, documentate și testate ca parte a revizuirilor regulate ale acordurilor de externalizare.”
Așteptarea de supraveghere în 2026 este testarea de execuție de ieșire end-to-end anuală pentru fiecare CIF dependent de un CTPP desemnat. Exercițiile la masă și revizuirile documentare sunt insuficiente. Testul trebuie să producă:
- Măsurarea timpului până la restabilire: timpul real scurs de la declararea ieșirii până la restabilirea volumului de lucru la furnizorul alternativ, față de ținta RTO derivată din BIA.
- Dovezi de portabilitate a datelor: export de date testat de la sursa primară, validat față de calea de import a furnizorului destinație, cu dovezi de reconciliere.
- Echivalență funcțională: volum de lucru testat rulând la furnizorul alternativ cu SLO-uri echivalente.
- Dovezi de cost: cost de execuție a ieșirii documentat față de ipoteza de cost al restabilirii din planificarea de contingență a instituției.
Prima încercare de testare end-to-end a ieșirii pentru un CIF dezvăluie tipic o discrepanță de 5-10× între RTO-ul documentat și RTO-ul real. Închiderea acelei discrepanțe este muncă tehnică care durează luni. Băncile care o descoperă în timpul unei inspecții de supraveghere în loc de propriul ciclu anual de testare se confruntă cu un ciclu de constatări în T3 pe care l-ar fi putut evita.
Ținte RTO / RPO din inventarul CIF #
Fiecare funcție critică sau importantă este mapată la o clasificare pe niveluri derivată din analiza impactului asupra afacerii a instituției. Nivelul determină țintele RTO și RPO pe care echipa de ingineria platformei se angajează să le livreze.
| Nivelul | Exemple | RTO | RPO |
|---|---|---|---|
| Nivelul 1 (misiune-critică) | Conectivitate RTGS (CHAPS / T2 / Fedwire), autorizarea plăților retail, autentificarea clientului pentru canale digitale | 2 ore | 15 minute |
| Nivelul 2 (critică) | Screening AML / sancțiuni, conducte de detectare a fraudei, autorizare ATM, procesarea plăților în loturi | 4 ore | 1 oră |
| Nivelul 3 (importantă) | Raportare și depunere de reglementare, baze de cunoștințe pentru clienți, platforme de colaborare internă | 24 ore | 4 ore |
| Nivelul 4 (non-critică) | Sisteme HR interne, instrumente de marketing, raportare care nu se adresează clienților | 72 ore | 24 ore |
Aceste cifre sunt ilustrative — BIA al instituției produce cifrele proprii. Livrabilul ingineriei platformei este o capacitate testată prin regresie de a îndeplini țintele derivate din BIA, dovedită prin testare DR automatizată per serviciu și validată prin testul anual de execuție a ieșirii pentru CIF-urile dependente de CTPP.
Ce înseamnă asta pe tipuri de bănci #
Bănci de importanță sistemică globală #
Problema dificilă este scara între liniile de afaceri: mii de servicii, sute de CIF-uri, multiple expuneri la CTPP-uri desemnate între produse, jurisdicții și profiluri de reziliență. Investiția este capacitatea centrală de ingineria platformei — drumuri pavate Kubernetes, portal Backstage, GitOps, OPA, OTel — care produce reconcilierea registrului Articolul 8, harta de concentrare CTPP și capacitatea de execuție a ieșirii CIF-cu-CIF fără construcție personalizată per linie de afaceri.
Bănci universale și de dimensiune medie #
Investiția în ingineria platformei este justificată la acest nivel, dar scopul este restrâns: alegeți cele două sau trei CIF-uri cu criticalitatea cea mai înaltă, construiți modelul de drum pavat în jurul lor, acceptați că patrimoniul moștenit continuă pe controalele existente pe termen mediu. Poziționarea de supraveghere este mai importantă decât amploarea platformei — capacitatea de a dovedi integritatea registrului DORA Articolul 8 și ieșirea testată pentru primele trei CIF-uri acoperă preocupările primare ale supraveghetorului.
Bănci regionale și mai mici #
Selecția furnizorului în loc de construcția internă. Alegeți un furnizor de platformă bancară a cărui arhitectură nativă Kubernetes este documentată, a cărui integrare a registrului Articolul 8 este încorporată și ale cărui angajamente de conținut contractual Articolul 28 DORA sunt clare. Capacitatea internă de inginerie este în jurul configurației, monitorizării și răspunsului la incidente — nu construcția platformei.
Fintech-uri, PSP-uri și furnizori SaaS care servesc băncile #
Întrebarea de produs pentru furnizorii care vând în băncile UE în 2026 este dacă platforma produce intrările în registrul Articolul 8 și conținutul contractual Articolul 28 DORA de care are nevoie funcția de conformitate a băncii. Furnizorii cu ieșiri structurate câștigă contracte enterprise; furnizorii cu șabloane PDF pierd în fața concurenților cu JSON structurat.
Concluzie #
Reziliența cloud sub DORA este în faza de audit. Deciziile de ingineria platformei luate în 2024-2025 sunt cele pe care ciclul de supraveghere din 2026 le examinează. Instituțiile care par credibile pentru BCE și ABE în 2026-2028 sunt cele care rulează drumuri pavate Kubernetes cu portaluri în stil Backstage și livrare GitOps sub admitere Open Policy Agent cu OpenTelemetry end-to-end — producând dovezi pentru registrul Articolul 8 ca artefact al livrării și dovezi de execuție de ieșire testată ca ciclu anual, nu ca răspuns la o cerere de supraveghere.
Instituțiile care nu au făcut acele investiții vor descoperi dacă echipa lor de conformitate de linia a doua poate absorbi prima rundă de constatări de supraveghere înainte de sosirea celei de-a doua runde.
Măsurați platforma așa cum măsurați orice program operațional: acoperirea drumului pavat, rata de reconciliere a registrului, scorul de concentrare CTPP, timpul de ieșire testat față de ținta RTO, timpul mediu de clasificare Articolul 18, rata de închidere TLPT. Dovezi la viteza conductei; pachete documentare doar atunci când supraveghetorul le cere.
Întrebări frecvente #
Reziliența cloud sub DORA este încă în faza de pregătire în 2026?
Nu. DORA este în aplicare activă din 17 ianuarie 2025. Regimul de desemnare a CTPP-urilor sub Articolele 28-44 se deschide pe parcursul 2025-2026. Constatările de examinare BCE privind gestionarea riscurilor TIC Articolul 6 și integritatea registrului Articolul 8 au sosit la mai multe instituții de nivel 1 în T4 2025. Întrebarea de supraveghere din 2026 este dovada de examinare specifică instituției, nu pregătirea de reglementare.
Care furnizori cloud sunt desemnați ca CTPP-uri?
AES publică deciziile de desemnare pe site-urile lor. Instituțiile din interiorul sau aproape de perimetru în 2026 includ AWS, Microsoft (Azure), Google (GCP), Salesforce și un număr restrâns de alții, în funcție de cota de piață a serviciilor financiare per stat membru. Băncile supravegheate față de acei furnizori se confruntă cu așteptări de supraveghere corespunzătoare privind modul în care gestionează acea dependență.
Cloud-ul suveran elimină nevoia de conținut contractual Articolul 28 DORA?
Nu. Cloud-ul suveran tratează dimensiunea Schrems II + rezidența datelor; conținutul contractual Articolul 28 DORA este o obligație separată care se aplică indiferent de unde sunt situate datele. Contractul furnizorului de cloud suveran trebuie să acopere în continuare accesibilitatea datelor, securitatea, rezidența, drepturile de audit, strategiile de ieșire și continuitatea conform Articolului 28.
Care este livrabilul tehnic care demonstrează reziliența cloud sub DORA?
Cinci primitive de ingineria platformei care se interconectează: drumuri pavate Kubernetes (cluster gestionat cu deviere controlată de politică), portal pentru dezvoltatori în stil Backstage (catalog care se reconciliază cu registrul Articolul 8), livrare GitOps (ArgoCD sau Flux), Open Policy Agent la admitere, OpenTelemetry end-to-end. Dovezi la viteza conductei, nu la momentul examinării.
Cât de des trebuie testată execuția de ieșire?
Testare de execuție de ieșire end-to-end anuală per CIF dependent de un CTPP desemnat. Exercițiile la masă și revizuirile documentare sunt insuficiente. Testul trebuie să producă timp până la restabilire, dovezi de portabilitate a datelor, echivalență funcțională și dovezi de cost — măsurate față de țintele RTO și RPO derivate din BIA.
Referințe #
- Uniunea Europeană, (2022). Regulamentul (UE) 2022/2554 — Actul privind reziliența operațională digitală (DORA) ⧉.
- Autoritatea Bancară Europeană, (2019). EBA/GL/2019/02 — Ghidul privind acordurile de externalizare ⧉.
- Autoritatea Bancară Europeană, (2026). Actul privind reziliența operațională digitală ⧉.
- Autoritățile Europene de Supraveghere, (2024). Raportul final privind ITS pentru Registrul de Informații sub DORA ⧉.
- Supraveghere Bancară BCE, (2025). Prioritățile de supraveghere 2026-28 ⧉.
- Banca Centrală Europeană, (2024). Cadrul TIBER-EU ⧉.
- ENISA, (2024). Schema UE de securitate cibernetică pentru serviciile cloud (EUCS) ⧉.
- Spotify, (2020-2024). Portalul pentru dezvoltatori Backstage ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
Ultima revizuire .
Ultima revizuire .