Costruire una matrice di assegnazione delle responsabilità per DORA e NIS2

Se oggi un auditor ti chiedesse: “Chi è responsabile di questo controllo, chi lo approva e chi può produrre le evidenze?”, il tuo team risponderebbe in modo coerente?

La maggior parte delle organizzazioni pensa di avere già una risposta chiara perché possiede un piano di progetto, un foglio di calcolo o una tabella RACI nascosta in un drive condiviso. Di solito funziona finché non bisogna dimostrare la titolarità sotto pressione. Negli ambienti regolamentati, quella pressione arriva durante la gestione degli incidenti, le revisioni di terze parti, il testing dei controlli e le richieste formali di audit.

Una matrice di assegnazione delle responsabilità viene spesso trattata come una comodità di project management. È una visione troppo limitata. In pratica, può essere il meccanismo che collega policy, esecuzione dei controlli, approvazione, escalation ed evidenze in un’unica struttura visibile. Senza questa struttura, le persone improvvisano. L’improvvisazione è il punto in cui mancano le approvazioni, falliscono i passaggi di consegne dei controlli e le evidenze finiscono sparse tra ticket, caselle di posta e portali dei fornitori.

Il problema non è che i team non assegnino il lavoro. Lo fanno. Il problema è che assegnazione del lavoro e accountability non sono la stessa cosa. Un security engineer può eseguire una revisione. Un operations manager può coordinare il change. Un compliance lead può raccogliere le evidenze. Nulla di tutto questo dice chi sia responsabile dell’esito del controllo.

Questa distinzione conta ancora di più oggi perché le aspettative di governance nell’IT sono andate ben oltre il semplice “qualcuno è stato coinvolto”. Richiedono una catena di titolarità difendibile. Una matrice di assegnazione delle responsabilità ben costruita non si limita a descrivere i task. Mostra chi decide, chi esegue, chi deve essere consultato, chi deve essere informato e chi firma quando il controllo deve resistere all’esame.

Oltre il piano di progetto

La maggior parte degli articoli sulla RAM si ferma al coordinamento dei team. Spiegano le lettere, mostrano un esempio generico di lancio e danno per concluso il lavoro. Va bene per attività di delivery semplici. Non è sufficiente quando la stessa organizzazione deve gestire controlli di sicurezza, servizi ICT esternalizzati, segnalazione degli incidenti, approvazioni di policy ed evidenze di audit.

Una matrice di assegnazione delle responsabilità è uno dei più antichi strumenti di governance di progetto nella moderna pratica IT, e il modello RACI è diventato ampiamente standardizzato attraverso l’uso diffuso nel project management, inclusi i riferimenti nelle tradizioni PMBOK, come descritto nella panoramica dell'Institute of Project Management sulla responsibility assignment matrix. La sua durata nel tempo deriva da un design semplice. I task o deliverable si collocano su un asse, i ruoli sull’altro, e ciascun ruolo viene marcato come Responsible, Accountable, Consulted o Informed.

Questo contesto storico è importante perché il modello sopravvive per una ragione. Risolve un problema operativo persistente: troppe persone che toccano lo stesso deliverable senza un unico owner del risultato. Nell’IT, questo problema si presenta ovunque. La sicurezza scrive uno standard, le operations implementano un controllo, il legal revisiona un avviso, un fornitore fornisce i log e la compliance si ritrova a spiegare chi fosse responsabile dell’esito.

Dove l’uso convenzionale del RACI si rompe

La versione di progetto del RACI di solito mappa attività come “deploy release” o “approva scope”. I team regolamentati hanno bisogno di altro. Hanno bisogno che la titolarità sia mappata su:

• Controlli e sotto-controlli come revisioni degli accessi, verifica dei backup, classificazione degli incidenti o due diligence dei fornitori
• Obblighi di evidenza come screenshot, approvazioni di policy, log esportati, registri di review e approvazioni delle eccezioni
• Dipendenze di terze parti in cui una parte del controllo è in capo a un fornitore ma l’accountability rimane interna
• Percorsi di escalation per approvazioni mancate, esecuzione fallita del controllo o evidenze assenti

Una matrice diventa utile quando risponde alla domanda dell’audit prima ancora che l’auditor la ponga.

Questo cambia il ruolo del documento. Smette di essere un artefatto di pianificazione e diventa parte del sistema di governance. Se la tua matrice non riesce a identificare l’owner di un controllo fallito e la persona che ne approva la remediation, non sta servendo l’organizzazione dove vive il rischio.

Il vero test

