Registro delle informazioni DORA: guida ISO 27001

Sono le 09:15 di un martedì. Sarah, responsabile della sicurezza delle informazioni di una fintech in rapida crescita, sta partecipando a una valutazione di preparazione con il responsabile conformità, il legale, il responsabile acquisti e l’architetto della sicurezza cloud. Il consulente esterno sta interpretando il ruolo dell’autorità di vigilanza DORA.

“Grazie per la presentazione”, dice. “Fornite il vostro Registro delle informazioni come richiesto da DORA Article 28, inclusi gli accordi contrattuali ICT a supporto di funzioni essenziali o importanti, la visibilità sul subappalto, la titolarità degli asset e le evidenze che il registro è mantenuto nell’ambito del vostro quadro di gestione dei rischi ICT.”

La prima risposta sembra sicura: “Abbiamo un elenco dei fornitori.”

Poi iniziano le domande.

Quali fornitori supportano l’autorizzazione dei pagamenti? Quali contratti includono diritti di audit, supporto in caso di incidente, impegni sulla localizzazione dei dati, diritti di risoluzione e supporto all’uscita? Quali piattaforme SaaS trattano dati personali dei clienti? Quali servizi cloud supportano funzioni essenziali o importanti? Quali subappaltatori operano dietro il fornitore di servizi di sicurezza gestiti? Quale proprietario interno dell’asset ha approvato la dipendenza? Quali rischi nel piano di trattamento del rischio ISO/IEC 27001:2022 sono collegati a questi fornitori? Quali voci della Dichiarazione di applicabilità giustificano i controlli?

Alle 10:30, il team ha aperto quattro fogli di calcolo, un’esportazione della CMDB, una cartella SharePoint con contratti in PDF, un elenco privacy dei responsabili del trattamento, un report di fatturazione cloud e uno strumento di tracciamento SaaS mantenuto manualmente. Nessuno di questi è coerente con gli altri.

Questa è la sfida pratica del Registro delle informazioni DORA nel 2026. L’applicazione di DORA è passata da “serve una roadmap” a “mostratemi le evidenze”. Per entità finanziarie, terzi fornitori di servizi ICT, responsabili della sicurezza delle informazioni, auditor interni e team di conformità, il registro non è più un modello amministrativo. È il tessuto connettivo tra contratti ICT, rischio dei fornitori, catene di subappalto, servizi cloud, asset ICT, funzioni critiche, titolarità della governance ed evidenze ISO/IEC 27001:2022.

L’approccio di Clarysec è semplice: non costruire il Registro delle informazioni DORA come un artefatto di conformità separato. Costruiscilo come un livello vivo di evidenze all’interno del tuo SGSI, supportato da gestione degli asset, sicurezza dei fornitori, governance dell’utilizzo del cloud, mappatura degli obblighi legali e normativi, metadati di audit e tracciabilità del trattamento del rischio.

Zenith Controls: guida alla conformità integrata di Clarysec Zenith Controls identifica tre controlli cardine dell’Allegato A di ISO/IEC 27001:2022 come particolarmente rilevanti per questo tema: A.5.9, inventario delle informazioni e degli altri asset associati; A.5.19, sicurezza delle informazioni nei rapporti con i fornitori; e A.5.20, gestione della sicurezza delle informazioni negli accordi con i fornitori. Questi controlli non sono documentazione aggiuntiva. Sono la dorsale operativa per dimostrare che il registro è completo, assegnato a un responsabile, aggiornato e verificabile.

Cosa si aspetta DORA dal Registro delle informazioni

DORA si applica dal 17 gennaio 2025 e introduce per il settore finanziario un corpus di regole sulla resilienza ICT in materia di gestione dei rischi ICT, segnalazione degli incidenti, test di resilienza, rischio di terze parti, accordi contrattuali, vigilanza sui terzi fornitori critici di servizi ICT e applicazione da parte delle autorità di vigilanza. Per le entità finanziarie identificate anche ai sensi del recepimento nazionale di NIS2, DORA opera come atto giuridico dell’Unione specifico di settore per i corrispondenti requisiti di gestione dei rischi di cibersicurezza e di segnalazione degli incidenti.

