La concentrazione cloud di quarta parte emerge quando fornitori diretti diversi dipendono dalla stessa infrastruttura essenziale. Due contratti, due marchi e due applicazioni possono quindi interrompersi insieme. Per comprenderla occorre collegare il servizio acquistato alle dipendenze che ne permettono il funzionamento, con una chiara distinzione tra fatti confermati e ipotesi.
Il risultato operativo è una mappa accompagnata da una tabella di dipendenze e da scenari di interruzione correlata. La guida NIST SP 1305 offre il quadro generale del rischio nella catena di fornitura. Per le entità finanziarie soggette a DORA, l’articolo 29 di DORA riguarda la valutazione preliminare degli accordi TIC che si prevede di concludere per funzioni essenziali o importanti: considera la concentrazione presso fornitori non facilmente sostituibili o strettamente connessi e, quando previsto, il subappalto. La mappa proposta qui è una pratica più ampia, utile anche fuori da quel perimetro normativo. Fonti verificate il 27 settembre 2026.
Definire cosa significa quarta parte nel lavoro concreto
In questa analisi, quarta parte indica un soggetto o un servizio che sostiene il vostro fornitore diretto senza essere necessariamente vostro contraente. Può essere infrastruttura cloud, identità, rete, distribuzione dei contenuti, messaggistica o gestione delle chiavi. L’espressione serve a descrivere la catena; non attribuisce automaticamente una qualifica giuridica.
Partire da una funzione operativa e dai servizi che la sostengono. Per esempio, l’acquisizione di un ordine può richiedere il portale clienti, un servizio di pagamento e una piattaforma di assistenza. La mappatura dei sistemi e dei flussi permette di seguire questi collegamenti senza ridurre l’analisi all’elenco dei fornitori registrati dagli acquisti.
Stabilire il livello di dettaglio utile. Sapere che due servizi usano lo stesso grande provider non dimostra che condividano la medesima modalità di guasto. Servono, quando disponibili e pertinenti, informazioni su regione, piano di controllo, identità e componenti da cui dipende la ripresa.
Scegliere la profondità della mappa in base alla funzione
La stessa infrastruttura può sostenere una funzione marginale e un servizio che non tollera interruzioni. Partire quindi dalla conseguenza operativa: quali operazioni si fermano, per quanto tempo e quali alternative esistono? Per il percorso più importante chiedere maggiore dettaglio sui componenti necessari all’accesso e al recupero. Per altri percorsi può bastare una relazione dichiarata con un livello di fiducia esplicito. Applicare a tutti la stessa profondità produce spesso molte caselle e poche decisioni.
Dopo aver individuato un provider comune, non fermarsi al marchio. Due applicazioni possono usare regioni diverse ma condividere un servizio di identità; viceversa, l’uso della stessa piattaforma non implica che ogni singolo guasto le coinvolga entrambe. Annotare il meccanismo plausibile di interruzione e la fonte che lo sostiene. Se il fornitore non rivela il componente, conservare la domanda come aperta e scegliere una prova di comportamento del servizio. Questa selezione rende l’indagine proporzionata e aiuta a spiegare perché certi nodi vengono approfonditi e altri solo monitorati.
Registrare ogni relazione con la sua prova
| Elemento | Dato da raccogliere | Decisione sostenuta |
|---|---|---|
| Funzione | Operazione e tolleranza all’interruzione | Priorità dell’analisi |
| Fornitore diretto | Servizio e contratto | Responsabile della richiesta |
| Dipendenza | Componente e funzione svolta | Possibile interruzione comune |
| Localizzazione | Regione o altra separazione pertinente | Valutazione dell’indipendenza |
| Fonte | Documento, risposta e data | Affidabilità dell’informazione |
| Fiducia | Confermato, dichiarato o ipotizzato | Necessità di ulteriori verifiche |
| Alternativa | Servizio sostitutivo e dipendenze | Possibilità di recupero |
| Responsabile | Chi aggiorna e chi decide | Continuità della manutenzione |
Conservare l’identità della relazione, non soltanto quella del soggetto. Un provider può sostenere il servizio principale e anche il canale di assistenza. Queste due dipendenze hanno conseguenze diverse e potrebbero richiedere alternative differenti.
Raccogliere informazioni senza promettere visibilità totale
Usare documentazione del servizio, elenchi dei subfornitori, architetture condivise, risposte contrattuali e risultati di esercizi. Una lista di subresponsabili per dati personali può essere utile, ma non coincide necessariamente con la mappa completa delle dipendenze operative. Alcuni componenti essenziali potrebbero non comparirvi.
Chiedere al fornitore come il servizio continua o viene ripristinato quando la dipendenza indicata non è disponibile. Una domanda centrata sul risultato può ottenere informazioni utili anche quando il fornitore non condivide dettagli architetturali riservati. Registrare la limitazione e la prova alternativa disponibile.
La valutazione dei fornitori TIC e dell’uscita descrive il fascicolo più ampio. Questa mappa ne approfondisce un elemento preciso: la possibilità che servizi apparentemente diversi falliscano per una causa comune. Non va presentata come inventario completo di ogni subfornitore esistente.
Un fornitore può non comunicare l’architettura dettagliata per ragioni di riservatezza. Formulare allora domande sul comportamento del servizio: quali funzioni sono compromesse dalla perdita di una determinata categoria di dipendenza, come vengono informati i clienti, quali alternative restano accessibili e quando è stata verificata la procedura. Una risposta che cita soltanto la certificazione del fornitore non descrive necessariamente lo scenario esaminato.
Assegnare a ogni risposta un livello di prova comprensibile: conferma documentata per quel servizio, dichiarazione del fornitore senza prova osservabile, oppure ipotesi dell’organizzazione. La categoria non è un voto al fornitore. Serve a decidere se una funzione può basarsi su quella conoscenza oppure necessita di una misura prudenziale. Conservare data, versione del servizio e interlocutore, perché un’integrazione successiva può rendere superata una risposta prima valida.
Quando l’incertezza resta significativa, la decisione può riguardare una misura compensativa: mantenere istruzioni fuori dal sistema interessato, predisporre un canale di comunicazione indipendente o limitare il volume di attività che dipende dal percorso incerto. Stabilire chi verifica la misura e quale evento riapre il tema. Per le entità finanziarie soggette a DORA, l’articolo 29 si riferisce agli accordi TIC previsti per funzioni essenziali o importanti, inclusi specifici rischi di concentrazione e subappalto. Questa classificazione della qualità delle risposte è una proposta pratica, non una prescrizione testuale dell’articolo.
Gestire ciò che rimane sconosciuto
Quando una relazione resta sconosciuta, precisare quale scenario non si riesce a escludere e quale funzione ne sarebbe colpita. Chiedere al responsabile della funzione se la prova disponibile basta per la decisione corrente, chi cercherà un chiarimento e quale misura temporanea mantiene utilizzabile il percorso di recupero. Il valore della mappa sta nel rendere visibile questa decisione, non nel trasformare una risposta mancante in un collegamento inventato. Per le entità cui si applica DORA, la gestione del rischio TIC offre il contesto in cui registrare il limite informativo e la decisione sul rischio residuo.
Cercare punti comuni oltre l’hosting
Esaminare autenticazione, risoluzione dei nomi, rete, repository, gestione dei segreti e strumenti necessari al ripristino. Un servizio può avere dati replicati in due ambienti ma dipendere da un unico sistema di identità per accedervi. Un’alternativa può essere disponibile ma inutilizzabile perché la documentazione di emergenza risiede nel servizio interrotto.
Distinguere il percorso normale da quello di recupero. La soluzione di continuità deve essere valutata nel momento in cui una parte dell’infrastruttura è già indisponibile. Il piano di continuità operativa deve quindi indicare come gli operatori raggiungono le informazioni, le credenziali e i contatti necessari.
Non sommare automaticamente le probabilità di guasto dei fornitori come se fossero indipendenti. Quando manca una base quantitativa, descrivere lo scenario e la dipendenza comune invece di produrre un numero preciso ma ingiustificato. La mappa serve proprio a rendere visibili queste assunzioni.
Disegnare uno scenario di guasto comune verificabile
Per ogni funzione prioritaria scegliere un evento preciso, invece di scrivere soltanto «indisponibilità del cloud». Può mancare il servizio di identità usato da due fornitori, la connettività verso una regione oppure il sistema che consegna le chiavi necessarie alla ripartenza. Indicare quale componente viene meno, quali servizi diretti lo usano e quale attività aziendale si arresta. Se la relazione tra un fornitore e il componente è soltanto presunta, segnalarla nella mappa come ipotesi.
Descrivere anche la sequenza temporale. Il portale potrebbe continuare a funzionare per le sessioni già aperte, mentre nuovi operatori non riescono ad autenticarsi; l’assistenza potrebbe ricevere richieste ma non leggere le informazioni necessarie per rispondere. Questa differenza cambia la misura utile. Una copia dei dati non risolve un blocco delle credenziali, e un numero telefonico alternativo non basta se gli addetti non possono identificare le richieste.
Confrontare lo scenario con la tolleranza all’interruzione della funzione e con le prove disponibili. Una dichiarazione contrattuale di alta disponibilità descrive il servizio cui si riferisce, non necessariamente il funzionamento simultaneo di tutte le dipendenze. Chiedere al fornitore quali parti del percorso di recupero sono incluse nella prova citata. Registrare ciò che resta fuori: accesso del cliente, integrazioni, esportazione dei dati e supporto. Il risultato è una decisione circoscritta sullo scenario, non una stima numerica artificiale del rischio complessivo.
Esempio: portale clienti e assistenza sulla stessa dipendenza
Una società ipotetica utilizza un portale clienti del fornitore Alfa e un sistema di assistenza del fornitore Beta. Il piano di emergenza prevede che, in caso di indisponibilità del portale, i clienti aprano richieste nel sistema Beta. I fornitori sono diversi e la soluzione è inizialmente descritta come diversificata.
La verifica mostra che entrambi usano lo stesso servizio di identità per gli operatori interni. Inoltre, le istruzioni per attivare il canale alternativo sono conservate in uno spazio accessibile attraverso quell’identità. Una sua indisponibilità può bloccare contemporaneamente gestione del portale e assistenza.
La decisione non consiste necessariamente nel cambiare entrambi i fornitori. L’organizzazione prepara un accesso di emergenza controllato, una copia protetta delle istruzioni e un canale alternativo che non dipende dal medesimo percorso. L’esercizio verifica che gli operatori autorizzati possano usarli senza introdurre accessi permanenti eccessivi.
La tabella conserva la dipendenza originaria, la misura introdotta e il risultato della prova. Il rischio residuo include comunque altre interruzioni comuni non eliminate. L’esito viene descritto come riduzione di uno scenario specifico, non come indipendenza assoluta dei due servizi.
Valutare la sostituibilità con una prova concreta
Per ogni alternativa importante, verificare dati, configurazioni, competenze e tempi. Una seconda piattaforma può dipendere dallo stesso provider ma offrire una separazione utile rispetto a uno specifico guasto; oppure può usare un provider diverso e restare dipendente dallo stesso sistema di identità del cliente.
La prova di disaster recovery deve considerare l’operazione completa. Recuperare un file non dimostra che gli utenti possano riprendere il lavoro. Inserire nella prova almeno una transazione o un’attività rappresentativa, con le autorizzazioni e le dipendenze necessarie.
Se la migrazione richiede settimane, non descriverla come soluzione a un’interruzione tollerabile di poche ore. Può essere una valida strategia di uscita, ma risponde a una domanda diversa. Tenere distinti continuità immediata, ripristino e sostituzione del fornitore.
Tracciare per l’alternativa gli stessi nodi della soluzione principale: identità, rete, nomi di dominio, chiavi, personale autorizzato e istruzioni. Se due fornitori usano la stessa piattaforma cloud, chiedere quale componente specifico condividono prima di concludere che subiranno lo stesso guasto. Se usano infrastrutture diverse ma dipendono dalla stessa identità aziendale, lo scenario comune può rimanere.
Preparare un esercizio limitato e sicuro. Un operatore designato riceve uno scenario di indisponibilità e deve trovare contatti, credenziali d’emergenza e procedura senza usare la dipendenza dichiarata guasta. Esegue poi una transazione rappresentativa o una simulazione controllata, annotando dove si ferma. Non occorre interrompere il servizio reale per verificare se un manuale è raggiungibile o se il sostituto ha i diritti previsti.
Aggiornare la mappa quando cambia il servizio
Durante un incidente, la mappa deve permettere di cercare rapidamente i servizi che condividono una dipendenza segnalata. Assegnare un identificativo stabile ai nodi principali evita di affidarsi soltanto a nomi commerciali che cambiano. Il responsabile della continuità usa la mappa per contattare i titolari dei servizi e verificare il comportamento reale; l’evento osservato aggiorna poi le relazioni e il grado di fiducia delle informazioni.
Rivedere le relazioni dopo modifiche di hosting, acquisizioni, nuovi componenti, incidenti o cambiamenti del piano di recupero. Conservare la data dell’ultima conferma e le fonti superate. Una mappa elegante ma non mantenuta può creare un’affidabilità apparente peggiore di un’incertezza esplicita.
Prima di un rinnovo, selezionare le dipendenze che sostengono gli scenari più rilevanti e verificare se le informazioni sono ancora valide. Il risultato minimo è una decisione leggibile: quali cause comuni sono plausibili, quali alternative sono state provate e quali limiti restano accettati. Questo rende la concentrazione un tema operativo su cui agire, invece di un semplice conteggio di contratti.
Registrare anche la decisione di non cambiare fornitore. Può essere ragionevole se una sostituzione introduce rischi maggiori e sono state rafforzate le alternative operative. Il verbale dovrebbe dire quale scenario rimane, chi lo accetta e quando verrà riesaminato. Così l’analisi della quarta parte produce un’azione verificabile e può essere ripresa da chi subentra, invece di rimanere un disegno statico dell’architettura.
Conservare anche le dipendenze escluse
Se un componente viene escluso dall’analisi perché non sostiene la funzione esaminata, annotare il motivo e la fonte. Questa traccia evita di riaprire continuamente la stessa domanda e permette di riconoscere quando un cambiamento rende l’esclusione non più valida. Una futura integrazione potrebbe infatti trasformare un servizio accessorio in un passaggio necessario per il recupero.