Processi e governance

Policy e procedure DORA: quali servono e come mantenerle aggiornate

Redazione GAPOFF · Aggiornato il 2026-05-19 · Revisione: 2026-05-19

Risposta rapida

Le policy DORA non devono essere un pacchetto di documenti statici. Devono descrivere come l’organizzazione governa il rischio ICT, classifica incidenti, gestisce fornitori, pianifica test, controlla cambiamenti, conserva evidenze e riesamina il framework. Una procedura è utile solo se è collegata a ruoli, workflow e prove operative.

Verifica se la tua organizzazione rientra in DORA

Perimetro, cinque pilastri, gap analysis e report audit-ready.

Verifica gratis →

Perché questo tema è importante

La tentazione più comune è acquistare o scrivere un set di policy “DORA compliant” e considerare chiuso il progetto documentale. Ma DORA non premia la carta: richiede che le policy riflettano processi reali. Una procedura di incident reporting che non coincide con il ticketing, le escalation e le persone reperibili è un rischio.

Le policy devono inoltre essere mantenute. Nuovi atti tecnici, cambiamenti organizzativi, nuovi fornitori, incidenti, test falliti e audit finding possono richiedere aggiornamenti. Una governance documentale senza owner e ciclo di revisione diventa rapidamente obsoleta.

Quadro normativo e fonti ufficiali

DORA prevede un framework di gestione del rischio ICT con strategie, politiche, procedure, protocolli e strumenti. Gli standard tecnici specificano ulteriori elementi per risk management, incident classification, policy sui servizi ICT che supportano funzioni critiche o importanti e subcontracting. Per questo le policy devono essere allineate al regolamento e ai relativi atti tecnici applicabili.

Le fonti da usare come base sono il Regolamento (UE) 2022/2554 su EUR-Lex, la pagina EBA dedicata a DORA, gli atti delegati e di esecuzione della Commissione europea e, per gli operatori vigilati in Italia, le comunicazioni della Banca d’Italia su incidenti ICT e Register of Information.

Cosa significa per l'azienda

Per l’azienda, le policy dovrebbero coprire almeno governance ICT risk, asset e classificazione, gestione incidenti, continuità e ripristino, test di resilienza, gestione fornitori ICT, change management, backup, logging, accessi, vulnerability management e reporting.

Ogni documento dovrebbe avere owner, approvatore, data di efficacia, ciclo di revisione, collegamento ai controlli e modalità di prova. Una procedura senza evidenze associate è difficile da verificare.

Metodo operativo per policy DORA

Creare un inventario delle policy esistenti e mapparle ai pilastri DORA.
Identificare duplicazioni, vuoti e contraddizioni tra documenti IT, security, compliance e vendor management.
Definire un modello documentale: scopo, perimetro, ruoli, processo, evidenze, eccezioni e riesame.
Collegare ogni policy a controlli, workflow, registri e owner.
Prevedere approvazione formale e comunicazione alle funzioni coinvolte.
Stabilire ciclo di revisione periodico e revisione straordinaria dopo eventi rilevanti.
Mantenere versioning e storico modifiche, perché anche l’evoluzione della policy è evidenza di governance.

Mappa pratica: requisito, controllo, evidenza

| Area | Domanda di controllo | Evidenza utile | Rischio se manca | |---|---|---|---| | Governance | Chi approva e riesamina il presidio? | Verbali, policy approvate, dashboard | Decisioni non dimostrabili | | ICT risk | Il rischio ICT è valutato e aggiornato? | Risk register, assessment, remediation | Rischio residuo non governato | | Incidenti | L'incidente viene classificato ed escalato? | Ticket, timeline, report, post-mortem | Ritardi e segnalazioni incoerenti | | Fornitori ICT | Il servizio esterno è censito e valutato? | ROI, contratto, assessment, exit strategy | Dipendenze non presidiate | | Test e continuità | La resilienza è provata periodicamente? | Piano test, risultati, lesson learned | Piani teorici non verificati |

Esempio pratico

