Mappare funzioni critiche e controlli nel framework DORA significa poter rispondere a una domanda precisa: se una dipendenza ICT si interrompe, quale attività finanziaria viene compromessa e quali prove dimostrano che l’organizzazione sa gestire l’impatto? Un inventario applicativo, da solo, non basta. Serve un collegamento verificabile tra funzione, processi, servizi ICT, asset, fornitori, controlli ed evidenze.
Il risultato utile per l’audit è una mappa che permetta di partire da una funzione e arrivare fino all’esito di un controllo, con responsabilità, versioni e lacune visibili. Di seguito un metodo operativo, con un esempio sul servizio di disposizione dei pagamenti.
Decidere cosa è critico prima di mappare i sistemi
Il regolamento DORA, regolamento (UE) 2022/2554, definisce all’articolo 3, punto 22, la «funzione critica o importante». La valutazione riguarda gli effetti di una sua interruzione o esecuzione carente sulla performance finanziaria, sulla solidità, sulla continuità dei servizi e delle attività o sul mantenimento della conformità alle condizioni e agli obblighi applicabili.
La criticità appartiene alla funzione, non automaticamente al software che la supporta. Un’applicazione può servire più funzioni con impatti diversi. Viceversa, una funzione può dipendere da molti sistemi, anche apparentemente secondari.
Per evitare classificazioni arbitrarie, documentare l’impatto dell’indisponibilità: servizi interrotti, clienti interessati, scadenze operative, conseguenze economiche e obblighi compromessi. La business impact analysis (BIA) può fornire questi elementi, purché la decisione finale sia motivata e approvata secondo la governance interna.
Non confondere questa classificazione con la designazione dei fornitori terzi critici di servizi ICT prevista dall’articolo 31. Sono valutazioni diverse: un fornitore può supportare una vostra funzione critica o importante senza essere stato designato come fornitore critico nel sistema di sorveglianza europeo.
Costruire la catena di mappatura nel framework DORA
L’articolo 8 disciplina l’identificazione e la documentazione delle funzioni aziendali supportate dall’ICT, degli asset e delle dipendenze rilevanti. Il percorso seguente traduce questi collegamenti in un modello utilizzabile per il quadro ordinario di gestione del rischio ICT. Le entità soggette al quadro semplificato dell’articolo 16 devono adeguarlo al proprio perimetro.
Registrare una decisione di classificazione verificabile
La scheda della funzione deve contenere un identificativo stabile, una descrizione del servizio reso, il responsabile di business e il perimetro organizzativo. A questi dati si aggiungono motivazione della classificazione, versione della BIA richiamata, data della valutazione e approvazione.
Una descrizione come «sistema pagamenti» è troppo ambigua: identifica forse un’applicazione, non necessariamente una funzione. Una formulazione più utile è «ricezione, autorizzazione e trasmissione delle disposizioni di pagamento per la clientela del perimetro X».
Registrare anche le esclusioni. Se una componente non rientra nella funzione, spiegare perché e chi ha validato la scelta. Le esclusioni non documentate diventano difficili da difendere quando un incidente rivela una dipendenza trascurata.
L’identificativo della funzione deve restare stabile anche quando cambiano nome, owner o tecnologia. In questo modo, le evidenze storiche conservano il collegamento con il perimetro a cui si riferivano.
Risalire alle dipendenze dirette e condivise
Nel framework DORA, una mappa utile non si ferma all’applicazione principale. Deve rendere visibili anche le dipendenze che possono impedirne l’utilizzo o il ripristino: gestione delle identità, connettività, DNS, database, chiavi crittografiche, monitoraggio e servizi di backup.
Per ogni collegamento indicare almeno il servizio ICT supportato, l’asset o il servizio esterno coinvolto, il relativo owner e l’effetto della sua indisponibilità. Distinguere le dipendenze indispensabili da quelle per cui esiste un’alternativa effettivamente verificata.
Gli asset condivisi meritano attenzione: lo stesso servizio di autenticazione può bloccare più funzioni contemporaneamente. Una mappa organizzata solo per applicazione rischia di nascondere questa concentrazione.
Per i fornitori, collegare il servizio erogato all’accordo contrattuale pertinente e ai dati del registro delle informazioni. I modelli del registro delle informazioni DORA, definiti dal regolamento di esecuzione (UE) 2024/2956, offrono una struttura ufficiale di riferimento. Il registro previsto dall’articolo 28, paragrafo 3, riguarda gli accordi contrattuali per l’utilizzo di servizi ICT, non soltanto quelli che supportano funzioni critiche o importanti.
Collegare il rischio al controllo, poi alla prova
Una dipendenza non genera automaticamente un controllo unico. Prima occorre descrivere lo scenario di rischio: accesso non autorizzato, perdita di dati, indisponibilità, alterazione delle transazioni o impossibilità di recuperare il servizio.
Il controllo deve poi specificare cosa viene verificato, su quale perimetro, da chi, con quale frequenza e con quale criterio di accettazione. «Backup attivo» non è sufficiente; «ripristino del database della funzione su ambiente isolato, con verifica della consistenza e dei tempi» è verificabile.
Per ogni controllo nel framework DORA, associare una prova di esecuzione e un esito, non soltanto la procedura che lo descrive. Una procedura dimostra il disegno del controllo; il verbale di test, i log e la revisione documentata ne mostrano l’esecuzione.
La guida alle evidenze di audit aiuta a distinguere questi livelli. Nella mappa, mantenere separati l’identificativo del controllo e quello delle singole evidenze: un controllo ricorrente produrrà più prove nel tempo.
Esempio operativo: il servizio di disposizione dei pagamenti
Consideriamo una funzione classificata come critica o importante dopo una valutazione interna. Il suo funzionamento dipende dal portale clienti, dal motore di autorizzazione, dal database delle disposizioni e da un servizio ICT esterno di trasmissione.
Supponiamo che la BIA stabilisca un obiettivo di ripristino di due ore (RTO) e una perdita massima di dati di quindici minuti (RPO). Sono valori illustrativi, non soglie imposte da DORA. Gli obiettivi reali devono essere coerenti con l’impatto della funzione e con gli obblighi applicabili.
Una matrice essenziale di controlli ed evidenze
La tabella mostra un possibile disegno operativo. Anche frequenze, campioni e modalità di verifica devono essere definiti dall’organizzazione, non copiati come requisiti universali.
| Dipendenza e rischio | Controllo da verificare | Owner del controllo | Evidenza attesa |
|---|---|---|---|
| Identità e accessi privilegiati: autorizzazioni improprie | Revisione degli accessi e verifica dell’autenticazione prevista | Responsabile IAM | Estrazione degli account, revisione approvata e ticket delle revoche |
| Database: perdita o incoerenza delle disposizioni | Ripristino e riconciliazione dei dati | Responsabile database | Log del ripristino, tempi misurati ed esito della riconciliazione |
| Infrastruttura: indisponibilità dell’ambiente principale | Test di commutazione e verifica delle dipendenze necessarie | Responsabile infrastruttura | Verbale del test, eventi tecnici e operazioni completate dopo la commutazione |
| Servizio esterno: interruzione della trasmissione | Verifica delle procedure di continuità e recupero concordate | Service owner interno | Rapporti del fornitore, ticket e risultati delle verifiche pertinenti |
La matrice del framework DORA deve consentire anche il percorso inverso: da un’evidenza deve essere possibile risalire al controllo, alla dipendenza e alla funzione coperta. Se un test interessa soltanto il database, non dimostra automaticamente la continuità dell’intero servizio di pagamento.
Quando un test dimostra davvero il recupero della funzione
Un ripristino tecnico completato entro due ore può comunque essere insufficiente. Il database potrebbe essere disponibile mentre il servizio di autenticazione resta irraggiungibile oppure le credenziali necessarie per trasmettere le disposizioni non sono utilizzabili.
Il verbale dovrebbe quindi riportare ambiente, versione della configurazione, orario iniziale e finale, punto di recupero dei dati e operazioni di business verificate. Per questo esempio, verificare anche che le disposizioni recuperate siano coerenti e che il riavvio non produca duplicazioni non gestite.
Se il test usa un ambiente diverso dalla produzione, documentare le differenze e i limiti della conclusione. Una prova parziale resta utile, ma va presentata come tale.
Quando un criterio non è soddisfatto, collegare il finding a una remediation con owner, scadenza ed evidenza di nuova verifica. Non chiudere il finding soltanto perché la modifica è stata installata: verificare che abbia risolto il problema osservato.
Assegnare responsabilità senza confondere i ruoli
Il responsabile della funzione valuta l’impatto sul servizio e valida le esigenze di continuità. L’owner tecnico mantiene le dipendenze e gestisce i controlli assegnati. Il responsabile del rapporto con il fornitore raccoglie le informazioni pertinenti e segue le azioni aperte.
Risk management e compliance verificano la coerenza del metodo secondo il modello organizzativo adottato. L’internal audit svolge la propria valutazione indipendente: non dovrebbe diventare il proprietario operativo dei controlli che deve esaminare.
Nella mappa del framework DORA, distinguere almeno chi esegue il controllo, chi ne riesamina l’esito e chi può approvare un’eventuale accettazione del rischio residuo. La dicitura «responsabile: IT» non identifica una responsabilità gestibile.
Ogni cambio di owner deve lasciare traccia della decorrenza e del passaggio delle attività aperte. Le pratiche di audit trail e tracciabilità delle modifiche servono anche a ricostruire quale versione della mappa fosse valida al momento di un test o di un incidente.
Aggiornare la mappa quando cambia la dipendenza
Una mappa approvata non resta corretta per inerzia. Migrazioni cloud, sostituzioni di fornitori, nuovi servizi, modifiche architetturali e incidenti possono cambiare l’impatto o rendere obsolete le prove.
Definire eventi di aggiornamento espliciti. Una modifica significativa deve avviare la revisione dei collegamenti interessati, degli owner e dei controlli. L’articolo 8 prevede, tra l’altro, valutazioni del rischio in occasione di modifiche rilevanti nelle infrastrutture, nei processi o nelle procedure ICT secondo il relativo perimetro applicativo.
Operativamente, confrontare la mappa con il sistema di gestione delle modifiche, l’inventario degli asset e il registro dei fornitori. Se compare un nuovo database ma nessuna funzione lo richiama, chiarire se manca un collegamento o se l’asset è estraneo al perimetro.
La manutenzione del framework DORA deve includere anche le evidenze: una prova riferita alla configurazione precedente può non coprire quella attuale. Non occorre ripetere indistintamente ogni test, ma motivare quali evidenze restano pertinenti e quali richiedono una nuova verifica.
Un incidente dovrebbe inoltre alimentare la revisione della mappa quando rivela una dipendenza sconosciuta, un controllo inefficace o un tempo di recupero diverso da quello atteso.
Tre errori che rendono la mappatura poco difendibile
Usare la CMDB come risposta completa. La CMDB può documentare asset e relazioni tecniche, ma normalmente non basta a motivare la criticità della funzione, identificare le decisioni di business e dimostrare l’esecuzione dei controlli. Va collegata a queste informazioni, non sostituita con un duplicato manuale.
Equiparare uno SLA a una prova di resilienza. Un impegno contrattuale descrive una prestazione attesa. Non dimostra, da solo, che il servizio recuperi entro gli obiettivi della vostra funzione. Servono elementi pertinenti, come risultati di test, dati di servizio e verifiche dei meccanismi di recupero. La natura e la sufficienza delle prove dipendono dal rapporto e dal rischio.
Estendere una prova oltre il suo perimetro. Nel framework DORA, un controllo condiviso può supportare più funzioni, ma il riuso dell’evidenza richiede di verificare configurazione, ambiente e scenario coperti. Un test di backup su un’applicazione non copre automaticamente tutte quelle che utilizzano lo stesso fornitore.
Questi errori hanno una conseguenza comune: la documentazione sembra completa, ma non consente di verificare se la funzione sia realmente protetta rispetto allo scenario considerato.
Checklist prima di consegnare la mappa all’auditor
Prima dell’export, selezionare una funzione e seguire tutta la catena. È una verifica concreta della navigabilità della mappa, non una valutazione esaustiva della conformità.
- Classificazione: la motivazione richiama impatti documentati e un’approvazione identificabile.
- Dipendenze: applicazioni, asset condivisi e servizi esterni rilevanti sono collegati con identificativi coerenti.
- Controlli: ogni controllo ha owner, perimetro, modalità di esecuzione e criterio di accettazione.
- Evidenze: le prove indicano data, versione, esito e limiti di copertura.
- Remediation: i finding hanno responsabile, scadenza e verifica di chiusura oppure una decisione sul rischio residuo secondo la governance interna.
- Tracciabilità: l’export permette di ricostruire collegamenti e versioni senza dipendere dalla spiegazione orale di una sola persona.
Se manca uno di questi passaggi, registrare la lacuna. Un perimetro incompleto ma dichiarato è più verificabile di una copertura totale soltanto presunta.
Domande frequenti
Una certificazione ISO 27001 sostituisce questa mappatura? No. Può fornire controlli ed evidenze riutilizzabili, ma occorre verificarne perimetro e pertinenza rispetto alle funzioni, alle dipendenze e ai requisiti DORA applicabili.
Serve un controllo diverso per ogni funzione? Non necessariamente. Nel framework DORA, un controllo condiviso può coprire più funzioni se la relazione è esplicita e le evidenze dimostrano la copertura dei rispettivi perimetri.
È possibile iniziare con un foglio di calcolo? Sì. Usare identificativi stabili, collegamenti alle evidenze e versioni controllate. Quando aumentano relazioni e collaboratori, verificare che il metodo mantenga ownership, cronologia e coerenza dei collegamenti.
Chi decide se una funzione è critica o importante? La decisione va assunta secondo la governance dell’entità, sulla base degli impatti documentati e dei criteri applicabili. Non dovrebbe essere una classificazione automatica decisa esclusivamente dal team IT.
Preparare un evidence pack verificabile
La mappa è pronta per il confronto quando permette di ricostruire funzione, dipendenze, controllo, prova ed eventuale remediation. AuditReady centralizza evidenze con ownership, versioni e audit trail e consente export per auditor e stakeholder.
Per valutare questo flusso sul vostro perimetro, richiedete una demo AuditReady dedicata a DORA. Il metodo descritto è informazione operativa e non costituisce una valutazione legale dell’applicabilità o della conformità dell’entità.
audit-ready evidence pack demo / not legal advice