Un test pratico è semplice. Prendi un controllo critico e poni quattro domande.

1. Chi lo esegue?
2. Chi è responsabile se fallisce?
3. Chi deve essere consultato prima che il controllo cambi?
4. Chi deve essere informato quando il risultato impatta su rischio, clienti o reporting?

Se le tue risposte dipendono dalla memoria, dalle relazioni o da chi capita online, la matrice manca o è inefficace. Una RAM matura riduce l’ambiguità prima che il problema si presenti. Ecco perché appartiene alla governance, non solo all’amministrazione di progetto.

Comprendere il framework di base

Una matrice di assegnazione delle responsabilità funziona perché costringe i team a separare l’azione dall’accountability. Non sono intercambiabili. Qualcuno può fare il lavoro e non possedere comunque l’esito finale.

Il modello è antico, ma si adatta ancora all’IT moderno perché il problema di fondo non è cambiato. Il lavoro cross-funzionale genera confusione se l’autorità non è esplicita. Ecco perché il framework resta valido.

Cosa significa davvero ciascun ruolo

Responsible significa la persona o il team che svolge il lavoro. In contesti operativi, può trattarsi di una funzione di engineering, service desk, analista di sicurezza o responsabile della vendor management. Possono esserci più parti Responsible se il task lo richiede.

Accountable significa che una persona possiede l’esito. Quella persona risponde di completamento, qualità, tempestività e firma finale. È il ruolo che conta di più quando un controllo fallisce o le evidenze vengono contestate.

Consulted significa una relazione bidirezionale. Queste persone forniscono input prima che una decisione o un’azione sia definitiva. Nell’IT regolamentato, spesso includono consulenti legali, privacy, architettura di sicurezza, risk o procurement.

Informed significa comunicazione unidirezionale. Questi stakeholder hanno bisogno di visibilità, ma non partecipano alla decisione.

La regola più importante è semplice: un solo owner Accountable per task o controllo. La spiegazione dell'Institute of Project Management su RAM e RACI evidenzia perché questo conta negli ambienti tecnologici. Un unico owner accountable riduce l’ambiguità decisionale nella delivery multi-team, nella risposta agli incidenti e nella titolarità delle evidenze.

Perché un solo owner Accountable è il perno

I team spesso resistono a questa regola perché la realtà sembra più disordinata del modello. Diranno che un comitato possiede il processo, oppure che sicurezza e operations sono congiuntamente accountable. In pratica, l’accountability condivisa significa di solito decisioni ritardate e firme poco chiare.

I comitati possono governare. Non dovrebbero possedere i singoli esiti dei controlli.

Quando le evidenze arrivano in ritardo, quando bisogna accettare un’eccezione o quando un regolatore chiede chi abbia approvato un processo, un owner nominato è l’unica risposta che regge. Puoi comunque avere molti contributori. Puoi comunque avere ampia consultazione. Ma solo una persona dovrebbe portare il marcatore finale di accountability nella matrice.

Regola pratica: se due persone sono marcate come Accountable, in realtà non lo è nessuna delle due.

RACI e varianti operative

RACI è la struttura più familiare, ma non è l’unica utile. Alcuni team usano RASCI, che aggiunge Support. Può aiutare quando i team operativi devono distinguere tra chi svolge il lavoro e un altro ruolo che fornisce tooling, accesso o coordinamento.

Per esempio, un identity engineer può essere Responsible per l’esecuzione della revisione trimestrale degli accessi, mentre un platform team supporta la generazione del report. Questo ruolo di supporto può avere peso operativo, soprattutto quando il processo dipende dall’accesso ai sistemi o dall’automazione di un altro team.

Tuttavia, la variante conta meno della logica. Una matrice di assegnazione delle responsabilità funziona quando risponde chiaramente a quattro domande pratiche:

Una buona matrice è rigorosa dove serve e semplice ovunque altrove. Se il framework diventa troppo sofisticato, le persone smettono di usarlo. Se è troppo vago, non sopravvivrà all’audit o alla pressione di un incidente.

La RAM negli ambienti regolamentati

Nell’IT regolamentato, la titolarità deve fare più che coordinare il lavoro. Deve supportare la prova.

È qui che la matrice di assegnazione delle responsabilità cambia natura. Smette di essere un artefatto di progetto e diventa una mappa dei controlli. Negli ambienti IT regolamentati, una RAM diventa una mappa della titolarità dei controlli e della titolarità delle evidenze. DORA si applica dal 17 gennaio 2025 e amplia l’accountability per il rischio ICT e la supervisione delle terze parti, mentre NIS2 aumenta la responsabilità del management per la governance della sicurezza, come indicato in questo approfondimento sulla matrice di assegnazione delle responsabilità e il suo uso nella governance.

