L’IT Security Audit di un partner tecnologico è un processo strutturato di verifica indipendente della postura di sicurezza di un fornitore IT: un esame sistematico dei controlli tecnici, organizzativi e procedurali implementati dal vendor per proteggere i sistemi, i dati e i servizi che gestisce per conto dell’organizzazione cliente.

Non è un questionario di self-assessment, non è una revisione documentale delle certificazioni, non è una conversazione con il responsabile IT del fornitore: è o dovrebbe essere una verifica oggettiva e misurabile, condotta secondo metodologie riconosciute, che produce evidenze concrete sullo stato reale della sicurezza del partner.

La distinzione tra ciò che un vendor dichiara e ciò che effettivamente implementa è il cuore della questione.

Cos’è un IT Security Audit dei sistemi partner e perché è obbligatorio

Le certificazioni ISO 27001, i report SOC 2, i questionari SIG compilati con cura sono strumenti utili e necessari nella fase di onboarding, ma non sostituiscono la verifica diretta.

Un audit ben condotto può rivelare gap significativi in sistemi certificati: controlli documentati ma non operativi, policy esistenti ma non applicate, vulnerabilità tecniche presenti nonostante le dichiarazioni di conformità. Questi gap non emergono dall’analisi dei documenti; emergono dall’osservazione diretta dei sistemi.

Sul piano normativo, la necessità dell’audit è esplicita e non aggirabile. La Direttiva NIS2, all’articolo 21, identifica la sicurezza della catena di approvvigionamento come misura obbligatoria e le linee guida ENISA sul rischio supply chain qualificano l’audit periodico dei vendor critici come pratica fondamentale.

DORA prevede il diritto di accesso, ispezione e audit sui provider ICT critici come elemento contrattuale obbligatorio.

Il GDPR, all’articolo 28, comma 3, lettera h), impone che il contratto con il responsabile del trattamento preveda la possibilità per il titolare di condurre audit e ispezioni.

Non si tratta di raccomandazioni: sono obblighi giuridici con conseguenze sanzionatorie in caso di inadempimento.

Pianificazione dell’audit: scope, metodologia e team

Per completare correttamente un IT Security Audit di un partner tecnologico è dunque necessario partire da una sua corretta pianificazione, seguendo alcuni importanti passaggi operativi.

Definire il perimetro: cosa si audita e cosa no

La definizione del perimetro è il passo più critico nella pianificazione di un IT Security Audit. Un perimetro troppo ampio rende l’audit superficiale e dispersivo; uno troppo ristretto rischia di lasciare fuori proprio le aree più esposte.

Il punto di partenza è la classificazione del vendor: i sistemi, i processi e i dati oggetto dell’audit devono corrispondere a ciò che il vendor gestisce per conto dell’organizzazione cliente, non all’intera infrastruttura del fornitore, che potrebbe includere ambienti non pertinenti e che il vendor ha tutto il diritto di non esporre.

Per un CSP che ospita workload critici, il perimetro dell’audit includerà tipicamente: la gestione delle identità e degli accessi al tenant del cliente, la configurazione della rete e la segmentazione, i meccanismi di backup e ripristino, il sistema di logging e alerting, e le procedure di gestione degli incidenti.

Per un provider di software gestito (MSP/MSSP), il perimetro si estenderà agli strumenti di accesso remoto, ai processi di patch management, alla gestione delle credenziali privilegiate e alle procedure di escalation.

Per un fornitore di software on-premise, il focus sarà sul processo di sviluppo sicuro (SDLC), sulla gestione delle vulnerabilità nel codice e sulle procedure di rilascio degli aggiornamenti.

Scegliere la metodologia: audit interno, esterno o ibrido

La scelta tra audit interno ed esterno non è solo una questione di budget: riguarda l’obiettivo dell’audit, il livello di indipendenza richiesto e le competenze disponibili.

L’audit interno, condotto dal team di sicurezza dell’organizzazione cliente, è più rapido, meno costoso e produce risultati immediatamente integrabili nei processi interni. È adatto per audit periodici di routine su vendor a medio rischio, per verifiche di follow-up dopo un audit esterno, e per organizzazioni con team di sicurezza maturi e risorse specializzate disponibili.