L’obbligo del registro si colloca nella disciplina DORA di gestione del rischio ICT di terze parti. DORA Article 28 richiede alle entità finanziarie di gestire il rischio ICT di terze parti come parte del quadro di gestione dei rischi ICT, restare pienamente responsabili della conformità anche quando utilizzano fornitori ICT, mantenere un registro delle informazioni per gli accordi contrattuali relativi ai servizi ICT e distinguere gli accordi che supportano funzioni essenziali o importanti.

DORA Article 29 aggiunge considerazioni sul rischio di concentrazione e sul subappalto. Ciò include sostituibilità, dipendenze multiple dallo stesso fornitore o da fornitori collegati, subappalto in paesi terzi, vincoli di insolvenza, ripristino dei dati, conformità in materia di protezione dei dati e catene di subappalto lunghe o complesse.

DORA Article 30 definisce poi la sostanza contrattuale che gli auditor si aspetteranno di vedere. Questa include descrizioni dei servizi, condizioni di subappalto, luoghi di trattamento dei dati, impegni di protezione dei dati, obblighi di accesso e ripristino, livelli di servizio, supporto in caso di incidente, cooperazione con le autorità, diritti di risoluzione, partecipazione alla formazione, diritti di audit e strategie di uscita per gli accordi a supporto di funzioni essenziali o importanti.

Un Registro delle informazioni DORA maturo deve rispondere a quattro domande pratiche.

Un registro debole è un foglio di calcolo che l’ufficio acquisti aggiorna una volta all’anno. Un registro solido è un set di dati governato che collega portafoglio fornitori, inventario degli asset, registro dei servizi cloud, repository contrattuale, registrazioni privacy, piani di continuità operativa, playbook di risposta agli incidenti, registro dei rischi ed evidenze ISO/IEC 27001:2022.

Perché ISO 27001 è la via più rapida verso un registro DORA difendibile

ISO/IEC 27001:2022 fornisce alle organizzazioni la struttura di sistema di gestione che spesso manca alle evidenze DORA. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di definire contesto, parti interessate, obblighi legali, normativi e contrattuali, ambito di applicazione, interfacce e dipendenze. È esattamente qui che DORA deve collocarsi nel SGSI, perché il registro dipende dalla conoscenza di quali servizi finanziari, fornitori ICT, clienti, autorità, piattaforme cloud e processi esternalizzati rientrano nell’ambito di applicazione.

Le clausole da 5.1 a 5.3 richiedono leadership, allineamento delle politiche, risorse, responsabilità e reporting all’alta direzione. Questo è rilevante perché DORA Article 5 attribuisce all’organo di gestione la responsabilità di definire, approvare, supervisionare e mantenere la responsabilità ultima del quadro di gestione dei rischi ICT, incluse le politiche relative ai servizi ICT di terze parti e i canali di reporting.

Le clausole da 6.1.1 a 6.1.3 sono il punto in cui il registro diventa basato sul rischio. ISO/IEC 27001:2022 richiede un processo ripetibile di valutazione del rischio, titolari del rischio, analisi di probabilità e conseguenze, trattamento del rischio, selezione dei controlli, una Dichiarazione di applicabilità e l’approvazione del rischio residuo da parte del titolare del rischio. Un registro DORA non collegato al trattamento del rischio diventa un elenco statico. Un registro collegato a scenari di rischio, controlli e proprietari diventa evidenza di audit.

Le clausole da 8.1 a 8.3 trasformano quindi la pianificazione in operazioni controllate. Supportano informazioni documentate, pianificazione operativa e controllo, controllo delle modifiche, controllo dei processi forniti esternamente, rivalutazioni del rischio pianificate, attuazione del trattamento e conservazione delle evidenze. Questo è critico per il 2026, perché le autorità di vigilanza non chiedono solo se un registro esisteva in un determinato momento. Chiedono se nuovi contratti, servizi modificati, nuovi subappaltatori, migrazioni cloud ed eventi di uscita sono acquisiti nel ciclo di governance.