Un intermediario ha tre procedure separate: gestione incidenti IT, data breach GDPR e business continuity. DORA richiede di collegarle. Il progetto non elimina tutto, ma crea una procedura di incident management ICT che include criteri DORA, escalation privacy quando sono coinvolti dati personali, collegamento al piano di continuità e template di report. Le procedure esistenti vengono armonizzate invece di produrre un quarto documento isolato.

Errori comuni da evitare

Creare policy standard non adattate al perimetro reale.
Non collegare procedure ai workflow usati dai team.
Avere documenti contraddittori su incidenti, escalation e business continuity.
Non assegnare owner e ciclo di revisione.
Non formare le persone sulle procedure aggiornate.
Non mantenere storico versioni e approvazioni.

Come GAPOFF aiuta

GAPOFF aiuta a trasformare policy e procedure in controlli operativi. Ogni documento può essere collegato a requisiti DORA, evidenze, scadenze, owner e remediation. Il modulo Incident & Breach Ops consente di verificare se la procedura incidenti è davvero applicabile; Vendor Risk Management collega policy e clausole fornitori; Business Continuity collega procedure e test di ripristino.

Collegamenti interni consigliati per il coding agent: Modulo GAPOFF DORA, Vendor Risk Management, Incident & Breach Ops, Business Continuity, Trust Center.

La DORA non si gestisce con Excel.

Perimetro, rischio ICT, incidenti, Register of Information, fornitori ed evidenze devono essere collegati e dimostrabili. GAPOFF unifica DORA, Incident & Breach Ops, Vendor Risk, Business Continuity, GDPR, NIS2 e ISO 27001 in un unico sistema audit-ready.

Scopri il modulo DORA →

Checklist operativa

Inventario policy esistenti
Mappatura ai pilastri DORA
Gap documentali identificati
Owner e approvatore assegnati
Procedure collegate ai workflow
Versioning attivo
Riesame periodico pianificato
Formazione sulle procedure completata

Trasforma la checklist in attività tracciabili

Con GAPOFF ogni voce diventa un controllo con owner, scadenza ed evidenza — non un foglio Excel. Modulo DORA →

Roadmap consigliata di mantenimento

| Frequenza | Attività | Output atteso | |---|---|---| | Settimanale | Verifica task aperti, incidenti e remediation scadute | Aggiornamento stato operativo | | Mensile | Riesame di gap, fornitori critici e qualità evidenze | Report per compliance e risk | | Trimestrale | Sintesi management su rischi, incidenti, test e budget | Dashboard executive e verbale | | Annuale | Riesame completo del framework e del Register of Information | Evidence pack e piano di miglioramento |

FAQ

Quali policy DORA sono indispensabili?

Dipende dal perimetro, ma di norma servono policy su ICT risk, incident management, business continuity, testing, vendor risk, change management, accessi, backup, logging e vulnerability management.

Posso usare policy ISO 27001 per DORA?

Sì, se sono aggiornate e integrate con requisiti DORA. Non basta però citare ISO 27001: serve mappatura ai requisiti specifici e alle evidenze operative.

Ogni policy deve essere approvata dal board?

Non necessariamente ogni documento operativo, ma le policy principali e il framework di rischio ICT richiedono un livello di approvazione coerente con la governance aziendale.

Quando va aggiornata una procedura DORA?

Almeno secondo il ciclo di revisione previsto e dopo eventi rilevanti: incidenti, test, audit finding, nuovi fornitori, cambiamenti di sistemi o aggiornamenti normativi.

Modulo GAPOFF DORA

Perimetro, cinque pilastri DORA, Register of Information, gap analysis, remediation con owner e scadenze, vendor risk ICT, incidenti e report audit-ready. Cross-mapping automatico con NIS2, ISO 27001 e GDPR.

Vai al modulo DORA →

Fonti ufficiali e riferimenti

Disclaimer legale

Questo contenuto ha finalità informative e di orientamento generale. Non costituisce consulenza legale, tecnica, fiscale o organizzativa personalizzata. Per determinare obblighi, responsabilità e misure applicabili al caso concreto, è necessario svolgere una valutazione specifica con professionisti qualificati e fonti ufficiali aggiornate.

FAQ