L’audit esterno, affidato a una società di revisione o a un auditor qualificato indipendente, offre un livello di obiettività e di autorevolezza che l’audit interno non può garantire. È la modalità raccomandata per i vendor critici, per gli audit richiesti da normative specifiche (DORA prevede esplicitamente il ricorso a revisori qualificati per le entità finanziarie) e ogni volta che i risultati dell’audit potrebbero essere contestati o utilizzati in un contesto legale o regolatorio. Il costo maggiore è giustificato dalla profondità tecnica dell’analisi e dalla credibilità dei risultati nei confronti del management, del CdA e delle autorità di supervisione.

La modalità ibrida, sempre più diffusa nelle organizzazioni mature, combina i vantaggi di entrambi gli approcci: il team interno conduce la raccolta documentale e le interviste preliminari, mentre un auditor esterno esegue le verifiche tecniche più specializzate (penetration test, analisi del codice, test di configurazione) e certifica i risultati finali. Questa modalità ottimizza il rapporto costo-efficacia e consente di sviluppare progressivamente le competenze del team interno.

La checklist operativa per l’IT Security Audit

La checklist che segue è organizzata per domini di sicurezza, in coerenza con i principali framework internazionali (ISO 27001, CIS Controls v8, NIST CSF 2.0) e con i requisiti delle linee guida ENISA per i settori critici NIS2.

Per ogni dominio sono indicati i controlli da verificare durante l’audit, con un linguaggio volutamente operativo: ciascuna voce rappresenta un’evidenza concreta che l’auditor deve raccogliere, non un’affermazione generica da accettare sulla parola del vendor.

Il livello di copertura richiesto va calibrato sulla classificazione del vendor: per i vendor critici si raccomanda la verifica di tutti i controlli; per i vendor ad alto rischio, almeno i controlli contrassegnati come prioritari in ciascun dominio.

Identità e gestione degli accessi (IAM)

La gestione delle identità è il controllo di sicurezza più frequentemente carente negli audit dei partner IT.

Credenziali condivise, account di servizio con privilegi eccessivi, MFA non implementata sugli accessi amministrativi, provisioning e deprovisioning non governati da processi formali: questi sono i gap più comuni, e i più pericolosi. Il dominio IAM deve essere il primo da verificare in qualsiasi audit di un partner che abbia accesso ai sistemi o ai dati dell’organizzazione cliente.

Ecco una checklist non esaustiva dei controlli necessari in questo dominio:

• Verificare che tutti gli account amministrativi siano protetti da autenticazione a più fattori (MFA) obbligatoria.
• Verificare l’assenza di account condivisi tra più utenti (ogni accesso deve essere nominativo e tracciabile).
• Verificare l’esistenza di un processo formale di provisioning e deprovisioning degli accessi, con approvazione documentata.
• Verificare che il principio del minimo privilegio sia applicato: gli utenti devono avere solo i permessi strettamente necessari al proprio ruolo.
• Verificare la presenza e l’aggiornamento di una policy per la gestione delle password (lunghezza minima, complessità, rotazione, no riutilizzo).
• Verificare che gli account degli ex-dipendenti e degli ex-collaboratori siano disabilitati entro 24 ore dalla cessazione del rapporto.
• Verificare la gestione degli account privilegiati (PAM): accessi mediati da vault, sessioni registrate, revisione periodica dei permessi.

Sicurezza della rete e segmentazione

La segmentazione della rete è il controllo che limita il raggio di azione di un attaccante che abbia già ottenuto un accesso iniziale.

Un partner che gestisce ambienti non segmentati in cui un sistema compromesso può raggiungere lateralmente qualsiasi altro asset è un partner che amplifica il rischio per l’intera supply chain.

La verifica della segmentazione e dei controlli perimetrali è tanto più critica quanto più il vendor ha accesso diretto ai sistemi dell’organizzazione cliente.

Ecco una checklist non esaustiva dei controlli necessari in questo dominio:

• Verificare l’esistenza di segmentazione di rete tra ambienti di produzione, sviluppo e test, e tra i diversi clienti (multi-tenancy).
• Verificare la configurazione dei firewall: regole documentate, revisione periodica, principio del deny-by-default.
• Verificare la protezione degli accessi remoti: VPN con MFA, o soluzioni Zero Trust Network Access (ZTNA) per i vendor con accesso ai sistemi cliente.
• Verificare l’assenza di servizi di rete non necessari esposti su internet (porte aperte, servizi legacy, interfacce di amministrazione pubblicamente accessibili).
• Verificare la presenza di IDS/IPS o soluzioni equivalenti per il rilevamento delle intrusioni sul perimetro di rete.
• Verificare i log di rete: sono abilitati, centralizzati, conservati per un periodo adeguato (minimo 12 mesi per NIS2) e monitorati attivamente?

