GRC: cos'è governance, risk and compliance e come si fa

GRC (governance, risk and compliance) è il modo di gestire insieme tre attività che spesso vivono separate: chi decide e risponde della sicurezza (governance), come si individuano e trattano i rischi (risk management) e come si dimostra di rispettare norme e standard (compliance). L'idea è che le tre parti usino gli stessi ruoli, lo stesso registro dei rischi e gli stessi controlli, invece di produrre tre documentazioni che non si parlano.

Il termine nasce nel 2002 in OCEG (Open Compliance and Ethics Group), che definisce il GRC come l'insieme integrato delle capacità che permettono a un'organizzazione di raggiungere i propri obiettivi in modo affidabile, gestire l'incertezza e agire con integrità. Qui trovi cosa chiedono NIS2, DORA e ISO/IEC 27001 e come si costruisce un programma GRC nel mid-market.

Cosa significa GRC: le tre parole, una per una

Governance

È la parte delle decisioni e delle responsabilità. Chi approva la politica di sicurezza, chi fissa quanto rischio l'azienda è disposta ad accettare, chi assegna il budget, chi riceve i report e con quale frequenza. Senza governance i rischi vengono valutati, ma nessuno ha l'autorità di accettarli.

Risk management

È il processo con cui si identificano, analizzano, valutano e trattano i rischi, e si decide cosa fare di quelli che restano. Per la sicurezza delle informazioni il rischio si legge sui processi e sui dati che contano per il business, non sulla lista dei server. Il ciclo completo, con minaccia, vulnerabilità, probabilità e impatto, è spiegato nel nostro articolo sul cyber risk.

Compliance