Il livello dei controlli dell’Allegato A rafforza lo stesso punto. Rapporti con i fornitori, accordi con i fornitori, rischio della catena di fornitura ICT, monitoraggio dei servizi dei fornitori, acquisizione e uscita dai servizi cloud, gestione degli incidenti, continuità operativa, obblighi legali e normativi, privacy, backup, logging, monitoraggio, crittografia e gestione delle vulnerabilità contribuiscono tutti alla qualità del registro.

Zenith Blueprint: roadmap in 30 passaggi per auditor di Clarysec Zenith Blueprint spiega il fondamento degli asset nella fase Controlli in azione, passaggio 22:

Nella sua forma più strategica, un inventario degli asset funge da sistema nervoso centrale del tuo SGSI. Indica come viene effettuato il provisioning degli accessi (8.2), dove deve essere applicata la cifratura (8.24), quali sistemi richiedono backup (8.13), quali log vengono raccolti (8.15) e persino come vengono applicate le politiche di classificazione e conservazione (5.10, 8.10).

Questa citazione coglie il punto pratico. Non è possibile mantenere un Registro delle informazioni DORA affidabile se l’inventario degli asset sottostante non è affidabile. Se il registro indica “Core Banking SaaS”, ma l’inventario degli asset non mostra API, account di servizio, set di dati, fonti di log, chiavi di cifratura, dipendenze di backup e proprietari, il registro è incompleto dal punto di vista dell’audit.

Il modello dati Clarysec: un registro, molte viste sulle evidenze

Un Registro delle informazioni DORA non dovrebbe sostituire il registro dei fornitori, il registro degli asset o il registro dei servizi cloud. Dovrebbe collegarli. Clarysec progetta di norma il registro come un livello master di evidenze con relazioni controllate verso le registrazioni SGSI esistenti.

Il modello minimo praticabile ha sette oggetti collegati.

Questa struttura consente a un solo registro di supportare più richieste di evidenze. Un’autorità di vigilanza DORA può visualizzare gli accordi contrattuali a supporto di funzioni essenziali o importanti. Un auditor ISO può tracciare i controlli sui fornitori verso i riferimenti dell’Allegato A e il trattamento del rischio. Un revisore GDPR può vedere responsabili del trattamento, categorie di dati, ubicazioni e impegni di protezione dei dati. Un valutatore orientato a NIST può riesaminare governance della catena di fornitura, criticità dei fornitori, requisiti contrattuali e monitoraggio del ciclo di vita.

Il registro diventa più di “chi sono i nostri fornitori?”. Diventa un grafo delle dipendenze.

Fondamenti di policy che rendono il registro verificabile

Il set di politiche di Clarysec assegna al registro una sede operativa. Per le PMI, la Politica di sicurezza delle terze parti e dei fornitori - PMI Politica di sicurezza delle terze parti e dei fornitori - PMI inizia con un chiaro requisito di registro:

Un Registro dei fornitori deve essere mantenuto e aggiornato dal referente amministrativo o dagli approvvigionamenti. Deve includere:

La stessa politica per PMI stabilisce che i contratti devono contenere obblighi di sicurezza definiti:

I contratti devono includere clausole obbligatorie relative a:

Sebbene le clausole citate introducano nella politica stessa elenchi di campi e categorie di clausole obbligatorie, il messaggio attuativo è diretto: la governance dei fornitori deve essere documentata, assegnata e resa vincolante contrattualmente.

Per gli ambienti enterprise, la Politica di gestione del rischio di dipendenza dai fornitori di Clarysec Politica di gestione del rischio di dipendenza dai fornitori è ancora più vicina alle aspettative di vigilanza DORA:

Registro delle dipendenze dai fornitori: l’ufficio gestione fornitori (VMO) deve mantenere un registro aggiornato di tutti i fornitori critici, includendo dettagli quali servizi/prodotti forniti; se il fornitore è in fornitura esclusiva; fornitori alternativi disponibili o sostituibilità; termini contrattuali correnti; e una valutazione dell’impatto nel caso in cui il fornitore non fosse in grado di erogare il servizio o venisse compromesso. Il registro deve identificare chiaramente i fornitori ad alta dipendenza (ad esempio, quelli per i quali non esiste un’alternativa rapida).