Gestione delle vulnerabilità e patch management

Il gap tra la scoperta di una vulnerabilità e la sua remediation è la finestra temporale in cui gli attaccanti operano.

Un partner con processi di vulnerability management maturi chiude questa finestra rapidamente e in modo documentato. Un partner che non ha un processo strutturato e che applica le patch quando riesce, senza prioritizzazione e senza tracciatura, è un partner che manterrà vulnerabilità critiche aperte per settimane o mesi.

Questo dominio deve essere verificato con evidenze concrete: non dichiarazioni, ma log di scansione, ticket di patch management, report di remediation.

Ecco una checklist non esaustiva dei controlli necessari in questo dominio:

• Verificare l’esistenza di un processo formalizzato di vulnerability management con scansioni periodiche (almeno mensili per i sistemi critici).
• Verificare la copertura delle scansioni: tutti i sistemi nel perimetro del servizio sono inclusi? Sono esclusi asset rilevanti?
• Verificare la prioritizzazione delle vulnerabilità per severity (CVSS) con SLA di remediation documentati e rispettati.
• Verificare i tempi effettivi di patching su un campione di vulnerabilità critiche degli ultimi 6 mesi: i risultati corrispondono agli SLA contrattualizzati?
• Verificare la gestione delle eccezioni: le vulnerabilità non patchabili (sistemi legacy, sistemi in produzione non interrompibili) sono documentate con risk acceptance formale e misure compensative?
• Verificare l’esistenza di un programma di penetration test periodico (almeno annuale) con report disponibile per revisione.

Protezione dei dati e crittografia

La protezione dei dati è il dominio con le implicazioni normative più dirette: GDPR, NIS2 e DORA convergono tutte sul requisito di proteggere i dati sia in transito che a riposo.

La verifica tecnica deve andare oltre la dichiarazione del vendor (“utilizziamo la crittografia AES-256”) per verificare come la crittografia è implementata, chi gestisce le chiavi e quali dati sono effettivamente protetti.

Particolare attenzione deve essere riservata alla localizzazione dei dati: per i vendor che trattano dati personali o dati critici, è necessario verificare che la data residency dichiarata corrisponda alla realtà dei sistemi.

Ecco una checklist non esaustiva dei controlli necessari in questo dominio:

• Verificare che tutti i dati sensibili siano cifrati a riposo con algoritmi adeguati (AES-256 o equivalente) e che le chiavi siano gestite separatamente dai dati.
• Verificare la cifratura di tutti i canali di trasmissione dei dati (TLS 1.2 minimo, preferibilmente TLS 1.3; assenza di protocolli deprecati come SSL, TLS 1.0/1.1).
• Verificare la gestione delle chiavi crittografiche: sono conservate in HSM o key vault dedicati? Chi ha accesso? Con quale procedura?
• Verificare la localizzazione fisica dei dati: i dati del cliente risiedono nelle regioni geografiche dichiarate contrattualmente? Inclusi backup e log?
• Verificare l’esistenza di una procedura di classificazione dei dati: il vendor sa quali dati del cliente sono sensibili e li tratta di conseguenza?
• Verificare le procedure di cancellazione sicura dei dati a fine contratto: sono documentate, certificate e conformi agli standard (es. NIST SP 800-88)?

Logging, monitoraggio e incident response

Un sistema che non registra ciò che accade è un sistema cieco. Il logging e il monitoraggio sono i prerequisiti tecnici per qualsiasi capacità di detection e response: senza log completi e centralizzati, un incidente può rimanere non rilevato per settimane.

Le organizzazioni nei settori critici NIS2 devono verificare non solo che il vendor produca log, ma che li conservi per il periodo richiesto dalla normativa, che li monitorizzi attivamente e che abbia una procedura di incident response documentata e testata.

La verifica di questo dominio è spesso rivelatrice: i vendor con processi maturi mostrano evidenze concrete; quelli meno strutturati faticano a produrre log storici o a descrivere le procedure di escalation.

Ecco una checklist non esaustiva dei controlli necessari in questo dominio:

• Verificare che i log di sistema, applicativi e di accesso siano abilitati, centralizzati in un SIEM e conservati per almeno 12 mesi (requisito NIS2).
• Verificare l’integrità dei log: sono protetti da modifiche non autorizzate? Esiste una procedura di log integrity verification?
• Verificare la presenza di monitoraggio attivo con alert configurati per eventi di sicurezza critici (accessi anomali, privilege escalation, esportazione massiva di dati).
• Verificare l’esistenza di una procedura di incident response documentata, con ruoli, responsabilità e canali di comunicazione definiti.
• Verificare che la procedura di incident response sia stata testata nell’ultimo anno (tabletop exercise o full drill): esistono evidenze documentate del test?
• Verificare i tempi di detection e response su incidenti recenti: chiedere evidenza di almeno un incidente gestito negli ultimi 12 mesi con relativo post-mortem.

Business continuity e disaster recovery

La resilienza operativa di un partner IT è un requisito critico tanto sul piano normativo quanto su quello operativo.

Per i soggetti NIS2, la capacità di garantire la continuità dei servizi essenziali dipende anche dalla resilienza dei propri fornitori. Per le entità DORA, i requisiti di resilienza operativa digitale si estendono esplicitamente ai provider ICT critici.

La verifica di questo dominio deve produrre evidenze concrete sulle capacità reali di recovery del vendor: non i valori di RTO e RPO dichiarati nel contratto, ma quelli misurati nei test più recenti.

Ecco una checklist non esaustiva dei controlli necessari in questo dominio:

• Verificare l’esistenza di un piano di Business Continuity (BCP) e di Disaster Recovery (DRP) documentati, aggiornati e approvati dal management del vendor.
• Verificare che RTO e RPO dichiarati contrattualmente siano stati effettivamente testati: richiedere i risultati degli ultimi test di DR (data, scenario, esito, scostamenti).
• Verificare la frequenza dei backup: sono eseguiti con cadenza adeguata alla criticità dei dati? Sono conservati in location geograficamente separate?
• Verificare l’integrità dei backup: sono eseguiti test di restore periodici? Con quale frequenza e con quali risultati documentati?
• Verificare i piani di failover: in caso di indisponibilità del data center primario, entro quanto tempo il servizio viene ripristinato sul sito secondario?
• Verificare la gestione delle dipendenze critiche del vendor: i propri sub-fornitori sono inclusi nei piani di BC/DR? Esiste un piano di contingenza per la perdita di un sub-fornitore critico?

Audit e Vendor Risk Management: un ciclo continuo

L’IT Security Audit non è un evento isolato nel tempo: è una componente strutturale di un programma di gestione del rischio fornitore maturo.

La sua efficacia dipende dalla continuità (audit periodici che seguono un piano prestabilito) e dalla coerenza con gli altri strumenti del programma Vendor Risk Management: il risk assessment preliminare che definisce la priorità degli audit, gli SLA che fissano gli standard da verificare, il monitoraggio continuo che segnala quando un audit straordinario è necessario.

L’ispezione periodica delle credenziali d’accesso dei partner previene la violazione dei sistemi centrali. L’audit costituisce l’elemento operativo di una strategia di Vendor Risk Management efficace, focalizzata sulla verifica e sul controllo continuo della supply chain: è attraverso l’audit che le dichiarazioni di conformità diventano evidenze verificabili, e i rischi teorici diventano findings concreti su cui agire.

La frequenza degli audit deve essere proporzionale alla classificazione del rischio del vendor e aggiornata dinamicamente.

Un vendor classificato come critico richiede audit almeno annuali; uno classificato ad alto rischio almeno ogni 18 mesi; i vendor a medio e basso rischio possono essere coperti con audit documentali biennali o con il monitoraggio continuo attraverso strumenti di security rating.

La classificazione deve essere rivista ogni volta che cambiano le circostanze: un vendor che subisce un incidente significativo, che viene acquisito da un nuovo soggetto, o che espande il perimetro dei servizi erogati deve essere riclassificato e, se necessario, sottoposto ad audit straordinario.

Audit nei settori critici NIS2: requisiti e frequenze

La direttiva NIS2 non prescrive una frequenza specifica per gli audit dei partner IT, ma impone alle organizzazioni di adottare misure proporzionate al rischio. Il che, per i soggetti essenziali che dipendono da vendor critici per l’erogazione dei propri servizi, si traduce nella necessità di audit periodici documentati.

Le linee guida ENISA sul rischio supply chain sono più esplicite: raccomandano audit almeno annuali per i fornitori che gestiscono sistemi o dati critici e audit di onboarding per qualsiasi nuovo vendor che acceda a infrastrutture essenziali.

Per le entità finanziarie soggette a DORA, i requisiti di audit sono codificati nel regolamento stesso: le entità hanno il diritto di condurre audit sui provider ICT critici con il supporto, se necessario, delle autorità di vigilanza (EBA, ESMA, EIOPA).

