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

If an auditor asked today, “Who owns this control, who approves it, and who can produce the evidence?”, would your team answer consistently?

La maggior parte delle organizzazioni pensa di avere già una risposta chiara perché dispone di un piano di progetto, di un foglio di calcolo o di un grafico RACI sepolto in un drive condiviso. Questo di solito funziona finché non è necessario dimostrare la proprietà sotto pressione. Negli ambienti regolamentati, quella pressione arriva durante la gestione degli incidenti, le revisioni di terze parti, i test dei controlli e le richieste formali di audit.

Una responsibility assignment matrix viene spesso trattata come una comodità di project management. È troppo riduttivo. In pratica, può essere il meccanismo che collega politica, esecuzione dei controlli, approvazione, escalation e prove in una struttura visibile. Senza quella struttura, le persone improvvisano. L'improvvisazione è dove le approvazioni spariscono, i passaggi di controllo falliscono 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 responsabilità non sono la stessa cosa. Un security engineer può eseguire una revisione. Un operations manager può coordinare la modifica. Un responsabile compliance può raccogliere le evidenze. Niente di tutto ciò ti dice chi è responsabile del risultato del controllo.

Questa distinzione conta di più ora perché le aspettative di governance IT sono andate ben oltre “qualcuno è stato coinvolto”. Richiedono una catena di proprietà difendibile. Una responsibility assignment matrix ben costruita non descrive solo i compiti. Mostra chi decide, chi esegue, chi deve essere consultato, chi deve essere informato e chi firma quando il controllo deve resistere al controllo.

Oltre il piano di progetto

La maggior parte degli articoli sul RAM si ferma al coordinamento del team. Spiegano le lettere, mostrano un esempio generico di avvio e presumono che il lavoro sia fatto. Va bene per lavori di consegna semplici. Non è sufficiente quando la stessa organizzazione deve gestire controlli di sicurezza, servizi ICT esternalizzati, segnalazione degli incidenti, approvazioni di policy e prove d'audit.

Una responsibility assignment matrix è uno degli strumenti di project-governance più antichi nella pratica IT moderna, e il modello RACI è diventato ampiamente standardizzato attraverso l'uso nel project management mainstream, incluso il riconoscimento nelle tradizioni PMBOK, come descritto nella panoramica della responsibility assignment matrix dell'Institute of Project Management. La sua longevità deriva da un design semplice. Attività o deliverable si trovano su un asse, i ruoli sull'altro, e a ogni ruolo viene assegnata una delle categorie Responsible, Accountable, Consulted o Informed.

Quel background storico conta perché il modello sopravvive per una ragione. Risolve un problema operativo persistente: troppe persone che toccano lo stesso deliverable senza un unico proprietario per il risultato. Nell'IT, quel problema appare ovunque. La sicurezza scrive uno standard, le operations implementano un controllo, il legale rivede una comunicazione, un fornitore fornisce log e la compliance rimane a spiegare chi era il proprietario del risultato.

Dove l'uso convenzionale del RACI fallisce

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

• Controlli e sotto-controlli come revisioni degli accessi, verifica dei backup, classificazione degli incidenti o due diligence sui fornitori
• Obblighi di evidenza come screenshot, approvazioni di policy, esportazioni di log, registri di revisione e firme per le eccezioni
• Dipendenze da terzi dove parte del controllo è del fornitore ma la responsabilità resta interna
• Percorsi di escalation per approvazioni mancate, esecuzione del controllo fallita o evidenze assenti

Una matrice diventa utile quando risponde alla domanda dell'auditor prima che l'auditor la faccia.

Questo cambia il ruolo del documento. Cessa di essere un artefatto di pianificazione e diventa parte del sistema di governance. Se la tua matrice non è in grado di identificare il proprietario di un controllo fallito e la persona che approva la sua remediation, non sta servendo l'organizzazione dove risiede il rischio.

La vera prova

Un test pratico è semplice. Scegli 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 influisce sul rischio, sui clienti o sul reporting?

Se le tue risposte dipendono dalla memoria, dalle relazioni o da chi è online in quel momento, la matrice manca o è inefficace. Un RAM maturo riduce l'ambiguità prima che sorga un problema. Ecco perché appartiene alla governance, non solo all'amministrazione di progetto.

Comprendere il framework centrale

Una responsibility assignment matrix funziona perché forza i team a separare l'azione dalla responsabilità. Queste non sono intercambiabili. Qualcuno può fare il lavoro e comunque non possedere il risultato finale.

Il modello è antico, ma si adatta ancora all'IT moderno perché il problema sottostante non è cambiato. Il lavoro cross-funzionale crea confusione a meno che l'autorità non sia esplicita. Per questo il framework rimane durevole.

