3,136 subscribers

Dalla norma al controllo: costruire la sicurezza dei dati sulla realtà aziendale

Antonio Ieranò

Information & Cybersecurity Strategist | Digital Sovereignty • AI Governance • Complex Systems | Author, Researcher & Occasional Philosopher | Views stubbornly my own. 🧠

September 28, 2026

Quando si parla di sicurezza dei dati e conformità normativa, il rischio è partire dalla tecnologia troppo presto.

Si identifica una piattaforma, si attivano alcune funzionalità, si producono dei finding e solo successivamente si cerca di collegare i risultati ai requisiti normativi e ai processi aziendali.

Il percorso dovrebbe essere opposto.

La domanda iniziale non è:

“Quale prodotto dobbiamo implementare?”

La domanda corretta è:

“Che cosa ci chiede la norma e come possiamo tradurlo in controlli coerenti con il modo in cui la nostra organizzazione opera realmente?”

Per rispondere serve una catena di tracciabilità che colleghi:

norma → processi aziendali → dati → ubicazione → accessi → rischio → evidenze tecnologiche → controlli

Questo approccio permette di evitare due errori frequenti:

costruire controlli generici, scollegati dalla realtà operativa;
aspettarsi che un software possa determinare autonomamente lo stato di conformità dell’organizzazione.

1. Che cosa chiede la norma?

Il primo passaggio consiste nel comprendere il risultato richiesto dalla normativa applicabile.

Non basta estrarre un elenco di articoli. Occorre identificare:

quale obbligo deve essere soddisfatto;
quale rischio la norma intende ridurre;
quali soggetti sono responsabili;
quali decisioni devono essere prese;
quali attività devono essere svolte;
quali risultati devono poter essere dimostrati;
quali evidenze potrebbero essere richieste.

Normative come GDPR, NIS2, DORA e AI Act hanno ambiti, destinatari e finalità differenti. Non devono essere trattate come un unico insieme indistinto.

Condividono però alcune esigenze operative:

conoscere dati, asset e dipendenze;
applicare misure adeguate e proporzionate;
limitare gli accessi;
assegnare responsabilità;
verificare l’efficacia delle misure;
documentare decisioni, attività e risultati.

La norma definisce l’aspettativa. Non descrive necessariamente in dettaglio come implementare ogni singolo controllo nell’ambiente specifico dell’azienda.

2. Come funzionano i processi aziendali?

Il requisito normativo deve essere collegato ai processi che utilizzano, producono o modificano i dati.

Questo passaggio è fondamentale perché i dati non esistono in modo isolato. Servono a supportare attività aziendali concrete:

gestione dei clienti;
amministrazione del personale;
sviluppo di prodotti;
gestione finanziaria;
assistenza;
collaborazione con fornitori;
analisi e reporting;
utilizzo di sistemi di intelligenza artificiale.

Per ogni processo è necessario comprendere:

qual è il suo obiettivo;
chi ne è responsabile;
quali funzioni aziendali sono coinvolte;
quali sistemi lo supportano;
quali terze parti partecipano;
quali decisioni vengono prese;
quali dati vengono creati, consultati, modificati o trasferiti;
quale sarebbe l’impatto di una perdita, alterazione o indisponibilità.

Senza questa analisi, un dato può essere classificato come sensibile, ma non necessariamente compreso nel suo contesto aziendale.

Lo stesso tipo di informazione può avere livelli di criticità differenti a seconda del processo nel quale viene utilizzato.

3. Quali dati possiede e utilizza l’azienda?

Una volta compresi i processi, occorre identificare i dati che li sostengono.

La domanda non è soltanto quali dati personali vengono trattati. L’analisi può includere:

dati personali;
categorie particolari di dati;
dati finanziari;
proprietà intellettuale;
contratti;
informazioni sui clienti;
documentazione tecnica;
dati operativi;
credenziali e segreti;
dati utilizzati da modelli o servizi di intelligenza artificiale;
informazioni soggette a obblighi di conservazione;
dati critici per la continuità del processo.

Per ogni categoria è utile comprendere:

sensibilità;
valore aziendale;
finalità;
proprietario;
origine;
ciclo di vita;
requisiti di conservazione;
eventuali limitazioni d’uso;
conseguenze di un accesso non autorizzato.