Questo si mappa in modo preciso su DORA Article 29 in materia di rischio di concentrazione e sostituibilità. Se un fornitore è in fornitura esclusiva, supporta una funzione critica, opera in un paese terzo, utilizza una lunga catena di subappalto e non ha un percorso di uscita testato, il registro non dovrebbe nascondere quel rischio in una nota a testo libero. Dovrebbe segnalarlo, assegnare un proprietario e collegarlo al trattamento del rischio.

La Politica di sicurezza delle terze parti e dei fornitori enterprise di Clarysec Politica di sicurezza delle terze parti e dei fornitori esplicita l’ambito di applicazione:

Copre sia i fornitori diretti sia, ove applicabile, i loro subappaltatori, e include software di terze parti, infrastruttura, supporto e servizi gestiti.

Questa frase corrisponde a una lacuna DORA frequente. Molte organizzazioni censiscono i fornitori ICT diretti ma non documentano subappaltatori, sub-responsabili, strumenti dei servizi gestiti, piattaforme di supporto o software di terze parti incorporato in un servizio.

Anche le evidenze contrattuali sono rilevanti. La stessa politica enterprise include:

Diritto di audit, ispezione e richiesta di evidenze di sicurezza

Questa frase dovrebbe essere visibile nella checklist di revisione contrattuale. Se un contratto con un fornitore ICT critico non include diritti di audit o di richiesta di evidenze, il registro dovrebbe indicare un’azione di rimedio.

Le evidenze sugli asset sono altrettanto importanti. La Politica di gestione degli asset - PMI di Clarysec Politica di gestione degli asset - PMI stabilisce:

Il referente IT deve mantenere un inventario strutturato degli asset che includa, come minimo, i seguenti campi:

La Politica di gestione degli asset enterprise Politica di gestione degli asset stabilisce analogamente:

L’inventario degli asset deve contenere, come minimo:

Il registro non deve duplicare ogni campo relativo agli asset, ma deve fare riferimento all’inventario degli asset. Se un SaaS di monitoraggio dei pagamenti supporta il rilevamento delle frodi, il registro DORA dovrebbe collegarsi all’asset applicativo, al set di dati, agli account di servizio, alle integrazioni API, alle fonti di log e al titolare del processo aziendale.

I servizi cloud meritano una vista dedicata. La Politica di utilizzo del cloud - PMI di Clarysec Politica di utilizzo del cloud - PMI richiede:

Un Registro dei servizi cloud deve essere mantenuto dal fornitore IT o dal direttore generale. Deve registrare:

Questo è particolarmente utile per l’individuazione dello shadow IT. Un registro DORA che esclude servizi cloud acquistati fuori dal processo di approvvigionamento non supera la verifica pratica di completezza.

Infine, la Politica di conformità legale e normativa di Clarysec Politica di conformità legale e normativa trasforma la conformità integrata in un requisito del SGSI:

Tutti gli obblighi legali e normativi devono essere mappati a politiche, controlli e proprietari specifici all’interno del Sistema di gestione della sicurezza delle informazioni (SGSI).

Questo è il ponte tra registro DORA ed evidenze ISO 27001. Il registro non dovrebbe mostrare solo i fornitori. Dovrebbe mostrare quali politiche, controlli e proprietari soddisfano l’obbligo normativo.

Mappare i requisiti DORA alle evidenze ISO 27001 e Clarysec

La tabella seguente combina le principali aspettative sul registro con i controlli dell’Allegato A di ISO/IEC 27001:2022 e gli artefatti di evidenza operativi di Clarysec.

Questa mappatura è il punto in cui il registro smette di essere un foglio di calcolo e diventa un modello di evidenze. Ogni riga dovrebbe avere un proprietario del contratto, un proprietario del fornitore, un proprietario del servizio, un titolare del processo aziendale e un proprietario della conformità. Ogni relazione critica dovrebbe avere una registrazione di rischio, una checklist delle clausole contrattuali, un collegamento agli asset e una cadenza di monitoraggio.