Il cambiamento è sottile ma importante. Le vecchie abitudini di compliance si concentravano sull’esistenza della policy. La realtà normativa moderna si preoccupa se l’organizzazione può mostrare chi possiede l’esecuzione, chi ha approvato il risultato e chi può produrre le evidenze senza ricostruire il processo dopo il fatto.

Cosa seguono davvero regolatori e auditor

Gli auditor raramente partono dal tuo organigramma. Seguono un percorso di controllo.

Chiedono quale sia lo scopo del controllo, chi lo possieda, come funzioni, dove si trovino le evidenze e come vengano gestite le eccezioni. Se il controllo dipende da un fornitore, chiedono anche chi gestisca quella dipendenza e chi esamini il contributo del fornitore.

Una matrice debole fallisce esattamente in quel punto. Può mostrare che “IT” è responsabile, “management” è accountable o “security” è consulted. Queste etichette sono troppo generiche per essere utili. Non identificano l’autorità decisionale, la titolarità delle evidenze o la responsabilità di escalation.

La catena di controllo conta più dell’elenco dei task

Negli ambienti regolamentati, la modalità di fallimento chiave non è “chi esegue il task”. È chi può dimostrare che è successo e chi firma. Questa distinzione diventa evidente in esempi come:

• Gestione degli incidenti in cui un team rileva, un altro fa triage, il legale valuta le implicazioni di reporting e il management approva la comunicazione esterna
• Supervisione di terze parti in cui il procurement gestisce il percorso contrattuale, la sicurezza revisiona i controlli, le operations dipendono dal servizio e risk o compliance necessitano di evidenze di supervisione
• Governance degli accessi in cui i proprietari della piattaforma eseguono le azioni di review, i manager convalidano le autorizzazioni e la compliance necessita prova di completamento e approvazione

Questo è anche il motivo per cui le discipline di governance adiacenti si intersecano. I team che già gestiscono obblighi di reporting transfrontaliero riconoscono spesso lo stesso schema in altri domini. Le questioni di governance pratiche alla base della ESG compliance for multinational corporations sono diverse nel contenuto, ma simili nella struttura: la titolarità nominata, le approvazioni documentate e le evidenze tracciabili contano più delle dichiarazioni generiche di intenti.

Una breve spiegazione tecnica può aiutare a inquadrare questo cambiamento di accountability in termini operativi:

Perché l’accountability del management cambia il design

Una volta che entra in gioco l’accountability del management, una titolarità vaga diventa un difetto di governance. Una matrice per uso regolamentato deve collegare ogni controllo o processo importante a un ruolo con autorità sufficiente per approvare azioni, allocare attenzione e accettare un’escalation.

Questo di solito significa mappare per funzione e diritti decisionali, non per la persona che ha scritto per ultima la procedura. Per esempio, “Security Operations Lead” è spesso più stabile di un nome personale nella matrice di base, ma l’organizzazione ha comunque bisogno di un’assegnazione aggiornata dietro quel ruolo.

Le migliori matrici leggono come verità operativa, non come teoria amministrativa.

Una RAM forte chiarisce anche dove finiscono le dipendenze esterne e dove resta la responsabilità interna. Un fornitore può generare log, ospitare sistemi o contribuire con report. Il fornitore non assorbe la tua accountability. Qualcuno all’interno dell’organizzazione deve comunque possedere la supervisione, rivedere le evidenze e firmare l’esito del controllo.

Come costruire una matrice pronta per l’audit

Una matrice di assegnazione delle responsabilità pronta per l’audit parte dall’ambito, non dalle lettere. Se inizi compilando caselle in un foglio di calcolo, produrrai una tabella ordinata che non corrisponde all’ambiente di controllo.

Parti dagli asset, dai processi e dagli obblighi che contano. In pratica, significa i tuoi servizi critici, i controlli che li supportano, le policy che definiscono le aspettative e le evidenze che dimostrano che i controlli hanno operato. Solo allora dovresti mappare la titolarità.

Parti dai controlli e dalle evidenze

Un primo passaggio utile di solito include:

• Controlli operativi core come incident management, access review, verifica dei backup, approvazione dei change, supervisione dei logging e review delle terze parti
• Processi di governance come approvazione delle policy, gestione delle eccezioni, review dei controlli e tracciamento delle remediation
• Attività che producono evidenze come review del management, export di report, approvazioni dei ticket, attestazioni dei fornitori e registri di firma