Questa classificazione non dovrebbe essere effettuata esclusivamente sulla base di etichette tecniche.

Deve riflettere anche il valore del dato per l’organizzazione e il processo nel quale viene utilizzato.

4. Dove si trovano realmente i dati?

Dopo aver identificato i dati, occorre localizzarli.

Le informazioni possono essere distribuite tra:

applicazioni SaaS;
piattaforme cloud;
database;
file server;
repository collaborativi;
mail server;
endpoint;
ambienti di sviluppo;
sistemi legacy;
archivi;
piattaforme di analisi;
backup;
servizi gestiti da terze parti;
strumenti di intelligenza artificiale.
…

La posizione ufficialmente prevista non coincide sempre con quella reale.

Un documento può essere presente nel sistema aziendale principale, ma anche:

in uno spazio condiviso;
nella casella email di un utente;
in un backup;
in un ambiente di test;
in una cartella personale;
in un repository non più utilizzato;
in una piattaforma esterna;
in un sistema di retrieval per l’intelligenza artificiale.

Per questo un inventario statico può diventare rapidamente incompleto.

La discovery tecnica deve aiutare a verificare la distanza tra l’architettura prevista e la distribuzione effettiva dei dati.

5. Chi può accedere ai dati?

Sapere dove si trova un dato non è sufficiente.

Occorre comprendere chi può raggiungerlo realmente e attraverso quale percorso.

L’analisi deve considerare:

utenti individuali;
gruppi;
ruoli;
amministratori;
account inattivi;
account di servizio;
applicazioni;
integrazioni;
fornitori;
collaboratori esterni;
servizi di intelligenza artificiale;
autorizzazioni ereditate;
collegamenti pubblici o condivisi;
percorsi indiretti di accesso.

Le autorizzazioni formalmente assegnate rappresentano soltanto una parte della situazione.

Un utente può ottenere accesso attraverso l’appartenenza a più gruppi. Un account di servizio può mantenere privilegi non più necessari. Un repository può ereditare impostazioni da una struttura superiore. Un servizio AI può avere accesso a contenuti inizialmente destinati a un gruppo ristretto.

La domanda da porre non è soltanto:

“Quali permessi risultano configurati?”

È:

“Chi può effettivamente raggiungere questo dato, direttamente o indirettamente?”

6. In che modo i dati sono esposti al rischio?

Il rischio non dipende da un solo fattore.

Un dato molto sensibile, correttamente segregato e accessibile a un gruppo limitato, può presentare una situazione diversa rispetto a un dato meno sensibile ma pubblicamente condiviso, duplicato e privo di owner.

La valutazione dovrebbe combinare:

sensibilità;
valore aziendale;
criticità del processo;
posizione;
configurazione;
numero e tipologia degli accessi;
privilegi eccessivi;
account inattivi;
condivisioni esterne;
copie duplicate;
assenza di un proprietario;
utilizzo da parte di applicazioni o servizi AI;
esposizione a terze parti;
possibilità di movimento o esfiltrazione;
impatto potenziale;
misure già presenti.

Il risultato non dovrebbe essere una lista piatta di finding.

Dovrebbe essere una vista contestualizzata che aiuti a rispondere a tre domande:

Quale condizione richiede attenzione?
Perché è rilevante per l’organizzazione?
Quale intervento deve avere priorità?

7. Quali evidenze possono produrre i software?

Dopo aver compreso norma, processi, dati, accessi e rischio, è possibile valutare ciò che uno o più software possono effettivamente osservare e dimostrare.

Una soluzione integrata di data management, data access management e security posture management può fornire evidenze come:

inventario tecnico dei repository;
localizzazione dei dati;
classificazione della sensibilità;
identificazione di copie e duplicati;
relazione tra dati e proprietari;
utenti e servizi con accesso;
accessi eccessivi;
account inattivi;
condivisioni esterne;
configurazioni rischiose;
percorsi di esposizione;
finding prioritizzati;
azioni assegnate;
stato della remediation;
eccezioni registrate;
trend nel tempo;
rischio residuo.

Altri strumenti possono fornire evidenze complementari:

sistemi IAM per identità e autorizzazioni;
DLP per utilizzo e trasferimento dei dati;
strumenti di cloud security per configurazioni e posture cloud;
SIEM per eventi e correlazioni;
ticketing per attività e responsabilità;
asset management per sistemi e dipendenze;
strumenti di business process management per workflow e owner;
piattaforme GRC per requisiti, rischi e controlli.

L’obiettivo non è chiedere a un singolo prodotto di risolvere ogni aspetto.

È comprendere quali evidenze ciascun sistema può produrre e come queste evidenze possono essere collegate.

8. Le evidenze sono coerenti con la norma e con il processo aziendale?

Un’evidenza tecnica è utile soltanto se risponde a una domanda di controllo.

Per esempio, sapere che un repository contiene dati personali è un’informazione importante, ma non è ancora sufficiente.

Occorre comprendere:

a quale processo appartiene;
chi ne è responsabile;
perché quei dati vengono conservati;
chi dovrebbe potervi accedere;
chi vi accede effettivamente;
quali accessi rappresentano un’eccezione;
quale rischio è associato alla condizione;
quale requisito normativo o aziendale viene supportato;
quale azione deve essere intrapresa.

Il software produce fatti tecnici.

Il lavoro consulenziale e organizzativo collega questi fatti a:

requisiti;
processi;
rischi;
responsabilità;
decisioni;
controlli.

Questo collegamento determina la reale utilizzabilità dell’evidenza.

9. Creare controlli basati sulla situazione reale dell’azienda

Soltanto a questo punto è possibile progettare controlli coerenti con la norma e con l’ambiente effettivo dell’organizzazione.

Ogni controllo dovrebbe definire almeno:

Obiettivo

Quale rischio o requisito deve affrontare?

Perimetro

Quali processi, dati, repository e sistemi include?

Owner

Chi è responsabile del controllo?

Regola

Quale condizione è considerata corretta o accettabile?

Soglia

Quando una condizione richiede un intervento?

Frequenza

Il controllo è continuo, periodico o attivato da un evento?

Evidenza

Quali dati, report o registrazioni dimostrano il funzionamento?

Remediation

Chi interviene, entro quali tempi e attraverso quale processo?

Eccezione

Chi può approvarla, per quanto tempo e con quali misure compensative?

Riesame

Come viene verificata l’efficacia del controllo nel tempo?

Il controllo non viene quindi copiato da un catalogo e applicato in modo uniforme.

Viene costruito considerando:

ciò che la norma richiede;
il modo in cui l’azienda opera;
i dati realmente utilizzati;
la loro posizione effettiva;
gli accessi reali;
le condizioni di rischio;
le evidenze disponibili;
le responsabilità organizzative.

Un esempio concreto

Immaginiamo che un requisito richieda di proteggere i dati personali attraverso misure adeguate e un controllo coerente degli accessi.

Il processo aziendale riguarda l’amministrazione del personale.

L’analisi identifica:

documenti relativi ai dipendenti;
dati retributivi;
coordinate bancarie;
certificazioni;
dati sanitari eventualmente presenti nei processi autorizzati.

La discovery mostra che questi dati sono distribuiti tra:

applicazione HR;
spazio collaborativo;
cartelle condivise;
email;
archivio cloud;
copie utilizzate per il reporting.

L’analisi degli accessi rileva:

gruppi troppo ampi;
account di ex dipendenti;
accessi di servizio;
condivisioni temporanee non rimosse;
repository privi di un owner aggiornato.

Il software può produrre:

inventario dei repository;
classificazione dei contenuti;
elenco degli accessi;
finding relativi agli account inattivi;
stato della remediation;
storico delle modifiche.

Sulla base di queste informazioni viene progettato un controllo:

Verificare con continuità che i repository contenenti dati del personale abbiano un owner, siano accessibili soltanto ai ruoli autorizzati e non includano account inattivi o condivisioni esterne non approvate.

Il controllo può prevedere:

owner: responsabile HR Data;
supporto tecnico: Identity e Security Team;
frequenza: monitoraggio continuo e riesame trimestrale;
soglia: presenza di account inattivi o gruppi non autorizzati;
remediation: rimozione o validazione entro un tempo definito;
eccezione: approvazione documentata e con scadenza;
evidenza: report degli accessi, ticket di remediation e registro delle eccezioni.

Il requisito normativo è stato così tradotto in un controllo costruito sulla reale situazione aziendale.