Esempio pratico: mappare un contratto ICT alle evidenze ISO 27001

Immaginiamo che un’entità finanziaria utilizzi una piattaforma cloud di analisi antifrode. Il servizio acquisisce metadati delle transazioni, supporta lo scoring antifrode in tempo reale, si integra con la piattaforma di pagamento, memorizza identificativi cliente pseudonimizzati, utilizza un subappaltatore di hosting cloud e fornisce supporto gestito da una sede approvata in un paese terzo.

Una riga di registro debole dice: “Fornitore: FraudCloud. Servizio: analisi antifrode. Contratto firmato. Critico: sì.”

Una riga di registro adeguata alla vigilanza è molto diversa.

Ora il team di conformità può produrre un pacchetto di evidenze coerente. Il registro dei fornitori dimostra che il fornitore esiste e ha un proprietario. L’inventario degli asset dimostra che sistemi interni, API, set di dati e log sono noti. La checklist contrattuale dimostra che le clausole DORA obbligatorie sono state riesaminate. La valutazione del rischio dimostra che concentrazione, subappalto, protezione dei dati e resilienza operativa sono stati considerati. La Dichiarazione di applicabilità mostra quali controlli sono stati selezionati. Il riesame del monitoraggio dimostra che l’accordo non viene dimenticato dopo l’onboarding.

Lo Zenith Blueprint, fase Gestione del rischio, passaggio 13, raccomanda esattamente questo tipo di tracciabilità:

Riferimenti incrociati alle normative: se determinati controlli sono applicati specificamente per rispettare GDPR, NIS2 o DORA, puoi annotarlo nel Registro dei rischi (come parte della giustificazione dell’impatto del rischio) oppure nelle note della SoA.

È così che il registro DORA diventa evidenza ISO 27001 invece di burocrazia parallela.

La catena di fornitori e subappaltatori è il punto in cui la qualità del registro fallisce

I principali fallimenti del registro non sono causati dall’assenza di fornitori di primo livello. Sono causati da catene di dipendenza nascoste.

Un fornitore di servizi di sicurezza gestiti può utilizzare una piattaforma SIEM, un agente di telemetria endpoint, un sistema di gestione dei ticket e un team di triage offshore. Un payment processor può dipendere da hosting cloud, servizi di identità, basi dati antifrode e connettività di regolamento. Un fornitore SaaS può affidarsi a più sub-responsabili per analisi, e-mail, osservabilità, supporto clienti e backup.

DORA Article 29 impone attenzione al rischio di concentrazione e di subappalto. Anche NIS2 Article 21 richiede la sicurezza della catena di fornitura per fornitori diretti e prestatori di servizi e si aspetta che le entità considerino vulnerabilità specifiche di ciascun fornitore diretto, qualità complessiva dei prodotti, pratiche di cibersicurezza dei fornitori e procedure di sviluppo sicuro. Per le entità finanziarie soggette a DORA, DORA funge da corpus di regole specifico di settore per i requisiti sovrapposti di NIS2 in materia di gestione dei rischi di cibersicurezza e segnalazione degli incidenti, ma la logica della catena di fornitura è allineata.

Lo Zenith Blueprint di Clarysec, fase Controlli in azione, passaggio 23, fornisce un’indicazione pratica:

Per ogni fornitore critico, identifica se utilizza subappaltatori (sub-responsabili) che possono accedere ai tuoi dati o sistemi. Documenta come i tuoi requisiti di sicurezza delle informazioni sono ribaltati su tali soggetti, tramite i termini contrattuali del fornitore o tramite tue clausole dirette.

È qui che molte organizzazioni necessitano di azioni di rimedio nel 2026. I contratti firmati prima della preparazione a DORA potrebbero non includere trasparenza sui subappaltatori, diritti di richiesta delle evidenze di audit, cooperazione con le autorità, supporto in caso di incidente, supporto all’uscita o impegni sulle ubicazioni. Il registro dovrebbe quindi includere uno stato di rimedio contrattuale, ad esempio completo, lacuna accettata, rinegoziazione in corso o opzione di uscita richiesta.