Cosa significano realmente i ruoli

Responsible indica la persona o il team che svolge il lavoro. In contesti operativi, può essere una funzione di engineering, il service desk, un analyst di sicurezza o il responsabile vendor management. Possono esserci più parti Responsible se il compito lo richiede.

Accountable indica una persona sola che possiede il risultato. Quella persona risponde per il completamento, la qualità, la tempestività e la firma. Questo è il ruolo che conta di più quando un controllo fallisce o l'evidenza viene contestata.

Consulted indica una relazione bidirezionale. Queste persone forniscono input prima che una decisione o un'azione sia definitiva. Nell'IT regolamentato, include spesso consulenza legale, privacy, architettura di sicurezza, risk o procurement.

Informed indica comunicazione unidirezionale. Questi stakeholder hanno bisogno di visibilità, ma non partecipano alla decisione vera e propria.

La regola più importante è semplice: un solo proprietario Accountable per attività o controllo. La spiegazione del RAM e RACI dell'Institute of Project Management evidenzia perché questo è importante negli ambienti tecnologici. Un proprietario Accountable unico riduce l'ambiguità decisionale nelle consegne multi-team, nella risposta agli incidenti e nella proprietà delle evidenze.

Perché un solo proprietario Accountable è il fulcro

I team spesso resistono a questa regola perché la realtà sembra più confusa del modello. Diranno che un comitato possiede il processo, o che security e operations sono responsabili congiuntamente. In pratica, la responsabilità congiunta di solito significa decisioni ritardate e firma poco chiara.

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

Quando l'evidenza è in ritardo, quando un'eccezione deve essere accettata o quando un regolatore chiede chi ha approvato un processo, un proprietario nominato è l'unica risposta che regge. Puoi comunque avere molti contributori. Puoi avere ampia consultazione. Ma solo una persona dovrebbe portare il marcatore di responsabilità finale nella matrice.

Regola pratica: Se due persone sono segnate come Accountable, in realtà nessuna delle due lo è davvero.

RACI e varianti operative

RACI è la struttura più familiare, ma non è l'unica utile. Alcuni team usano RASCI, che aggiunge Support. Questo può aiutare quando i team operativi devono distinguere tra la persona che fa il lavoro e un altro ruolo che fornisce tool, accessi o coordinamento.

Ad esempio, un identity engineer può essere Responsible per l'esecuzione trimestrale della revisione degli accessi, mentre un team platform supporta la generazione dei report. Quel ruolo di supporto può essere importante operativamente, specialmente quando il processo dipende dall'accesso o dall'automazione di un altro team.

Tuttavia, la variante conta meno della logica. Una responsibility assignment matrix funziona quando risponde chiaramente a quattro domande pratiche:

Una buona matrice è rigorosa dove serve e semplice ovunque altro. Se il framework diventa troppo ingegnoso, le persone smettono di usarlo. Se è troppo vago, non sopravviverà a un audit o alla pressione di un incidente.

Il RAM negli ambienti regolamentati

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

È qui che la responsibility assignment matrix cambia carattere. Cessa di essere un artefatto di progetto e diventa una mappa dei controlli. Negli ambienti IT regolamentati, un RAM diventa una mappa di proprietà dei controlli e delle evidenze. DORA si applica dal 17 January 2025 ed estende la responsabilità per il rischio ICT e la supervisione di terze parti, mentre NIS2 aumenta la responsabilità manageriale per la governance della sicurezza, come indicato in questo background sulla responsibility assignment matrix e sull'uso nella governance.

Lo spostamento è sottile ma importante. Le vecchie abitudini di compliance si concentravano sull'esistenza delle policy. La realtà normativa moderna interessa se l'organizzazione può mostrare chi possiede l'esecuzione, chi ha approvato il risultato e chi può produrre le prove senza dover ricostruire il processo retroattivamente.

Cosa seguono realmente regolatori e auditor

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

Chiedono quale obiettivo il controllo mira a raggiungere, chi lo possiede, come opera, dove risiede l'evidenza e come vengono gestite le eccezioni. Se il controllo si basa su un fornitore, chiedono anche chi gestisce quella dipendenza e chi rivede il contributo del fornitore.

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

La catena del controllo conta più della lista delle attività

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

• Gestione degli incidenti in cui un team rileva, un altro fa il triage, il legale valuta le implicazioni di reporting e il management approva la comunicazione esterna
• Supervisione di terze parti in cui procurement detiene il percorso contrattuale, security revisiona i controlli, operations dipende dal servizio e risk o compliance necessitano prove di supervisione
• Governance degli accessi in cui i proprietari della piattaforma eseguono le azioni di revisione, i manager convalidano le entitlements e la compliance ha bisogno di prova di completamento e approvazione

