Il banking cloud-nativo nel 2026 è in fase di audit DORA. Il Regolamento (UE) 2022/2554 ⧉ è in vigore dal 17 gennaio 2025. Il regime di designazione dei fornitori terzi critici (CTPP) ai sensi degli Articoli 28-44 si è aperto nel 2025-2026, con AWS, Microsoft (Azure), Google (GCP) e Salesforce dentro o vicino al perimetro di designazione. Le Autorità europee di vigilanza (EBA, EIOPA, ESMA) hanno pubblicato gli RTS e gli ITS finali sul Registro delle informazioni ⧉ nel 2024. Il team di Vigilanza bancaria della BCE prevede programmi espliciti su preparazione alle interruzioni cloud e test di penetrazione threat-led nelle priorità di vigilanza 2026-28 ⧉. La domanda istituzionale non è se allineare la strategia cloud a DORA — è cosa decisa — ma se le primitive di ingegneria di piattaforma dell'istituzione generano evidenza alla velocità della pipeline di deployment anziché in PDF assemblati la settimana prima dell'esame.
Sintesi esecutiva / Punti chiave
- Resilienza cloud DORA in applicazione attiva dal 17 gennaio 2025. Articoli 6, 8, 18, 26 e 28-44 tutti in vigore. I rilievi di vigilanza della prima ondata di esami sono arrivati nel Q4 2025. La cornice "preparazione" è vecchia di due cicli.
- Regime di designazione CTPP in apertura. AWS, Microsoft, Google, Salesforce — dentro o vicino. La designazione conferisce alle ESAs diritti di supervisione diretta inclusi richieste di informazioni, ispezioni in loco e raccomandazioni di vigilanza.
- L'ingegneria di piattaforma è il deliverable. Paved road Kubernetes (EKS / AKS / GKE / OpenShift), portale per sviluppatori stile Backstage, GitOps (ArgoCD o Flux), Open Policy Agent in admission, OpenTelemetry end-to-end. Cinque primitive nominate; qualunque mancanza è un rilievo.
- Il cloud sovrano è ingegneria, non marca. AWS European Sovereign Cloud, Microsoft EU Data Boundary, Bleu (Capgemini + Orange + Microsoft), Thales / S3NS, Oracle EU Sovereign Cloud — ciascuno affronta una dimensione specifica di Schrems II + DORA Articolo 28; nessuno è una risposta chiavi in mano.
- Evidenza di uscita testata richiesta. EBA/GL/2019/02 paragrafi 81 e 113-117. Il tabletop trimestrale è insufficiente; i supervisori si attendono test annuali end-to-end di esecuzione di uscita per ogni funzione critica o importante.
- RTO / RPO dall'inventario CIF. Tier 1: 2h / 15min. Tier 2: 4h / 1h. Tier 3: 24h / 4h. Derivati dall'analisi di impatto sul business, non dalla capacità del team di piattaforma.
Perché la resilienza cloud DORA è in fase di audit #
Tre ragioni per cui la cornice "preparazione" è sbagliata nel 2026.
Primo, la timeline. DORA è stato pubblicato a dicembre 2022. Il periodo di applicazione di 24 mesi si è chiuso il 17 gennaio 2025. Gli RTS e gli ITS finali delle ESAs — inclusi gli ITS sul Registro delle informazioni usato per la designazione CTPP — sono stati pubblicati nel corso del 2024. La prima ondata di esami di vigilanza si è svolta nel 2025; i rilievi sulla completezza del quadro di gestione del rischio ICT ex Articolo 6 e sulla riconciliazione del registro ex Articolo 8 sono arrivati nel Q4 2025 in diversi istituti tier-1.
Secondo, il regime di designazione CTPP. L'Articolo 31 stabilisce i criteri per la designazione come fornitore terzo critico: impatto sistemico in caso di guasto, criticità dei servizi forniti, scala e complessità dei servizi, sostituibilità. Le ESAs mantengono il registro e pubblicano le decisioni di designazione. AWS, Microsoft (Azure), Google (GCP) e Salesforce sono dentro o vicino al perimetro di designazione, a seconda della quota di mercato dei servizi finanziari per Stato membro. La designazione conferisce al lead overseer (una delle ESAs, allocata per fornitore) autorità di supervisione diretta: richieste di informazioni ex Articolo 37, ispezioni in loco ex Articolo 38, raccomandazioni ex Articolo 35 e il regime di disclosure pubblica ex Articolo 41. Le banche vigilate su quei CTPP sono soggette a corrispondenti attese di vigilanza su come gestiscono quella dipendenza designata.
Terzo, le priorità di vigilanza 2026-28 della BCE. Il documento sulle priorità nomina due programmi espliciti che riguardano direttamente il banking cloud-nativo: preparazione a interruzioni significative dei servizi cloud (scenari di vigilanza modellati che testano la capacità dell'istituzione di assorbire un'interruzione prolungata di un CTPP designato) e TLPT allineato a TIBER-EU (ogni esercizio TIBER-EU definisce il perimetro delle funzioni critiche e importanti dell'istituzione, che ora include i servizi ospitati nel cloud pubblico). L'ondata di esami 2026 produrrà rilievi su entrambi.
La cornice per il 2026 non è "DORA sta arrivando"; è "i rilievi degli esami DORA stanno arrivando nella casella della tua istituzione, e le decisioni di ingegneria di piattaforma prese nel 2024-2025 sono ciò che il supervisore esamina in quei rilievi".
L'architettura dell'indice 2026 #
| Livello dell'indice | Cosa significa "pronto" | Metrica di prontezza | Modalità di fallimento |
|---|---|---|---|
| Maturità della piattaforma | >80% dei carichi su una piattaforma Kubernetes paved road (EKS / AKS / GKE / OpenShift) con admission policy-as-code, deployment GitOps, test DR automatizzati | % di CIF su piattaforma paved road; conteggio dei deployment shadow; tempo medio per onboarding di un nuovo servizio | Piattaforme shadow con controlli incoerenti; CIF su infrastruttura non-paved invisibile alla riconciliazione del registro Articolo 8 |
| Integrità del registro Articolo 8 | Il Registro delle informazioni si riconcilia automaticamente con il consumo di API terze + cloud bill-of-materials della piattaforma; classificazione di criticità coerente con l'inventario CIF dell'istituzione | % di voci del registro riconciliate con la telemetria di piattaforma; conteggio delle voci orfane; verifica di integrità del perimetro CTPP | Le ESAs identificano una dipendenza CTPP designata che l'istituzione non ha dichiarato ex Articolo 8; rilievo individuale e conseguenza sul perimetro CTPP |
| Concentrazione cloud | Funzioni critiche mappate a fornitori cloud E sotto-regioni cloud E servizi E valutazione di sostituibilità; esposizione correlata cross-CIF quantificata | Punteggio di concentrazione per CIF; esposizione correlata fra CIF che condividono una regione CTPP designata | Una singola interruzione IAM in AWS us-east-1 manda offline quattro CIF che l'istituzione riteneva indipendentemente approvvigionate |
| Capacità di uscita testata | Test annuale end-to-end di esecuzione di uscita per ogni CIF dipendente da un CTPP designato; RTO / RPO documentati rispettano i target derivati dalla BIA; percorso di portabilità dati testato | Tasso di superamento test per CIF; tempo medio di esecuzione di uscita rispetto al target RTO; latenza del percorso di portabilità dati | Piano di uscita che esiste solo come PDF; il tabletop indica 4h di RTO, il test reale mostra 48h al primo tentativo |
| Osservabilità + notifica incidenti | Tracce OpenTelemetry end-to-end fra servizi; helper automatizzato di classificazione 4 ore ex Articolo 18 collegato alla piattaforma di incident management | % di traffico CIF coperto da tracce OTel; tempo medio dalla rilevazione dell'incidente alla decisione di classificazione ex Articolo 18 | Incidente significativo classificato fuori dalla finestra di 4 ore perché la determinazione di criticità richiedeva una riunione di triage; rilievo Articolo 18 |
| Integrazione TLPT | Perimetro TLPT derivato dall'inventario CIF e aggiornato in continuo; i rilievi rientrano nelle policy-as-code di piattaforma; i rilievi chiusi producono pacchetti di evidenza pronti per la vigilanza | Tasso di chiusura dei rilievi TLPT; tempo di ciclo da rilievo ad aggiornamento di policy | TLPT scopre una vulnerabilità che il team di ingegneria di piattaforma non riesce a risolvere in meno di due cicli di release |
Segnali correnti da monitorare #
| Segnale | Cosa significa per le banche | Fonte |
|---|---|---|
| DORA in applicazione attiva dal 17 gen 2025 | I rilievi di vigilanza di prima ondata sono arrivati nel Q4 2025; quelli di seconda ondata attesi nel H2 2026 | EUR-Lex ⧉ |
| Designazione CTPP in apertura nel 2025-2026 | AWS, Microsoft, Google, Salesforce dentro o vicino al perimetro; la designazione conferisce alle ESAs diritti di supervisione diretta | EBA ⧉ |
| Le priorità di vigilanza BCE 2026-28 nominano esplicitamente l'interruzione cloud | Scenari di vigilanza modellati testano la capacità di assorbire un'interruzione prolungata di un CTPP designato | Vigilanza bancaria BCE ⧉ |
| TIBER-EU allineato all'Articolo 26 DORA | Il perimetro TLPT copre le funzioni critiche / importanti inclusi i servizi cloud-hosted | BCE TIBER-EU ⧉ |
| Le linee guida EBA sull'outsourcing (EBA/GL/2019/02) si incastrano con l'Articolo 28 DORA | Presenza sostanziale (¶64), valutazione di sostituibilità (¶81), strategia di uscita (¶113-117) — i paragrafi su cui i supervisori effettivamente verificano | EBA ⧉ |
| Avanza la bozza dello Schema EU Cloud Services (EUCS) | Futuro schema di certificazione per cloud sovrano nell'ambito dell'EU Cybersecurity Act; bozza pubblicata da ENISA | ENISA EUCS ⧉ |
Ingegneria di piattaforma: le cinque primitive nominate #
La maturità cloud-nativa nel 2026 si riduce a cinque primitive ingegneristiche che si incastrano per generare evidenza di vigilanza alla velocità della pipeline di deployment. La mancanza di una qualunque è un rilievo in attesa di accadere.
1. Paved road basate su Kubernetes #
Ogni CIF gira su una piattaforma Kubernetes gestita — EKS, AKS, GKE o OpenShift su un CTPP designato, oppure un'alternativa vendor-managed. Il team di piattaforma opera un singolo pattern di cluster golden con deviazione controllata: nodi da un'immagine base documentata; isolamento namespace-per-team; profilo pod-security-standards-restricted; network policy; iniezione di service mesh (Istio o Linkerd) per autenticazione fra servizi e osservabilità. I nuovi servizi entrano nella paved road tramite un workflow di onboarding templatizzato che genera la voce del registro Articolo 8 come artefatto di deployment.
2. Portale per sviluppatori stile Backstage #
Un portale per sviluppatori centrale — Backstage ⧉ open-source di Spotify è l'implementazione di riferimento, con varie alternative enterprise — fornisce il sistema di record di ciò che gira dove. Il catalogo elenca ogni servizio, owner, dipendenza, classificazione di criticità, runbook, rotazione on-call. Il portale si incastra con il registro Articolo 8: ogni voce di catalogo mappa a una voce di registro; le voci senza riferimenti nel registro fanno fallire la CI; le voci di registro senza presenza nel catalogo attivano allerte che anticipano il supervisore.
3. Deployment GitOps via ArgoCD o Flux #
Il deployment in produzione passa attraverso un controller GitOps — ArgoCD o Flux è lo standard di produzione nel 2026 — che riconcilia uno stato dichiarativo versionato in Git con il cluster in esecuzione. Il kubectl apply manuale è disabilitato; l'unica via per la produzione è una pull request mergeata. Il repository Git è la pista di audit; ai supervisori che chiedono "mostratemi la configurazione del servizio X alla data Y" si fornisce un tag Git, non uno screenshot.
4. Open Policy Agent in admission #
Open Policy Agent (OPA) si inserisce nella catena di admission del cluster applicando la policy di piattaforma: conformità al profilo pod-security, provenienza delle immagini, limiti di risorse, presenza di network policy, replica appropriata al tier di criticità, posizionamento sub-regionale sotto i vincoli di cloud sovrano. Le policy sono versionate in Git e change-managed insieme alle configurazioni dei servizi. I deployment rifiutati producono motivazioni revisionabili che alimentano il pacchetto di evidenza di change management.
5. OpenTelemetry end-to-end #
Ogni servizio emette tracce, metriche e log OpenTelemetry. Il team di piattaforma opera una pipeline di osservabilità centralizzata — tipicamente Tempo o Jaeger per le tracce, Prometheus per le metriche, Loki o OpenSearch per i log — che espone la salute end-to-end dei CIF, la mappatura delle dipendenze e gli input di classificazione degli incidenti. La finestra di classificazione di 4 ore ex Articolo 18 inizia con la rilevazione; la pipeline OTel accorcia il percorso da rilevazione a classificazione a una query, non a una riunione di triage.
Cloud sovrano come ingegneria, non come marca #
La strategia di cloud sovrano nel 2026 deve rispondere a quattro domande specifiche di Schrems II + DORA + outsourcing EBA:
- Dove sono elaborati e archiviati i dati? Localizzazione in uno Stato membro UE; sotto-regione per i flussi ad alta criticità; impegni di residenza dei dati per iscritto.
- Chi ha accesso legale ai dati? Operazioni solo con personale locale; richieste di accesso da governi esteri soggette al processo giudiziario locale; risposta testata alle richieste di accesso legittime.
- Qual è il profilo di sostituibilità? Valutazione di sostituibilità EBA/GL/2019/02 ¶81; esecuzione di uscita testata; fornitore alternativo identificato e contrattualizzato (o documentato il motivo per cui non è praticabile).
- Qual è il modello di sovranità tecnica? Chiavi controllate dal cliente; separazione crittografica; piano di management sovrano; supply chain auditabile.
Le opzioni vendor del 2026 che rispondono a queste domande:
- AWS European Sovereign Cloud (annunciato nel 2023, GA prevista nel H2 2026): regione fisica operata da una sussidiaria AWS residente UE; operazioni e supporto residenti UE; chiavi controllate dal cliente tramite pattern KMS-XKS. In attesa di allineamento del contenuto contrattuale ex Articolo 28 DORA nel 2026.
- Microsoft EU Data Boundary (GA 2024) + Bleu (Capgemini + Orange + Microsoft, solo Francia): Data Boundary mantiene i dati dei clienti UE nelle regioni UE; Bleu è il cloud sovrano francese allineato SecNumCloud che esegue lo stack Microsoft Azure sotto controllo operativo francese.
- Partnership sovrane di Google Cloud: Thales / S3NS in Francia (equivalente Bleu); T-Systems in Germania.
- Oracle EU Sovereign Cloud (GA 2023): pattern a doppia regione (Francoforte + Madrid) con operazioni residenti UE; nettamente compliant con Schrems II.
- Fornitori allineati Gaia-X (OVHcloud, Scaleway, Stackit, Aruba Cloud, IONOS): fornitori nativi UE con etichettatura Gaia-X; scala ed ecosistema più ridotti rispetto agli hyperscaler ma nessuna esposizione al Foreign Intelligence Surveillance Act.
La decisione strategica raramente è binaria. Le banche tier-1 tipicamente eseguono una configurazione hyperscaler-con-Data-Boundary per il grosso dei carichi, un'opzione di cloud sovrano per flussi designati ad alta sensibilità (es. sistemi di case management AML / sanzioni che trattano dati personali di residenti UE), e un percorso di sostituibilità di contingenza testato annualmente ex Articolo 28 DORA.
Esecuzione di uscita testata #
I paragrafi 113-117 di EBA/GL/2019/02 ⧉ sono le disposizioni sulla strategia di uscita. Il testo è esplicito su cosa è richiesto: "Gli istituti e gli istituti di pagamento dovrebbero assicurarsi di essere in grado di uscire dagli accordi di outsourcing senza indebita interruzione delle proprie attività… Le strategie di uscita dovrebbero essere anche documentate e testate nell'ambito delle revisioni periodiche degli accordi di outsourcing."
L'attesa di vigilanza nel 2026 è il test annuale end-to-end di esecuzione di uscita per ogni CIF dipendente da un CTPP designato. Le esercitazioni tabletop e le revisioni documentali sono insufficienti. Il test deve produrre:
- Misurazione del tempo di ripristino: tempo effettivo trascorso dalla dichiarazione di uscita al ripristino del carico sul fornitore alternativo, rispetto al target RTO derivato dalla BIA.
- Evidenza di portabilità dei dati: esportazione dati testata dal primario, validata rispetto al percorso di import del fornitore di destinazione, con evidenza di riconciliazione.
- Equivalenza funzionale: carico testato in esecuzione sul fornitore alternativo con SLO equivalenti.
- Evidenza di costo: costo di esecuzione di uscita documentato rispetto all'assunzione di costo di ripristino nella pianificazione di contingenza dell'istituzione.
Il primo tentativo di test end-to-end di uscita per un CIF tipicamente rivela un divario di 5-10× fra l'RTO documentato e l'RTO effettivo. Chiudere quel divario è lavoro ingegneristico che richiede mesi. Le banche che lo scoprono durante un'ispezione di vigilanza anziché durante il proprio ciclo di test annuale affrontano un ciclo di rilievi nel Q3 che avrebbero potuto evitare.
Target RTO / RPO dall'inventario CIF #
Ogni funzione critica o importante è mappata a una classificazione per tier derivata dall'analisi di impatto sul business dell'istituzione. Il tier guida i target RTO e RPO che il team di ingegneria di piattaforma si impegna a fornire.
| Tier | Esempi | RTO | RPO |
|---|---|---|---|
| Tier 1 (mission-critical) | Connettività RTGS (CHAPS / T2 / Fedwire), autorizzazione dei pagamenti retail, autenticazione clienti per canali digitali | 2 ore | 15 minuti |
| Tier 2 (critico) | Screening AML / sanzioni, pipeline di rilevazione frodi, autorizzazione ATM, elaborazione batch dei pagamenti | 4 ore | 1 ora |
| Tier 3 (importante) | Reportistica e segnalazioni regolamentari, knowledge base rivolte ai clienti, piattaforme collaborative interne | 24 ore | 4 ore |
| Tier 4 (non critico) | Sistemi HR interni, strumenti di marketing, reportistica non rivolta ai clienti | 72 ore | 24 ore |
Questi valori sono illustrativi — la BIA dell'istituzione produce i propri. Il deliverable dell'ingegneria di piattaforma è una capacità sottoposta a test di regressione di soddisfare i target derivati dalla BIA, evidenziata tramite test DR automatizzati per servizio e validata tramite il test annuale di esecuzione di uscita per i CIF dipendenti da CTPP.
Cosa significa per tipo di banca #
Banche di rilevanza sistemica globale #
Il problema difficile è la scala fra linee di business: migliaia di servizi, centinaia di CIF, esposizioni multiple a CTPP designati fra prodotti, giurisdizioni e profili di resilienza. L'investimento è la capacità centrale di ingegneria di piattaforma — paved road Kubernetes, portale Backstage, GitOps, OPA, OTel — che genera la riconciliazione del registro Articolo 8, la mappa di concentrazione CTPP e la capacità di esecuzione di uscita CIF per CIF senza costruzione su misura per linea di business.
Banche universali e di media dimensione #
L'investimento in ingegneria di piattaforma è giustificato a questo tier ma il perimetro è vincolato: scegliere i due o tre CIF di criticità più alta, costruire il pattern paved road intorno a loro, accettare che l'estate legacy continui sotto i controlli esistenti nel medio termine. Il posizionamento di vigilanza è più importante dell'ampiezza della piattaforma — essere in grado di evidenziare l'integrità del registro Articolo 8 DORA e l'uscita testata per i tre CIF principali copre le preoccupazioni primarie del supervisore.
Banche regionali e di dimensioni minori #
Selezione di vendor anziché costruzione interna. Scegliere un vendor di piattaforma bancaria la cui architettura Kubernetes-nativa è documentata, la cui integrazione con il registro Articolo 8 è incorporata e i cui impegni di contenuto contrattuale ex Articolo 28 DORA sono chiari. La capacità ingegneristica interna è intorno a configurazione, monitoraggio e risposta agli incidenti — non costruzione di piattaforma.
Fintech, PSP e fornitori SaaS che servono le banche #
La domanda di prodotto per i vendor che vendono a banche UE nel 2026 è se la piattaforma genera le voci del registro Articolo 8 e il contenuto contrattuale ex Articolo 28 DORA di cui la funzione compliance della banca ha bisogno. I vendor con output strutturati vincono i contratti enterprise; i vendor con template PDF perdono contro concorrenti con JSON strutturato.
Conclusione #
La resilienza cloud DORA è in fase di audit. Le decisioni di ingegneria di piattaforma prese nel 2024-2025 sono ciò che il ciclo di vigilanza 2026 esamina. Le istituzioni che appaiono credibili alla BCE e all'EBA nel 2026-2028 sono quelle che eseguono paved road Kubernetes con portali stile Backstage e deployment GitOps sotto admission Open Policy Agent con OpenTelemetry end-to-end — generando l'evidenza del registro Articolo 8 come artefatto di deployment e l'evidenza di esecuzione di uscita testata come ciclo annuale, non come risposta a una richiesta di vigilanza.
Le istituzioni che non hanno fatto quegli investimenti scopriranno se il loro team di compliance di seconda linea può assorbire la prima ondata di rilievi di vigilanza prima che arrivi la seconda.
Misurare la piattaforma come si misura qualunque programma operativo: copertura paved road, tasso di riconciliazione del registro, punteggio di concentrazione CTPP, tempo di uscita testato rispetto al target RTO, tempo medio di classificazione Articolo 18, tasso di chiusura TLPT. Evidenza alla velocità della pipeline; pacchetti documentali solo quando il supervisore ne chiede uno.
Domande frequenti #
La resilienza cloud DORA è ancora in fase di preparazione nel 2026?
No. DORA è in applicazione attiva dal 17 gennaio 2025. Il regime di designazione CTPP ex Articoli 28-44 si sta aprendo nel 2025-2026. I rilievi degli esami BCE su gestione del rischio ICT ex Articolo 6 e integrità del registro ex Articolo 8 sono arrivati in diversi istituti tier-1 nel Q4 2025. La domanda di vigilanza 2026 è l'evidenza di esame specifica per istituzione, non la prontezza regolatoria.
Quali fornitori cloud sono designati come CTPP?
Le ESAs pubblicano le decisioni di designazione sui propri siti. Gli istituti dentro o vicino al perimetro nel 2026 includono AWS, Microsoft (Azure), Google (GCP), Salesforce e un piccolo numero di altri a seconda della quota di mercato dei servizi finanziari per Stato membro. Le banche vigilate su quei fornitori affrontano corrispondenti attese di vigilanza su come gestiscono quella dipendenza.
Il cloud sovrano elimina la necessità del contenuto contrattuale ex Articolo 28 DORA?
No. Il cloud sovrano affronta la dimensione Schrems II + residenza dei dati; il contenuto contrattuale ex Articolo 28 DORA è un obbligo separato che si applica indipendentemente da dove risiedono i dati. Il contratto del fornitore di cloud sovrano deve comunque coprire accessibilità dei dati, sicurezza, residenza, diritti di audit, strategie di uscita e continuità ex Articolo 28.
Qual è il deliverable ingegneristico che dimostra la resilienza cloud DORA?
Cinque primitive di ingegneria di piattaforma che si incastrano: paved road Kubernetes (cluster gestito con deviazione controllata da policy), portale per sviluppatori stile Backstage (catalogo che si riconcilia con il registro Articolo 8), deployment GitOps (ArgoCD o Flux), Open Policy Agent in admission, OpenTelemetry end-to-end. Evidenza alla velocità della pipeline anziché al momento dell'esame.
Con quale frequenza deve essere testata l'esecuzione di uscita?
Test annuale end-to-end di esecuzione di uscita per ogni CIF dipendente da un CTPP designato. Le esercitazioni tabletop e le revisioni documentali sono insufficienti. Il test deve produrre tempo di ripristino, evidenza di portabilità dei dati, equivalenza funzionale ed evidenza di costo — misurati rispetto ai target RTO e RPO derivati dalla BIA.
Riferimenti #
- Unione europea, (2022). Regolamento (UE) 2022/2554 — Digital Operational Resilience Act (DORA) ⧉.
- European Banking Authority, (2019). EBA/GL/2019/02 — Linee guida sugli accordi di outsourcing ⧉.
- European Banking Authority, (2026). Digital Operational Resilience Act ⧉.
- Autorità europee di vigilanza, (2024). Final Report on the ITS on the Register of Information under DORA ⧉.
- Vigilanza bancaria BCE, (2025). Priorità di vigilanza 2026-28 ⧉.
- Banca centrale europea, (2024). Framework TIBER-EU ⧉.
- ENISA, (2024). EU Cybersecurity Scheme for Cloud Services (EUCS) ⧉.
- Spotify, (2020-2024). Portale per sviluppatori Backstage ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
- Cloud Native Computing Foundation, (2019). OpenTelemetry ⧉.
Ultima revisione .
Ultima revisione .