Conformità integrata: DORA, NIS2, GDPR e NIST richiedono la stessa verità sulle dipendenze

Un Registro delle informazioni DORA ben progettato supporta più di DORA.

NIS2 Article 20 rende la cibersicurezza una responsabilità dell’organo di gestione tramite approvazione, supervisione e formazione. NIS2 Article 21 richiede analisi dei rischi, politiche, trattamento degli incidenti, continuità, sicurezza della catena di fornitura, acquisizione e manutenzione sicure, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e MFA ove opportuno. Queste aree si sovrappongono fortemente a ISO/IEC 27001:2022 e al modello di evidenze del registro.

GDPR aggiunge responsabilizzazione privacy. Il suo ambito territoriale può applicarsi a organizzazioni UE e non UE che trattano dati personali nel contesto di stabilimenti nell’UE, offrono beni o servizi a persone nell’UE o ne monitorano il comportamento. Le definizioni GDPR di titolare del trattamento, responsabile del trattamento, trattamento, pseudonimizzazione e violazione dei dati personali sono direttamente rilevanti per la mappatura dei fornitori ICT. Se il registro DORA identifica fornitori ICT e subappaltatori ma non identifica ruoli nel trattamento dei dati personali, categorie di dati, ubicazioni e misure di sicurezza, non supporterà le evidenze GDPR.

NIST CSF 2.0 offre un’ulteriore prospettiva utile. La sua funzione GOVERN richiede alle organizzazioni di comprendere missione, aspettative degli stakeholder, dipendenze, requisiti legali e contrattuali, servizi da cui altri dipendono e servizi da cui dipende l’organizzazione. Gli esiti GV.SC relativi alla catena di fornitura richiedono un programma di gestione del rischio della catena di fornitura, ruoli dei fornitori definiti, integrazione nella gestione del rischio aziendale, criticità dei fornitori, requisiti contrattuali, due diligence, monitoraggio del ciclo di vita, coordinamento degli incidenti e pianificazione post-relazione.

Una vista pratica di conformità integrata appare così.

L’obiettivo non è creare cinque flussi di lavoro di conformità. L’obiettivo è creare un unico modello di evidenze filtrabile per ciascun quadro di riferimento.

Dal punto di vista dell’auditor

Un’autorità di vigilanza DORA si concentrerà su completezza, funzioni essenziali o importanti, accordi contrattuali, subappalto, rischio di concentrazione, governance, reporting e sul fatto che il registro sia mantenuto. Potrebbe richiedere un campione di fornitori critici e aspettarsi di vedere clausole contrattuali, valutazioni del rischio, strategie di uscita, termini di supporto in caso di incidente ed evidenze della supervisione da parte della direzione.

Un auditor ISO/IEC 27001:2022 partirà dall’ambito di applicazione del SGSI, dalle parti interessate, dagli obblighi normativi, dalla valutazione del rischio, dalla Dichiarazione di applicabilità, dal controllo operativo e dalle informazioni documentate. Verificherà se i rapporti con i fornitori e gli inventari degli asset sono mantenuti, se i processi forniti esternamente sono controllati, se le modifiche attivano una rivalutazione e se le evidenze supportano l’applicazione dei controlli dichiarata.

Un valutatore NIST CSF 2.0 chiederà spesso profili attuali e target, aspettative di governance, mappatura delle dipendenze, criticità dei fornitori, integrazione contrattuale, monitoraggio del ciclo di vita e azioni di miglioramento prioritizzate.

Un auditor orientato a COBIT 2019 esaminerà tipicamente titolarità della governance, responsabilità dei processi, diritti decisionali, monitoraggio delle prestazioni, reporting del rischio e assurance. Chiederà se il registro è integrato nella governance aziendale, non soltanto mantenuto dalla funzione di conformità.