Per questo motivo le discipline di governance adiacenti si intersecano. I team che già gestiscono obblighi di reporting transfrontalieri spesso riconoscono lo stesso schema in altri domini. Le questioni pratiche di governance dietro alla compliance ESG per le multinazionali sono diverse per materia, ma simili nella struttura: la proprietà nominata, le approvazioni documentate e le evidenze tracciabili contano più delle affermazioni generiche di intento.

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

Perché la responsabilità del management cambia il design

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

Questo solitamente significa mappare per funzione e diritti decisionali, non in base a chi ha scritto la procedura. Ad esempio, “Security Operations Lead” è spesso più stabile di un nome personale nella matrice di base, ma l'organizzazione ha comunque bisogno di un'assegnazione corrente dietro quel ruolo.

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

Un RAM solido chiarisce anche dove finiscono le dipendenze esterne e dove resta la responsabilità interna. Un fornitore può generare log, ospitare sistemi o contribuire report. Il fornitore non assorbe la tua responsabilità. Qualcuno dentro l'organizzazione deve ancora possedere la supervisione, rivedere le evidenze e firmare il risultato del controllo.

Come costruire una matrice pronta per l'audit

Una responsibility assignment matrix pronta per l'audit inizia con lo scope, non con le lettere. Se cominci riempiendo celle in un foglio di calcolo, produrrai un grafico ordinato che non corrisponde all'ambiente dei controlli.

Inizia con gli asset, i processi e gli 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 provano che i controlli hanno funzionato. Solo allora dovresti mappare la proprietà.

Parti dai controlli e dalle evidenze

Un buon primo passaggio di solito include:

• Controlli operativi core come gestione degli incidenti, revisioni degli accessi, verifica dei backup, approvazione delle modifiche, supervisione dei log e revisione di terze parti
• Processi di governance come approvazione di policy, gestione delle eccezioni, revisione dei controlli e tracciamento delle remediation
• Attività che producono evidenze come revisioni di management, esportazioni di report, approvazioni via ticket, attestazioni dei fornitori e registri di firma

Molti team traggono beneficio dal rivedere come già raccolgono e strutturano le audit evidence in practice. La matrice e il modello delle evidenze dovrebbero rafforzarsi a vicenda. Se evolvono separatamente, la proprietà del controllo e la proprietà della prova divergeranno.

Definisci i ruoli per autorità, non per job title

I titoli di lavoro sono spesso troppo locali e instabili. Un'azienda ha un Head of Infrastructure. Un'altra ha un Platform Director. Una terza divide quel lavoro tra Site Reliability ed 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 solitamente funzionali. Esempi includono:

• CISO per la proprietà 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 revisione e il coordinamento regolamentare
• CEO or Board per la visibilità esecutiva, l'approvazione formale o l'escalation strategica

Se a un ruolo manca l'autorità per approvare il risultato, probabilmente non dovrebbe detenere lo status Accountable. Una matrice che ignora i diritti decisionali sembra completa ma fallisce la prima volta che si presenta una vera eccezione.

Usa una riga per controllo o punto decisionale

Tratta ogni riga come un'unità di governance. Quella riga può essere un controllo, un'attività di controllo o un punto decisionale importante. Non mescolare compiti non correlati in un'unica riga. “Incident management” è troppo ampio se nasconde rilevamento, classificazione, decisione di reporting e revisione post-incidente nella stessa riga.

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

Example RAM for a DORA Control

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

Se una riga non sopporta una sfida legale, operativa e di audit allo stesso tempo, non è completa.

Valida la matrice rispetto alla realtà

Prima di pubblicare qualsiasi cosa, testala contro scenari operativi reali.

Usa un incidente recente, una revisione di un fornitore, un controllo mancato o un ciclo di approvazione di una policy. Attraversa la matrice con le persone nominate e chiedi se le assegnazioni riflettono ciò che accade realmente. Stai cercando tre segnali di fallimento comuni:

1. Il proprietario accountable non controlla l'approvazione.
2. Il team responsible non può eseguire il compito senza l'accesso o gli strumenti di un altro team.
3. L'evidenza è prodotta da un ruolo ma si dà per scontato che sia trattenuta da un altro.

Quei disallineamenti sono preziosi. Mostrano dove il processo e il modello di proprietà sono diveriti.

Mantieni la matrice abbastanza ristretta da governare

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 è solitamente quello in cui un passo mancato creerebbe rischio, richiederebbe azione di management o indebolirebbe la tua capacità di dimostrare il funzionamento del controllo.