Molti team traggono beneficio dal rivedere come raccolgono e strutturano già le audit evidence in practice. La matrice e il modello delle evidenze dovrebbero rafforzarsi a vicenda. Se evolvono separatamente, la titolarità dei controlli e la titolarità delle prove si allontanano.

Definisci i ruoli in base all’autorità, non al job title

I job title sono spesso troppo locali e troppo instabili. In un’azienda c’è un Head of Infrastructure. In un’altra un Platform Director. In una terza quel lavoro è suddiviso tra Site Reliability e Enterprise IT. La matrice dovrebbe riflettere l’autorità necessaria per prendere una decisione, non il branding di un ruolo.

Le definizioni di ruolo utili sono di solito funzionali. Esempi includono:

• CISO per la titolarità dei controlli di sicurezza e l’escalation
• IT Operations Manager per l’esecuzione dei processi operativi
• Legal and Compliance per l’interpretazione del reporting, gli obblighi di review e il coordinamento normativo
• CEO o Board per la visibilità executive, l’approvazione formale o l’escalation strategica

Se un ruolo non ha l’autorità per approvare l’esito, probabilmente non dovrebbe avere status Accountable. Una matrice che ignora i diritti decisionali sembra completa ma fallisce alla prima vera eccezione.

Usa una riga per ogni controllo o punto decisionale

Tratta ogni riga come un’unità di governance. Quella riga può essere un controllo, un’attività di controllo o un importante punto decisionale. Non mescolare task non correlati nella stessa riga. “Incident management” è troppo ampio se nasconde nello stesso elemento detection, classificazione, decisione di reporting e post-incident review.

Un esempio semplice per un processo legato a DORA appare così:

Example RAM for a DORA Control

Questo è solo un modello. L’assegnazione esatta dipende dalla tua struttura operativa. In alcune organizzazioni, Legal and Compliance può possedere il percorso di approvazione per il reporting. In altre, il ruolo accountable può essere collocato in una specifica funzione di resilience o risk. Ciò che conta è che ogni riga abbia un owner difendibile.

Se una riga non può resistere contemporaneamente a una contestazione da parte di legal, operations e audit, non è finita.

Valida la matrice contro la realtà

Prima di pubblicare qualcosa, testala contro scenari operativi reali.

Usa un incidente recente, una review di un fornitore, un controllo mancato o un ciclo di approvazione di una policy. Esamina la matrice con le persone nominate e chiedi se le assegnazioni riflettono ciò che accade davvero. Cerca tre segnali di fallimento comuni:

1. L’owner accountable non controlla l’approvazione.
2. Il team responsible non può eseguire il task senza l’accesso o gli strumenti di un altro team.
3. Le evidenze vengono prodotte da un ruolo ma si presume siano conservate da un altro.

Questi disallineamenti sono preziosi. Mostrano dove il processo e il modello di ownership si sono separati.

Mantieni la matrice abbastanza ristretta da essere governabile

Una matrice diventa inutilizzabile quando cerca di rappresentare ogni azione a livello di ticket. Dovrebbe coprire punti di controllo significativi, non ogni movimento operativo. Il livello giusto è di solito quello in cui un passaggio mancato creerebbe rischio, richiederebbe un’azione del management o indebolirebbe la capacità di dimostrare il funzionamento del controllo.

Questo equilibrio conta. Troppo ampia, e la titolarità diventa vaga. Troppo granulare, e nessuno la mantiene. Un design pronto per l’audit sta nel mezzo. Registra i punti in cui autorità, esecuzione ed evidenze devono incontrarsi.

Mantenere un sistema di ownership vivo

La maggior parte delle matrici di assegnazione delle responsabilità non fallisce perché il design iniziale era sbagliato. Fallisce perché l’organizzazione cambia e la matrice no.

Una sfida importante è il responsibility drift. Con il cambiamento delle organizzazioni, le matrici diventano obsolete, una causa frequente di evidenze di audit incomplete, come descritto in questa discussione sulla manutenzione e sul cambiamento della responsibility assignment matrix. Ecco perché i team regolamentati hanno bisogno di un modello di ownership vivo, integrato con sistemi di identity, ticketing ed evidenze, invece di una tabella da compilare una sola volta.

Cosa provoca il drift

Di solito l’ownership deriva per normali ragioni operative.