Zenith Controls aiuta a tradurre queste prospettive ancorando il tema ai controlli dell’Allegato A di ISO/IEC 27001:2022 A.5.9, A.5.19 e A.5.20, quindi usando l’interpretazione di conformità integrata per collegare asset, rapporti con i fornitori e accordi con i fornitori alle aspettative normative, di governance e di audit. Questa è la differenza tra “abbiamo un registro” e “possiamo difendere il registro”.

La Politica di audit e monitoraggio della conformità - PMI di Clarysec Politica di audit e monitoraggio della conformità - PMI affronta anche la qualità delle evidenze:

I metadati (ad esempio chi li ha raccolti, quando e da quale sistema) devono essere documentati.

Questo requisito è piccolo ma decisivo. In una richiesta di evidenze nel 2026, un foglio di calcolo privo di metadati di raccolta è debole. Un’esportazione del registro che mostra sistema sorgente, data di estrazione, proprietario responsabile, stato di approvazione e cadenza di riesame è più solida.

Risultanze comuni sul Registro delle informazioni DORA nel 2026

Le risultanze più frequenti sono pratiche.

Primo, incompletezza del registro. Servizi cloud, strumenti di supporto, piattaforme di monitoraggio, strumenti per sviluppatori, sistemi di gestione dei ticket e piattaforme di analisi dei dati spesso mancano perché l’ufficio acquisti non li ha classificati come servizi ICT.

Secondo, logica di criticità debole. Alcuni team classificano i fornitori come critici in base alla spesa, non all’impatto sull’attività. DORA considera se il servizio ICT supporta una funzione essenziale o importante.

Terzo, lacune nelle evidenze contrattuali. Gli accordi con i fornitori più datati spesso non contengono clausole adeguate a DORA per diritti di audit, supporto in caso di incidente, subappalto, cooperazione con le autorità, ubicazioni dei servizi, restituzione dei dati, risoluzione e supporto all’uscita.

Quarto, collegamento insufficiente agli asset. I registri elencano i fornitori ma non si collegano ad applicazioni, set di dati, API, identità, log, infrastruttura o servizi aziendali. Questo rende difficile l’analisi dell’impatto durante incidenti e indisponibilità dei fornitori.

Quinto, opacità sui subappaltatori. L’organizzazione conosce il fornitore principale ma non sa spiegare quali sub-responsabili o fornitori tecnici supportano il servizio.

Sesto, assenza di eventi attivanti per le modifiche. Un fornitore aggiunge un nuovo sub-responsabile, cambia regione di hosting, migra l’architettura o modifica l’accesso di supporto, ma nessuno aggiorna il registro o rivaluta il rischio.

Settimo, assenza di cadenza delle evidenze. Non esiste una frequenza definita per riesame dei fornitori, riesame contrattuale, validazione degli asset, riconciliazione del registro cloud o reporting alla direzione.

Questi problemi sono risolvibili, ma solo se il registro ha proprietari e flussi di lavoro.

Un piano pratico di miglioramento in 30 giorni

Parti dall’ambito di applicazione. Identifica tutte le funzioni aziendali che possono essere essenziali o importanti ai sensi di DORA. Per ciascuna funzione, elenca i servizi ICT da cui dipende. Non iniziare dalla spesa di approvvigionamento. Inizia dalla dipendenza operativa.

Riconcilia le fonti dati principali: registro dei fornitori, repository contrattuale, inventario degli asset e registro dei servizi cloud. Aggiungi le registrazioni privacy dei responsabili del trattamento e le dipendenze di risposta agli incidenti, ove rilevanti. L’obiettivo non è la perfezione il primo giorno. L’obiettivo è una dorsale unica del registro con le incognite chiaramente contrassegnate.

Classifica fornitori e servizi utilizzando criteri quali funzione supportata, sensibilità dei dati, sostituibilità operativa, concentrazione, subappalto, ubicazioni, impatto degli incidenti, tempo di ripristino e rilevanza normativa.