Quel bilanciamento è importante. Troppo ampia e la proprietà è vaga. Troppo granulare e nessuno la mantiene. Il design pronto per l'audit sta nel mezzo. Cattura i punti in cui autorità, esecuzione e evidenze devono incontrarsi.

Mantenere un sistema vivo di proprietà

La maggior parte delle responsibility assignment matrix non fallisce perché il design iniziale era sbagliato. Fallisce perché l'organizzazione cambia e la matrice no.

Una sfida principale è la responsibility drift. Man mano che le organizzazioni cambiano, le matrici diventano obsolete, che è una causa comune di evidenze d'audit incomplete, come descritto in questa discussione sulla manutenzione e il cambiamento della responsibility assignment matrix. Ecco perché i team regolamentati hanno bisogno di un modello di proprietà vivo integrato con identità, ticketing e sistemi di evidenza piuttosto che di un grafico fatto una sola volta.

Cosa causa il drift

La proprietà di solito deriva per ragioni operative ordinarie.

• Cambiamenti 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 interno resta indefinito
• Cambiamenti di tool alterano chi può accedere a log, approvazioni o esportazioni di evidenze
• Turnover del personale lascia un nome di ruolo nella matrice che non corrisponde più a un proprietario reale

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

Tratta la matrice come un artefatto controllato

Una matrice viva ha bisogno della stessa disciplina che applichi ad altri oggetti di governance. Questo include controllo delle versioni, approvazione delle modifiche, trigger di revisione e storia conservata. Non hai bisogno di una burocrazia teatrale, ma hai bisogno di abbastanza struttura per mostrare come la proprietà è cambiata e chi ha approvato l'aggiornamento.

Trigger di revisione utili includono:

• Cambiamenti organizzativi materiali
• Nuovi sistemi critici o servizi esternalizzati
• Riformulazioni di policy o redesign dei controlli
• Rilevazioni da audit, incidenti o richieste di evidenze fallite

Qui è anche dove la più ampia pratica GRC diventa operativa piuttosto che teorica. La governance non è la matrice stessa. La governance è l'insieme di controlli che mantengono la matrice accurata, autorizzata e allineata al modo in cui l'organizzazione lavora realmente.

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

Collega la proprietà ai sistemi operativi

Un foglio di calcolo statico può documentare la proprietà. Non può applicarla o convalidarla in modo affidabile.

Il modello più solido collega le assegnazioni di ruolo ai sistemi in cui il lavoro e le evidenze esistono già. I sistemi di identità mostrano chi detiene attualmente un ruolo. I sistemi di ticketing mostrano l'esecuzione e le approvazioni. I repository di evidenze mostrano se la prova prevista è stata allegata, rivista e conservata. I log di cambiamento immutabili aiutano a mostrare quando la proprietà è cambiata e se l'aggiornamento stesso è stato controllato.

Questo non rimuove la responsabilità umana. La rafforza. L'automazione può notificare, instradare e registrare. Non può possedere il controllo.

Misura l'accuratezza qualitativamente

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

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

Best Practices e errori comuni

La migliore responsibility assignment matrix è solitamente più piccola e più rigorosa di quanto le persone immaginino. Non cerca di modellare l'intera organizzazione. Si concentra sui controlli, le approvazioni e i percorsi di evidenza che contano.

Qualche pratica che funziona costantemente bene:

• Inizia con i controlli critici. Parti dove il fallimento creerebbe problemi di reporting, resilienza, sicurezza o audit.
• Proteggi la regola del proprietario Accountable unico. Se un comitato o una funzione condivisa appare nella colonna Accountable, correggi il design.
• Mappa esplicitamente la proprietà delle evidenze. La persona che possiede il risultato del controllo e la persona che raccoglie gli artefatti non sono sempre la stessa.
• Revisiona su eventi, non solo su calendario. Cambi organizzativi, cambi di fornitore e redesign di processi dovrebbero tutti innescare una revisione.
• Valida con scenari reali. Attraversa incidenti, eccezioni e richieste d'audit prima di considerare la matrice completa.

Gli errori comuni sono altrettanto prevedibili.

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

Una responsibility assignment matrix è utile quando incorpora la responsabilità nelle operazioni quotidiane. Questo la rende più della sola carta. Diventa parte del modo in cui l'organizzazione dimostra il controllo, non solo come lo descrive.

Se stai costruendo un modello di proprietà vivo per DORA, NIS2 o GDPR, AuditReady è progettato per quello strato operativo. Aiuta i team a mappare responsabilità, allegare evidenze a controlli e policy, mantenere registri tracciabili e preparare output pronti per l'audit senza trasformare la governance in un esercizio su fogli di calcolo.