• Cambi organizzativi spostano i diritti decisionali senza aggiornare i documenti di controllo
• Nuovi fornitori prendono in carico parte di un processo, ma il ruolo di supervisione interna resta indefinito
• Cambi di tool modificano chi può accedere a log, approvazioni o export di evidenze
• Turnover del personale lascia nella matrice un nome di ruolo che non mappa più chiaramente a un vero owner

La matrice allora diventa cerimoniale. Esiste ancora, ma non prevede più chi risponderà, approverà o fornirà la prova quando necessario.

Tratta la matrice come un artefatto controllato

Una matrice viva necessita della stessa disciplina che applichi agli altri oggetti di governance. Ciò include version control, approvazione del cambiamento, trigger di review e storico conservato. Non servono processi teatrali, ma serve abbastanza struttura per mostrare come è cambiata l’ownership e chi ha approvato l’aggiornamento.

Trigger di review utili includono:

• Cambi organizzativi rilevanti
• Nuovi sistemi critici o servizi esternalizzati
• Rielaborazione delle policy o redesign dei controlli
• Esiti di audit, incidenti o richieste di evidenze fallite

È anche qui che la più ampia pratica di GRC governance risk compliance diventa operativa piuttosto che teorica. La governance non è la matrice in sé. La governance è l’insieme dei controlli che mantengono la matrice accurata, autorizzata e allineata al modo in cui l’organizzazione lavora davvero.

Una matrice obsoleta è peggiore di nessuna matrice, perché le persone si fidano di essa finché non scoprono che non dovrebbero.

Collega l’ownership ai sistemi operativi

Un foglio di calcolo statico può documentare l’ownership. Non può però applicarla o validarla in modo affidabile.

Il modello più solido collega le assegnazioni di ruolo ai sistemi in cui lavoro ed evidenze già esistono. I sistemi di identity mostrano chi ricopre attualmente un ruolo. I sistemi di ticketing mostrano esecuzione e approvazioni. I repository delle evidenze mostrano se la prova attesa è stata allegata, revisionata e conservata. I change log immutabili aiutano a mostrare quando l’ownership è cambiata e se l’aggiornamento stesso era controllato.

Questo non rimuove l’accountability umana. La rafforza. L’automazione può notificare, instradare e registrare. Non può possedere il controllo.

Misura l’accuratezza in modo qualitativo

Molti team vogliono una metrica precisa per l’accuratezza della matrice. In pratica, l’approccio più utile è una verifica ricorrente tramite test operativi. Scegli un piccolo insieme di controlli importanti e verifica se il ruolo accountable nominato può confermare il design del controllo, identificare le evidenze più recenti e spiegare il percorso di escalation senza dover ricostruire tutto.

Se non può farlo, il problema non è lo stile della documentazione. È l’integrità della governance.

Best practice e errori comuni

La migliore matrice di assegnazione delle responsabilità è di solito più piccola e più rigorosa di quanto ci si aspetti. Non cerca di modellare l’intera organizzazione. Si concentra sui controlli, sulle approvazioni e sui percorsi delle evidenze che contano.

Alcune pratiche funzionano costantemente bene:

• Parti dai controlli critici. Inizia dove un fallimento creerebbe problemi di reporting, resilienza, sicurezza o audit.
• Proteggi la regola di un solo owner accountable. Se un comitato o una funzione condivisa appare nella colonna Accountable, correggi il design.
• Mappa esplicitamente la titolarità delle evidenze. La persona che possiede l’esito del controllo e quella che raccoglie gli artefatti non sono sempre la stessa.
• Rivedi sugli eventi, non solo a scadenza. Cambi organizzativi, cambi di fornitori e redesign dei processi dovrebbero tutti attivare una review.
• Valida con scenari reali. Simula incidenti, eccezioni e richieste di audit prima di considerare la matrice completa.

Gli errori comuni sono altrettanto prevedibili.

Lo standard pratico è semplice. La matrice dovrebbe rispecchiare la realtà abbastanza da evitare che un incidente, un test di controllo o una richiesta di audit costringa l’organizzazione a riscoprire chi possiede cosa.

Una matrice di assegnazione delle responsabilità è utile quando incorpora l’accountability nelle operazioni quotidiane. È questo che la rende più di un insieme di documenti. Diventa parte di come l’organizzazione dimostra il controllo, non solo di come descrive l’intenzione.

Se stai costruendo un modello vivo di ownership per il lavoro su DORA, NIS2 o GDPR, AuditReady è pensato per quel livello operativo. Aiuta i team a mappare le responsabilità, collegare le evidenze ai controlli e alle policy, mantenere registri tracciabili e preparare output pronti per l’audit senza trasformare la governance in un esercizio da foglio di calcolo.