Riesamina i contratti per ogni accordo ICT essenziale o importante. Verifica se il contratto include descrizioni dei servizi, condizioni di subappalto, ubicazioni, impegni di protezione dei dati, accesso e ripristino, livelli di servizio, supporto in caso di incidente, diritti di audit, cooperazione con le autorità, risoluzione, partecipazione alla formazione e supporto all’uscita.

Mappa le evidenze ISO per ogni accordo critico. Collega registrazioni degli asset, voci di valutazione del rischio, controlli SoA, due diligence sui fornitori, riesami di monitoraggio, piani di continuità, playbook di risposta agli incidenti ed evidenze della strategia di uscita.

Assegna la cadenza. I fornitori critici possono richiedere riesame trimestrale, assurance annuale, riesame contrattuale prima del rinnovo e rivalutazione immediata in caso di modifica rilevante. I fornitori non critici possono essere riesaminati annualmente o al verificarsi di eventi attivanti.

Usa questa checklist per trasformare il registro in un processo operativo:

• Nomina un proprietario del registro DORA e un sostituto.
• Collega ogni riga del registro a un ID contratto e a un proprietario del fornitore.
• Collega ogni servizio ICT essenziale o importante alla funzione aziendale e alle registrazioni degli asset.
• Aggiungi campi relativi a subappaltatori e sub-responsabili, anche se inizialmente contrassegnati come sconosciuti.
• Aggiungi lo stato delle clausole contrattuali per i termini DORA critici.
• Aggiungi riferimenti al rischio ISO/IEC 27001:2022 e alla SoA.
• Aggiungi ruolo GDPR, dati personali e campi di ubicazione ove applicabile.
• Aggiungi cadenza di riesame e metadati dell’ultimo riesame.
• Crea regole di escalation per clausole mancanti, subappaltatori sconosciuti e rischio di concentrazione elevato.
• Riporta alla direzione le metriche di qualità del registro.

È qui che il metodo di implementazione in 30 passaggi di Clarysec, il set di politiche e Zenith Controls operano insieme. Zenith Blueprint fornisce il percorso di implementazione, dal trattamento del rischio e dalla tracciabilità SoA nel passaggio 13 fino all’inventario degli asset nel passaggio 22 e ai controlli sui fornitori nel passaggio 23. Le politiche definiscono chi deve mantenere i registri, quali evidenze contrattuali e sugli asset devono esistere e come vengono acquisiti i metadati di conformità. Zenith Controls fornisce la bussola di conformità integrata per mappare le stesse evidenze rispetto alle aspettative di audit DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST e COBIT 19.

Trasforma il registro in evidenza prima che lo chieda l’autorità di vigilanza

Se il tuo Registro delle informazioni DORA è ancora un foglio di calcolo scollegato da contratti, asset, fornitori, subappaltatori ed evidenze ISO 27001, il 2026 è l’anno per correggerlo.

Inizia usando Zenith Blueprint Zenith Blueprint per collegare trattamento del rischio, inventario degli asset e governance dei fornitori. Usa Zenith Controls Zenith Controls per mappare i controlli dell’Allegato A di ISO/IEC 27001:2022 A.5.9, A.5.19 e A.5.20 in evidenze di conformità integrata. Quindi rendi operativi i requisiti tramite le politiche Clarysec su fornitori, asset, cloud, conformità legale e monitoraggio dell’audit, incluse Politica di sicurezza delle terze parti e dei fornitori - PMI, Politica di gestione del rischio di dipendenza dai fornitori, Politica di sicurezza delle terze parti e dei fornitori, Politica di gestione degli asset - PMI, Politica di gestione degli asset, Politica di utilizzo del cloud - PMI, Politica di conformità legale e normativa e Politica di audit e monitoraggio della conformità - PMI.

Il momento migliore per correggere la qualità del registro è prima di una richiesta dell’autorità, di un audit interno, di un’indisponibilità del fornitore o di un rinnovo contrattuale. Il secondo momento migliore è adesso. Scarica le politiche Clarysec pertinenti, mappa il tuo registro attuale rispetto al modello di evidenze sopra descritto e prenota una valutazione del registro DORA per trasformare dati dispersi sui fornitori in evidenze adeguate alla vigilanza.