Le entità finanziarie più grandi, quelle designate come sistemicamente rilevanti, sono soggette a requisiti aggiuntivi di test della resilienza operativa digitale (TLPT, Threat-Led Penetration Testing), che includono necessariamente la verifica dei sistemi dei provider ICT critici.

Un aspetto specifico dei settori critici riguarda la gestione dei risultati degli audit: per i soggetti NIS2, le findings significative emerse dall’audit dei vendor devono essere integrate nel processo di gestione del rischio e comunicate al management.

ACN, in qualità di autorità di supervisione, può richiedere evidenza degli audit condotti e dei piani di remediation adottati.

Questo significa che la documentazione dell’audit (piano, evidenze raccolte, findings, piano di remediation, follow-up) deve essere conservata e mantenuta accessibile per un periodo adeguato.

Dalla findings list al piano di remediation: chiudere il ciclo

Un audit che produce un report e non genera azioni concrete è un esercizio documentale senza valore operativo.

Il momento più critico del processo di audit è quello successivo alla consegna del report: la negoziazione del piano di remediation con il vendor, la definizione delle scadenze, il monitoraggio dell’implementazione e la verifica finale.

È qui che si misura la maturità reale del programma di audit di un’organizzazione, non nella qualità del report, ma nella capacità di tradurre le findings in miglioramenti concreti della postura di sicurezza del partner.

Le findings di un audit devono essere classificate per severity (critica, alta, media, bassa) e per ogni finding devono essere definiti: la descrizione tecnica del problema, l’impatto potenziale, la raccomandazione di remediation, il responsabile nel team del vendor, e la scadenza.

Per le findings critiche, la scadenza deve essere ravvicinata (tipicamente 30 giorni) e il monitoraggio deve essere continuo fino alla chiusura. Le findings ad alto rischio devono essere risolte entro 90 giorni; quelle a medio e basso rischio possono essere incluse nel ciclo di miglioramento ordinario del vendor.

La verifica della remediation è il passo che più frequentemente viene saltato, trasformando il piano di remediation in un documento formale senza effetti reali.

Il follow-up deve essere strutturato: entro la scadenza concordata, il vendor deve fornire evidenza tecnica della remediation (screenshot di configurazione, log di sistema, report di nuova scansione di vulnerabilità); l’auditor – interno o esterno – deve verificare l’evidenza e chiudere formalmente il finding.

Le findings non risolte entro le scadenze concordate devono essere scalate al management e, per i vendor critici, devono attivare le clausole contrattuali di penale o, nei casi più gravi, il processo di risoluzione contrattuale.

Strumenti e standard di riferimento per l’IT Security Audit

L’IT Security Audit dei sistemi partner si avvale di un ecosistema consolidato di framework, standard e strumenti tecnici.

Sul fronte degli standard internazionali, ISO 27001:2022 fornisce il framework per la valutazione del sistema di gestione della sicurezza del vendor, con i controlli dell’Annex A come baseline di riferimento per la checklist di audit.

Il CIS Controls v8 offre un set di 18 controlli prioritizzati, organizzati per Implementation Group, che si traducono direttamente in verifiche tecniche durante l’audit.

Infine, il NIST CSF 2.0 fornisce il vocabolario per strutturare i risultati dell’audit nelle cinque funzioni (Identify, Protect, Detect, Respond, Recover) più la nuova funzione Govern, rendendo i risultati immediatamente comunicabili al management.

Sul fronte dei framework, le linee guida ENISA sul rischio della supply chain ICT e il documento ENISA Good Practice Guide for Supply Chain Security offrono una struttura specifica per l’audit dei vendor nei settori critici, con indicazioni sulla valutazione della maturità del fornitore e sulla gestione delle findings.

Per le entità finanziarie, le EBA Guidelines on ICT and Security Risk Management forniscono i requisiti tecnici di riferimento per gli audit dei provider ICT nel settore bancario e assicurativo.

Sul piano degli strumenti tecnici, l’IT security audit di un partner IT si avvale di strumenti di vulnerability scanning, di analisi della configurazione, di analisi dei log e del SIEM e di strumenti di security rating.

La scelta degli strumenti deve essere coerente con il perimetro dell’audit e con il livello di accesso concesso dal vendor: un audit puramente documentale non richiede strumenti di scansione attiva; un audit tecnico approfondito su un vendor critico richiede l’intero stack.