È la capacità di sapere quali obblighi si applicano (leggi, regolamenti, contratti, standard volontari scelti dall'azienda) e di dimostrare con prove che sono rispettati. La parola chiave è dimostrare: una misura che esiste ma non lascia traccia, davanti a un auditor o a un'autorità, vale come una misura assente.

Perché integrarle: il problema dei tre silos

In molte aziende le tre attività esistono già, ma in uffici diversi. L'IT tiene la lista delle vulnerabilità, il risk manager un registro dei rischi d'impresa in cui la sicurezza informatica è una riga, il responsabile qualità o il DPO le procedure per la certificazione e il GDPR. Il risultato si vede in tre sintomi ricorrenti:

• Lo stesso controllo viene documentato più volte. L'autenticazione a più fattori compare nella checklist ISO 27001, nel questionario di un cliente e nelle misure NIS2, ogni volta con prove raccolte da capo.
• I rischi non sono collegati ai controlli. Il registro dice che il ransomware è un rischio alto, ma non dice quali misure lo riducono, chi ne è responsabile e se funzionano.
• Il consiglio di amministrazione riceve tre report diversi. Uno tecnico, uno di conformità, uno di rischio, con scale e linguaggi incompatibili, e nessuno gli dice cosa decidere.

Un approccio GRC non aggiunge un quarto ufficio. Mette in comune tre cose: chi decide, un metodo unico di valutazione del rischio e un catalogo unico di controlli, ciascuno mappato su tutti gli obblighi a cui risponde.

GRC e compliance: cosa chiedono NIS2, DORA e ISO 27001

Le norme recenti sulla sicurezza informatica non usano la sigla GRC, ma ne descrivono la struttura: un organo di vertice che approva e risponde, un processo di gestione del rischio, politiche documentate, verifiche periodiche.

NIS2 in Italia: il D.Lgs. 138/2024 e le misure ACN

L'articolo 23 del D.Lgs. 138/2024 mette la governance in capo agli organi di amministrazione e direttivi dei soggetti essenziali e importanti. Questi organi approvano le modalità di implementazione delle misure di gestione dei rischi per la sicurezza informatica previste dall'articolo 24, sovrintendono all'attuazione degli obblighi e sono responsabili delle violazioni. Sono anche tenuti a seguire una formazione in materia di sicurezza informatica e devono essere informati periodicamente degli incidenti e delle notifiche.

La determinazione ACN 379907/2025 traduce questi principi in misure di base: allegato 1 per i soggetti importanti, allegato 2 per gli essenziali, da adottare entro ottobre 2026 per i soggetti inseriti nell'elenco NIS nel 2025 (18 mesi dalla comunicazione di inserimento) ed entro il 31 luglio 2027 per quelli inseriti nel 2026 (Determinazione ACN 127434/2026). Le misure della funzione Governo sono, di fatto, un programma GRC minimo:

• GV.RR-02: l'organizzazione per la sicurezza informatica, con ruoli e responsabilità, è definita e approvata dagli organi di amministrazione e direttivi, e riesaminata almeno ogni due anni.
• GV.RM-03: un piano di gestione dei rischi per la sicurezza informatica, documentato e aggiornato, dentro i processi di gestione del rischio del soggetto.
• GV.PO-01 e GV.PO-02: politiche di sicurezza su sedici ambiti, fra cui gestione del rischio, ruoli e responsabilità, conformità e audit di sicurezza, approvate dagli organi di amministrazione e riesaminate almeno una volta all'anno, verificandone la conformità alla normativa.
• ID.IM-01: dagli esiti del riesame nasce un piano di adeguamento approvato dagli organi di amministrazione, che ricevono relazioni periodiche sui risultati.

DORA per le entità finanziarie

Il Regolamento (UE) 2022/2554 è ancora più esplicito. L'articolo 5 assegna all'organo di gestione la responsabilità finale per la gestione dei rischi informatici: definisce e approva l'attuazione del quadro di gestione dei rischi informatici, ne vigila l'attuazione, stabilisce ruoli e responsabilità, fissa il livello di tolleranza al rischio, approva i piani di audit interno sulle TIC e assegna le risorse. L'articolo 6, paragrafo 4, chiede alle entità diverse dalle microimprese una separazione e indipendenza tra funzioni di gestione dei rischi informatici, funzioni di controllo e audit interno, secondo il modello delle tre linee di difesa o secondo un modello interno di controllo e gestione del rischio. Il quadro va documentato e riesaminato almeno una volta all'anno, periodicamente per le microimprese (paragrafo 5), e, per le entità diverse dalle microimprese, sottoposto periodicamente ad audit interno (paragrafo 6). Gli obblighi personali del consiglio sono approfonditi in DORA e responsabilità dell'organo di amministrazione.

ISO/IEC 27001: il sistema di gestione come struttura GRC

Per chi non è soggetto a NIS2 o DORA, la ISO/IEC 27001:2022 è spesso il modo più ordinato di costruire un programma GRC sulla sicurezza delle informazioni, perché la norma ne contiene le tre parti:

• Governance: punto 5, Leadership (leadership e impegno, politica, ruoli, responsabilità e autorità) e punto 9.3, Riesame di direzione.
• Rischio: punti 6.1.2 e 6.1.3, valutazione e trattamento del rischio relativo alla sicurezza delle informazioni, ripresi ai punti 8.2 e 8.3 tra le attività operative.
• Compliance: punto 4.2, comprendere le esigenze e le aspettative delle parti interessate, e punto 9.2, Audit interni.

Il vantaggio pratico è la certificazione: un organismo accreditato verifica che il sistema funzioni, e il certificato risponde a una parte delle domande che clienti e autorità fanno. Il percorso completo è nella nostra guida alla certificazione ISO 27001.

NIST CSF 2.0: la funzione Govern

Anche il NIST Cybersecurity Framework è andato nella stessa direzione. Con la versione 2.0, pubblicata il 26 febbraio 2024, NIST ha aggiunto alle cinque funzioni storiche la funzione Govern (GV), che copre contesto organizzativo, strategia di gestione del rischio, rischio della catena di fornitura, ruoli e responsabilità, politiche e supervisione. Le misure ACN parlano la stessa lingua: sono sviluppate sul Framework nazionale per la cybersecurity e la data protection (edizione 2025), che allinea il proprio core a quello del CSF 2.0, ed è da lì che vengono i codici GV.

Come si costruisce un programma GRC nel mid-market

Un'azienda del mid-market non ha bisogno di una direzione GRC. Ha bisogno che sei cose esistano e siano collegate:

1. Un registro degli obblighi. Quali norme si applicano (NIS2, DORA, GDPR), quali standard l'azienda ha scelto (ISO/IEC 27001, SOC 2), quali requisiti arrivano dai contratti con i clienti. Per ognuno, un responsabile.
2. Ruoli e deleghe scritti e approvati. Chi è il responsabile della sicurezza, chi è il punto di contatto NIS2, chi può accettare un rischio residuo e fino a che soglia. L'approvazione del vertice non è una formalità: NIS2 e DORA la chiedono esplicitamente.
3. Un solo metodo di valutazione del rischio. Stessa scala, stessi criteri di accettazione, stesso registro per tutti i framework. Due metodi diversi producono due priorità diverse e nessuna decisione.
4. Un catalogo unico di controlli. Ogni controllo descritto una volta e collegato a tutti i requisiti che soddisfa: un controllo sugli accessi amministrativi risponde insieme all'Annex A della 27001, alle misure ACN e alle domande dei clienti.
5. Evidenze raccolte con continuità. Le prove che un controllo funziona (log, configurazioni, verbali, report) invecchiano in fretta. Raccoglierle in modo continuo invece che prima di ogni audit è il punto in cui la compliance automation fa risparmiare più lavoro.
6. Un riesame periodico con il vertice. Una relazione unica che dica quali rischi sono sopra soglia, quali controlli non funzionano, quali obblighi sono scoperti e cosa serve per chiuderli. È il momento in cui la governance decide, e lascia la traccia che NIS2, DORA e ISO 27001 chiedono.

Piattaforma GRC: cosa fa e cosa no

Quando si parla di GRC si parla spesso di software. Una piattaforma GRC tiene in un unico posto il registro degli obblighi, il registro dei rischi, il catalogo dei controlli con le mappature tra framework, le evidenze, le attività di audit e le scadenze. È utile quando i framework sono più di uno e i fogli di calcolo cominciano a contraddirsi.

Lo strumento però non decide il perimetro, non valuta i rischi al posto dell'azienda, non sceglie quali accettare e non sostituisce l'audit. Se ruoli, metodo di rischio e catalogo dei controlli non sono stati definiti, il software li rende solo più visibili. L'ordine giusto è prima il metodo, poi lo strumento.

Gli errori che vediamo più spesso

• GRC come progetto documentale. Politiche scritte per l'audit e mai lette da chi gestisce i sistemi. Le misure ACN chiedono che le politiche siano approvate, comunicate e riesaminate: un documento fermo da due anni non regge.
• Il rischio cyber fuori dal rischio d'impresa. Sia la misura GV.RM-03 di ACN sia l'articolo 6 di DORA lo vogliono dentro i processi complessivi di gestione del rischio, non in un registro parallelo dell'IT.
• Compliance senza operatività. Una politica di monitoraggio degli eventi di sicurezza va sostenuta da qualcuno che i log li guarda davvero. Le prove migliori nascono dal lavoro quotidiano, non dalla settimana prima dell'audit.
• Un framework per volta. Prima la 27001, poi NIS2, poi le richieste dei clienti, ognuno con il suo progetto e le sue prove.

In sintesi

GRC significa governance, risk and compliance: decisioni e responsabilità del vertice, gestione del rischio e dimostrazione della conformità, tenute insieme dagli stessi ruoli, dallo stesso registro dei rischi e dallo stesso catalogo di controlli. NIS2 (art. 23 del D.Lgs. 138/2024 e misure ACN della funzione Governo), DORA (articoli 5 e 6 del Regolamento UE 2022/2554) e la ISO/IEC 27001 descrivono la stessa struttura con parole diverse. Per un'azienda del mid-market il punto di partenza più concreto è spesso il sistema di gestione della 27001, perché organizza le tre parti in un impianto verificabile da terzi.

Se vuoi capire come impostare governance, rischio e controlli partendo dalla ISO 27001 nel tuo caso, trovi come lavoriamo nella pagina dedicata alla certificazione ISO 27001.