Cosa include un audit di sicurezza informatica aziendale?

In un audit di sicurezza informatica aziendale occorre distinguere la parte organizzativa, che valuta responsabilità, accessi, backup e risposta agli incidenti, dalla parte tecnica, che verifica configurazioni, vulnerabilità e codice dei sistemi. Il prezzo dipende dal numero di sistemi da verificare e dalla profondità del lavoro: il nostro controllo di sicurezza automatizzato costa 89–890 € in base al campo di applicazione, mentre l’audit manuale di un esperto è disponibile a partire da 3.500 €. Chiarisca prima quale parte Le serve e quali evidenze si aspetta, perché la verifica di un sito, la valutazione della gestione della sicurezza aziendale e la certificazione sono incarichi diversi con risultati diversi.

Immagini che un cliente, prima di firmare il contratto, Le chieda un audit di sicurezza, allegando domande sia sui diritti di accesso dei dipendenti sia sulla verifica tecnica del sistema. Inoltrare la richiesta allo sviluppatore non basta: occorre concordare se il cliente si aspetta un rapporto sul sito, processi aziendali documentati o un certificato rilasciato da un organismo indipendente, e quali sistemi o attività debba coprire tale attestazione. Consigliamo di conservare la formulazione esatta della richiesta e chiarirne la finalità prima di scegliere il fornitore e accettare il preventivo.

Due lavori con lo stesso nome

Le due parti rispondono a domande diverse. Quella organizzativa esamina come l’azienda prende e attua le decisioni sulla sicurezza; quella tecnica verifica come funziona un sistema concreto e se sia possibile aggirarne le protezioni. Lo stesso argomento assume quindi forme molto diverse: nella valutazione delle procedure di gestione degli accessi, l’auditor chiede chi approva i diritti di un dipendente e come vengono revocati; nel test dell’applicazione, tenta invece di eseguire con un account ordinario operazioni che quell’account non è autorizzato a compiere. Conviene leggere insieme i due risultati, ma uno non sostituisce l’altro: una politica di accesso ben definita non dimostra che l’applicazione la rispetti, e un’applicazione sicura non dimostra che qualcuno abbia disattivato l’account di un ex dipendente.

La sola parola «audit» nell’incarico dice quindi poco. Consigliamo di aggiungere due elementi: i criteri con cui sarà valutato il lavoro e le evidenze attese nel rapporto. Per una valutazione delle vulnerabilità si tratta di rilievi con relative priorità; per un penetration test, di un meccanismo di protezione o di un limite operativo concreto che si tenterà di aggirare; per un audit organizzativo di conformità, di un insieme di requisiti con cui confrontare documenti e prassi quotidiana.

Se sceglie soltanto una valutazione iniziale delle carenze, la definisca come tale, senza chiamarla certificazione, e concordi già nell’incarico chi dovrà leggere il documento e quale decisione dovrà prendere. Nel caso della certificazione è importante sapere chi rilascerà l’attestazione: ISO non certifica direttamente le aziende e descrive la certificazione come un’attestazione scritta di conformità a determinati requisiti, rilasciata da un organismo indipendente. Nella stessa spiegazione, ISO precisa che l’accreditamento attesta la competenza dell’organismo di certificazione, ma non è obbligatorio; sarebbe quindi inesatto affermare che solo un organismo accreditato possa certificare. Se il Suo cliente richiede una certificazione accreditata, chiarisca questa condizione prima del contratto e verifichi l’accreditamento dell’organismo scelto, per evitare di ritrovarsi con un’attestazione che il cliente non ha accettato di riconoscere.

La nostra offerta riguarda la verifica tecnica dei sistemi web e, per la parte organizzativa, possiamo aiutare a preparare le politiche di sicurezza; tuttavia non certifichiamo le aziende e non gestiamo per Lei il sistema di gestione della sicurezza delle informazioni (SGSI). Conviene indicare questo limite anche nell’incarico. Se il lavoro comprende sia la verifica del sito sia la valutazione della gestione aziendale, concordi chi prepara le evidenze tecniche, chi le confronta con i requisiti scelti e chi risponde della valutazione finale. Altrimenti potrebbe aspettarsi da noi una valutazione dei processi di gestione e dall’auditor organizzativo un test che non ha commissionato. La parte organizzativa viene solitamente svolta da un consulente di gestione della sicurezza delle informazioni o da un auditor ISO/IEC 27001, mentre il certificato è rilasciato da un organismo di certificazione.

La parte organizzativa: confrontare i documenti con il lavoro concreto

Sulla carta tutto può sembrare in ordine: nella parte organizzativa conviene quindi verificare che quanto previsto dalla politica di sicurezza abbia un responsabile, le risorse necessarie ed evidenze di attuazione, e che per i problemi individuati nella valutazione dei rischi siano previsti interventi. La guida ENISA per le piccole e medie imprese tratta responsabilità della direzione, coinvolgimento e formazione dei dipendenti, politiche di sicurezza, gestione dei fornitori, protezione degli accessi e piano di risposta agli incidenti. Affianchi ai colloqui con la direzione e i dipendenti l’esame dei documenti e di esempi operativi concreti, per distinguere nella valutazione le procedure previste dalla loro effettiva applicazione e indicare le evidenze che l’auditor non ha potuto ottenere e che devono ancora essere preparate.

Per gli accessi, un buon auditor esamina non solo come vengono assegnati gli account, ma anche come vengono disattivati, se si usa l’autenticazione a più fattori e quali diritti hanno i fornitori. Negli esempi da verificare conviene quindi includere l’uscita di un dipendente o la sostituzione di un fornitore: è proprio in questi passaggi che gli account tendono a essere dimenticati. Per i backup vale un ragionamento simile, perché rispondere «facciamo i backup» dice poco. Un backup che nessuno ha mai ripristinato potrebbe rivelarsi incompleto durante un incidente, quando il sito è già fuori servizio. L’inventario dei sistemi e dei dispositivi richiede responsabili, i registri degli eventi richiedono una procedura di riesame e il piano di risposta agli incidenti richiede una persona identificata per nome che prenda le decisioni e comunichi con le parti coinvolte. Altrimenti il piano rimane un documento che nessuno mette in pratica durante l’incidente.

Come riferimento per i criteri si può utilizzare ISO/IEC 27001:2022, che stabilisce i requisiti di un sistema di gestione della sicurezza delle informazioni (SGSI): qui «sistema» indica la gestione, non soltanto l’applicazione da verificare. La spiegazione dello standard pubblicata da BSI indica 93 controlli di sicurezza delle informazioni e quattro aree: organizzativa, relativa alle persone, fisica e tecnologica. Concordi quali requisiti valuterà l’audit e con quali evidenze, perché un richiamo allo standard nel preventivo non chiarisce ancora se stia commissionando una valutazione del sistema di gestione o soltanto una verifica tecnica i cui risultati saranno poi utilizzati in un audit più ampio. Metta per iscritto questa scelta prima dell’inizio del lavoro.

Un altro riferimento è costituito dai CIS Controls v8.1, con 18 gruppi di controlli, che coprono aree dall’inventario delle risorse aziendali ai penetration test e comprendono complessivamente 153 misure di protezione. CIS descrive il CIS Implementation Group 1 (IG1) come l’igiene informatica di base, con 56 misure di protezione: nell’incarico precisi quindi anche il gruppo scelto, oltre al nome del framework. Chieda che il rapporto colleghi ogni requisito valutato all’evidenza ricevuta e alla carenza rilevata, così da poter verificare la stessa condizione dopo gli interventi correttivi, anziché confrontare due valutazioni generiche.

Quando la legge richiede un audit di sicurezza informatica

Il D.Lgs. 138/2024 non impone a ogni soggetto essenziale o importante un obbligo generale di commissionare periodicamente un audit esterno. L’Agenzia per la cybersicurezza nazionale (ACN), unica autorità nazionale competente NIS, può richiedere una rendicontazione, comprese autovalutazioni, e audit di sicurezza periodici o mirati, in particolare in caso di incidente significativo o di violazione del decreto. Può anche prescrivere tali audit nell’esercizio dei poteri di esecuzione, ma non può imporre audit periodici ai soggetti importanti. I poteri ispettivi, comprese le ispezioni in loco e a distanza e i controlli casuali, si applicano ai soggetti essenziali; per quelli importanti occorrono elementi che indichino una possibile violazione. Gli audit e le scansioni sono svolti da organismi indipendenti; i costi sono a carico del soggetto, salvo che l’ACN decida diversamente in casi debitamente giustificati. L’ACN può inoltre ordinare di attuare le raccomandazioni dell’audit e di rimediare alle carenze. I soggetti essenziali o importanti del settore bancario e delle infrastrutture dei mercati finanziari sono esclusi dai Capi IV e V del decreto, quindi da questi poteri di audit: a loro si applica il regolamento (UE) 2022/2554. Le reti, i sistemi informativi e i servizi informatici inseriti nell’elenco del perimetro di sicurezza nazionale cibernetica, previsto dal decreto-legge n. 105/2019, sono esclusi dall’intero decreto NIS; gli altri sistemi del soggetto restano sottoposti ai suoi obblighi. Se Le viene proposto un «audit obbligatorio», chieda a quale disposizione si richiami l’offerta e se riguardi un soggetto essenziale, un soggetto importante, un bene del perimetro oppure un soggetto bancario o delle infrastrutture dei mercati finanziari sottoposto al regolamento (UE) 2022/2554.

Il D.Lgs. 138/2024 non prevede un’autovalutazione a scadenza fissa: questa rientra soltanto nella rendicontazione che l’ACN può richiedere, anche periodicamente, senza una scadenza prestabilita dal decreto. Sono adempimenti distinti la registrazione o il suo aggiornamento sulla piattaforma ACN, dal 1° gennaio al 28 febbraio di ogni anno, e la comunicazione e l’aggiornamento dell’elenco delle attività e dei servizi con la relativa categoria di rilevanza, dal 1° maggio al 30 giugno di ogni anno, a partire dalla ricezione della prima comunicazione di inserimento nell’elenco NIS. Per i soggetti essenziali, l’allegato 2 alla determinazione ACN n. 379907/2025, misura ID.RA-01, punto 2, richiede, almeno per i sistemi informativi e di rete rilevanti, attività di identificazione delle vulnerabilità che comprendano un vulnerability assessment e/o un penetration test. Queste attività vanno svolte periodicamente e comunque prima della messa in esercizio dei sistemi, secondo il piano di gestione delle vulnerabilità, salvo motivate e documentate ragioni normative o tecniche. Le attività vanno documentate in un rapporto. Sono rilevanti i sistemi la cui compromissione avrebbe un impatto significativo sulla riservatezza, integrità e disponibilità delle attività e dei servizi per cui il soggetto rientra nel decreto. L’allegato 1 per i soggetti importanti non impone queste verifiche periodiche. Il termine per adottare le misure di sicurezza di base è di 18 mesi dalla comunicazione di inserimento; per chi è inserito per la prima volta nel 2026 scade il 31 luglio 2027. L’ACN indica ottobre 2026 per i primi soggetti inseriti: si tratta del termine di 18 mesi, non di una scadenza per un’autovalutazione. I beni ICT inseriti nell’elenco del perimetro di sicurezza nazionale cibernetica sono esclusi dal decreto NIS: per le piattaforme e le applicazioni software critiche l’allegato B al DPCM n. 81/2021, misura DE.CM-8, richiede sia penetration test sia vulnerability assessment prima della messa in esercizio e poi periodicamente, secondo la criticità. La frequenza è indicata nel piano di verifica e test del soggetto, senza un intervallo in anni fissato dalla norma. I soggetti del perimetro aggiornano inoltre l’elenco dei beni ICT almeno una volta l’anno: anche questo elenco è distinto dall’autovalutazione. Quando riceve un’offerta per un «audit obbligatorio», chieda quindi di indicare l’obbligo concreto, la disposizione che lo prevede e il Suo status, per non considerare la preparazione dell’autovalutazione richiesta dall’ACN, l’audit esterno disposto dall’autorità di controllo e i test richiesti dall’allegato 2 o dall’allegato B come un unico incarico.

La parte tecnica: dagli indirizzi pubblici al codice

Nell’incarico tecnico indichi gli indirizzi pubblici, i record DNS, i servizi esposti e le impostazioni TLS, oltre alla configurazione del server o dell’ambiente cloud, alle applicazioni web e al codice sorgente che autorizza a verificare. Per ogni parte precisi se il fornitore avrà accesso alle configurazioni o valuterà soltanto ciò che è visibile dall’esterno, perché si tratta di attività diverse. Nella classificazione NIST delle tecniche di verifica della sicurezza, l’esame di documenti, registri e configurazioni è distinto dall’identificazione e analisi dei bersagli e dalla conferma delle vulnerabilità. Può utilizzare questa distinzione per descrivere con maggiore precisione nel preventivo i metodi scelti e il risultato atteso.

Per le applicazioni web, OWASP Top 10:2025 offre un linguaggio comune: dieci categorie di rischio, le prime due delle quali sono le carenze nel controllo degli accessi e le configurazioni non sicure. L’elenco, da solo, non verifica nulla: un buon auditor traduce quindi ogni categoria in una domanda sulla Sua applicazione. Per il controllo degli accessi significa tentare le operazioni di un ruolo con l’account di un altro; per la categoria della progettazione non sicura significa scegliere un processo di business le cui regole potrebbero essere aggirate. Completi il riferimento a OWASP con l’indicazione delle attività comprese nella verifica, così che entrambe le parti sappiano quali funzioni e ruoli utente rientrino effettivamente nel lavoro.

Per la posta elettronica preveda la valutazione delle impostazioni SPF, DKIM e DMARC, collegando l’incarico ai sistemi da cui l’azienda invia messaggi: dal 1 febbraio 2024 i requisiti Google per i mittenti prevedono che chiunque invii messaggi ad account Gmail configuri SPF o DKIM, mentre chi invia più di 5.000 messaggi al giorno deve configurare SPF, DKIM e DMARC. La policy DMARC può essere «none», ma per i messaggi diretti il dominio indicato nel campo From deve essere allineato al dominio SPF o DKIM. Chieda quindi di valutare sia le impostazioni sia i percorsi di invio che utilizza, senza limitarsi a segnare la presenza dei record del dominio.

Nei nostri audit il rilievo più frequente è la mancata installazione degli aggiornamenti di PHP, del core del sistema di gestione dei contenuti e dei framework software. Consigliamo quindi di includere nell’incarico tecnico un esame delle versioni, dei plugin e delle dipendenze utilizzati, e di chiedere che ogni rilievo indichi il componente concreto e l’intervento necessario, così che lo sviluppatore riceva un’attività eseguibile anziché un’osservazione generica su un sito obsoleto. Se la Sua priorità è capire quali operazioni gli utenti possano eseguire nel sistema, un esame delle versioni non basta: servono anche test sul controllo degli accessi e test sulla logica di business. Nella nostra esperienza abbiamo riscontrato errori critici che consentivano a qualsiasi utente di ottenere diritti di amministratore e la cui risoluzione ha richiesto la riscrittura completa del nucleo del sistema; un esame delle versioni non avrebbe individuato un errore simile.

La domanda su cosa un utente sia autorizzato a fare è diversa da quella sulle versioni installate, e ciascuna richiede una propria evidenza nel rapporto. NIST definisce la scansione delle vulnerabilità come una tecnica per identificare gli host, le loro caratteristiche e le vulnerabilità associate; nel nostro controllo di sicurezza automatizzato la scansione è una delle fasi del lavoro tecnico. La definizione NIST di penetration test comprende la simulazione di attacchi reali, alla ricerca di modi per aggirare le protezioni e, spesso, di combinazioni di vulnerabilità che consentano un accesso più ampio. Approfondiamo la scelta del test nell’articolo sul penetration test; nell’incarico di audit è essenziale stabilire quali carenze il fornitore si limiterà a cercare, per quali tenterà di dimostrare uno sfruttamento pratico entro i limiti concordati e quali operazioni saranno deliberatamente escluse dal lavoro.

Come si svolge l’audit, dall’incarico alla nuova verifica

Cominci con una descrizione scritta del campo di applicazione che indichi sistemi, applicazioni, indirizzi e ruoli utente da verificare, specificando chiaramente cosa non verrà esaminato nell’incarico. Aggiunga la finalità e i limiti del lavoro: quali operazioni autorizza, in quale ambiente si svolgeranno, chi può interrompere la verifica e chi contattare in caso di imprevisti. Per un sistema di ordini, ad esempio, concordi separatamente come verificare le operazioni che altrimenti genererebbero un ordine reale. Anche chi si occupa della manutenzione deve leggere questo accordo, affinché operazioni autorizzate, accessi e referenti siano concordati prima dell’inizio del lavoro tecnico.

Prima dell’inizio prepari i documenti e le persone da coinvolgere nei colloqui nella misura richiesta dall’incarico: per la parte organizzativa, politiche, esempi di assegnazione degli accessi, registrazioni dei ripristini dei backup e piano di risposta agli incidenti; per quella tecnica, descrizione del sistema e accessi concordati, segnalando anche ciò che ancora manca. Se la verifica riguarda una copia, ne registri le differenze rispetto al sistema utilizzato quotidianamente e concordi come rappresentarle nel rapporto, affinché il lettore possa capire a quale ambiente si riferiscano i risultati e quali questioni siano rimaste aperte per l’indisponibilità di documenti, accessi o funzioni. Per il lavoro tecnico concordi orari precisi dei test e modalità di comunicazione; per l’esame dei documenti preveda una scadenza entro cui i Suoi colleghi possano fornire chiarimenti, così da distinguere nel risultato ciò che è stato verificato da ciò che non è ancora confermato.

Se durante il lavoro il fornitore individua un problema rilevante, chieda che lo comunichi secondo le modalità concordate mentre le altre attività proseguono, senza attendere la data di consegna del rapporto completo. Concordi anche chi decide se proseguire i test su quel punto e come registrare le autorizzazioni o le limitazioni ricevute, perché queste decisioni serviranno a spiegare fino a che punto è stato possibile confermare il rilievo.

Il calendario deve prevedere anche il tempo per le correzioni

L’audit con il nostro sistema richiede alcuni giorni, mentre il lavoro di audit manuale richiede 1–3 settimane in base al campo di applicazione; prima dell’inizio può esserci un’attesa, che dipende dagli impegni dell’auditor. La pagina del servizio indica un intervallo complessivo di esecuzione di 1–60 giorni: non consideri quindi queste descrizioni come un’unica scadenza garantita e concordi prima dell’incarico la data di inizio, la consegna del rapporto e la nuova verifica. Se ha una scadenza fissata da un cliente o da una gara, pianifichi anche il tempo per esaminare e correggere i rilievi e per le risposte del Suo team, perché la data di completamento della verifica e quella entro cui desidera risolvere le carenze sono due momenti distinti della pianificazione.

La nostra offerta di audit manuale di un esperto comprende una nuova verifica entro 30 giorni dalle correzioni. Per utilizzarla efficacemente, alla consegna del rapporto concordi chi correggerà ogni rilievo, chi comunicherà il completamento del lavoro e quali evidenze il fornitore verificherà nuovamente. Definisca separatamente le attività di correzione e il relativo compenso, perché il prezzo dell’audit non costituisce un accordo su tutti gli sviluppi successivi. Può affidare le correzioni al Suo team e farle poi verificare da noi, oppure commissionarcele come lavoro separato, che stimiamo sulla base del rapporto. Nel rapporto della nuova verifica chieda di distinguere le carenze risolte da quelle rinviate o non ancora ricontrollate e di indicare lo stato del sistema utilizzato, affinché il Suo team e il destinatario del rapporto abbiano una risposta comune e comprensibile per ogni rilievo iniziale.

Cosa richiedere nel rapporto di audit

All’inizio del rapporto chieda una sintesi comprensibile alla direzione sulla finalità della verifica, sui sistemi esaminati e sui rilievi principali, così da poter decidere attività e risorse senza rileggere tutto il materiale tecnico. Chieda di indicare nello stesso punto anche i limiti del lavoro. Se il codice sorgente non era disponibile o un ruolo utente non è stato esaminato, chieda che venga dichiarato esplicitamente, senza lasciare al lettore il compito di interpretare una breve valutazione sullo stato del sistema. Valuti la sintesi in base alla capacità del Suo responsabile di ricavarne la prossima decisione, la persona incaricata e la domanda che attende ancora una risposta.

Per ogni rilievo tecnico chieda il punto del sistema interessato, le condizioni in cui è stato individuato, il ruolo utente utilizzato, la descrizione dei passaggi per riprodurlo e l’evidenza del risultato. Per una non conformità organizzativa, oltre al riferimento al requisito, chieda di indicare il documento o l’esempio operativo su cui si basa la valutazione. La raccomandazione correttiva deve chiarire cosa modificare: precisi quindi una formulazione come «sistemare gli accessi» fino a identificare i diritti e la funzione che il Suo sviluppatore deve cambiare, indicando il comportamento atteso dopo la correzione. Il rapporto potrà così servire sia ad assegnare il lavoro sia a controllarlo in seguito, senza costringere ogni nuovo lettore a reinterpretare le intenzioni dell’auditor.

Se il rapporto utilizza CVSS, chieda di indicarne anche la versione: FIRST pubblica CVSS, inclusa la versione 4.0, la cui scala di gravità comprende le etichette «nessuna» (0,0), «bassa» (0,1–3,9), «media» (4,0–6,9), «alta» (7,0–8,9) e «critica» (9,0–10,0); l’utilizzo di queste etichette è facoltativo. Oltre al punteggio, chieda una motivazione e una spiegazione delle conseguenze sull’attività della Sua azienda, ad esempio quali operazioni o dati siano interessati dal rilievo e perché venga consigliato quell’ordine di correzione, così da discutere la priorità sulla base delle circostanze descritte e non soltanto del numero.

Utilizziamo l’esperienza con questi errori critici per richiedere una descrizione chiara delle conseguenze, senza affermare che ogni sito debba essere ricostruito: il rapporto deve distinguere un intervento circoscritto da un problema che richiede di rivedere il funzionamento di base del sistema. Se prevede una rielaborazione ampia, chieda quali evidenze giustifichino la raccomandazione, cosa sia possibile correggere separatamente e quale questione rimarrà irrisolta se l’azienda sceglierà soltanto una parte del lavoro proposto.

Chieda il file dei risultati grezzi dello scanner come allegato, se serve al team tecnico, ma subordini l’accettazione del rapporto alle evidenze, alle priorità e alle raccomandazioni correttive eseguibili previste dal Suo incarico. Non scelga il numero di righe come misura della qualità. Chieda al fornitore di spiegare un rilievo dall’inizio alla fine: come è stato individuato, cosa dimostra il risultato, come riguarda il Suo sistema e come si verificherà dopo le modifiche che sia stato risolto, indicando anche tutto ciò che nella conclusione rimane un’ipotesi. Questo esame offre una base concreta per accettare il rapporto e suddividere il lavoro successivo.

Perché i prezzi degli audit variano tanto

I prezzi variano soprattutto perché le offerte coprono un numero diverso di sistemi e livelli diversi di approfondimento: la scansione automatica e l’esame delle versioni costano centinaia di euro, mentre i test manuali sul controllo degli accessi e i test sulla logica di business, la secure code review e la nuova verifica richiedono giornate di lavoro di un esperto. Nel nostro servizio di audit di sicurezza del sito web, il controllo di sicurezza automatizzato costa 89–890 € in base al campo di applicazione ed è destinato ai sistemi WordPress, Laravel, Drupal, Joomla e Moodle. L’offerta comprende la scansione automatica delle vulnerabilità, la verifica di versioni, plugin e dipendenze, la valutazione della configurazione e delle impostazioni del server, oltre a un rapporto con rilievi e priorità. Utilizzi questi contenuti per confrontare il prezzo con un’altra offerta e precisi quali Sue installazioni saranno verificate. Consideri la cifra minima dell’intervallo in relazione al campo di applicazione concordato, senza estendere il prezzo della verifica di un sito all’insieme dei sistemi aziendali, i cui confini non sono ancora stati valutati dal fornitore.

Il nostro audit manuale di un esperto è disponibile a partire da 3.500 € e comprende una verifica manuale secondo OWASP Top 10, test per aggirare il controllo degli accessi e le regole della logica di business, una secure code review e un penetration test autorizzato. La secure code review è prevista per Laravel, WordPress e soluzioni sviluppate su misura; nel rapporto ordiniamo i rilievi secondo il rischio reale e aggiungiamo a ciascuno una raccomandazione correttiva. L’offerta comprende anche una nuova verifica dopo le correzioni. L’espressione «a partire da» rimane valida anche se il Suo sistema ha un solo indirizzo pubblico, perché per il preventivo occorre ancora concordare funzioni, ruoli e codice da esaminare.

Un controllo completo con il nostro sistema costa solitamente 500–800 €. È la cifra che riscontriamo più spesso nell’intervallo di prezzo del controllo di sicurezza automatizzato, non un prezzo separato per una valutazione congiunta della gestione aziendale, di tutti i sistemi e della certificazione. Colleghi quindi la parola «completo» al campo di applicazione tecnico concreto che abbiamo concordato. Per la maggior parte dei siti consigliamo un controllo di sicurezza automatizzato periodico, ripetibile frequentemente, e un audit manuale di un esperto quando il sistema elabora pagamenti o dati personali oppure è critico per l’attività aziendale, perché solo una persona individua gli errori nei diritti di accesso e i modi per aggirare la logica di business. Nella pratica funziona bene abbinare un controllo di sicurezza automatizzato periodico a un audit manuale una volta all’anno.

Questa distinzione aiuta anche nella discussione sul budget: se Le servono risposte sui componenti e sulle impostazioni del sito, chieda un preventivo per tale attività; se invece la domanda principale riguarda la possibilità di aggirare i diritti degli utenti o le regole di business, includa i test manuali appropriati e lasci che il fornitore ne stimi separatamente il lavoro.

Per confrontare le offerte prepari una descrizione identica dei sistemi, delle applicazioni, dei ruoli utente e, se serve anche la parte organizzativa, delle sedi operative aziendali, poi chieda di indicare separatamente le attività automatiche e quelle manuali. Immagini un preventivo per il solo sito pubblico e un altro per lo stesso sito insieme all’area clienti, all’amministrazione e al codice sorgente: prima di confrontare gli importi, chiarisca i limiti di ciascuna offerta. Per ogni parte registri anche gli accessi necessari, i criteri di conformità scelti e il destinatario del rapporto. Fornirà così al professionista una base concreta per il preventivo e potrà individuare un’attività omessa.

Precisi separatamente se il prezzo comprende la spiegazione dei rilievi al Suo sviluppatore, il collegamento ai requisiti dello standard scelto e la nuova verifica, e dove finisce il lavoro di audit e inizia lo sviluppo delle correzioni. Consigliamo inoltre di prevedere, nel budget dell’audit, una decisione sulla risoluzione delle carenze rilevate. Se il prezzo rimane molto diverso anche tra offerte di pari contenuto, chieda ai fornitori di spiegare il lavoro e i suoi limiti attraverso una funzione concreta, ad esempio la modifica degli accessi di un utente, anziché aggiungendo nomi di servizi. Potrà così scegliere in base al risultato concreto e alle responsabilità, senza affidarsi a promesse di sicurezza totale.

Quando serve un audit di sicurezza informatica aziendale

Consigliamo di commissionare un audit quando l’azienda deve prendere una decisione concreta sulla sicurezza o fornire un’attestazione verificabile, precisando subito se la decisione riguarda la gestione, lo stato tecnico o entrambi. Se il motivo è NIS2, chiarisca prima il Suo status e i requisiti applicabili, anche utilizzando il nostro articolo su NIS2 e sul suo ambito di applicazione, poi definisca l’incarico. L’ordine è importante: chiarisca l’applicabilità dei requisiti e l’attestazione necessaria prima di scegliere il servizio, affinché commissionare un rapporto tecnico non diventi la Sua unica risposta a una questione che richiede di valutare anche responsabilità e processi aziendali. Se il sito non ha account utente, pagamenti o trattamento di dati personali e nessuno richiede un’attestazione, un audit ampio solitamente non serve: installi prima gli aggiornamenti, poi è sufficiente il controllo di sicurezza automatizzato.

Se la verifica è richiesta da un assicuratore o da un cliente, chieda di precisare il risultato atteso e trasmetta al fornitore il testo stesso della richiesta. Ad esempio, distingua una domanda sulla formazione dei dipendenti o sulla prova di ripristino di un backup da una richiesta di verifica dei diritti di accesso dell’applicazione e prepari le evidenze appropriate per le risposte. Se un questionario per i fornitori richiede di attestare un processo di sicurezza più ampio di quello coperto dal Suo audit tecnico, concordi con il cliente le informazioni aggiuntive e incarichi una persona in azienda di raccoglierle, senza ampliare il significato del rapporto tecnico. Precisi inoltre se il destinatario si aspetta il rapporto stesso, risposte a domande specifiche o un’altra forma di attestazione, e con quale scadenza.

Per una gara conservi il tipo di verifica richiesto e le condizioni sulla qualificazione del fornitore esattamente come formulati dal committente, chiarendo i dubbi prima di richiedere il preventivo, per evitare di dover riscrivere l’offerta dopo l’inizio del lavoro. Approfondiamo la scelta nell’articolo sulla verifica di sicurezza richiesta da una gara; per preparare l’incarico tecnico può inviarci la formulazione della richiesta e una descrizione del sistema. Indichi anche la data di invio, la documentazione disponibile e chi, dalla Sua parte, eseguirà le correzioni: il confronto sull’esecuzione della verifica deve comprendere sia la preparazione del rapporto sia la possibilità del Suo team di lavorare sui risultati entro la data necessaria.

Dopo un incidente e tra le verifiche programmate

Dopo un incidente consigliamo di impostare l’incarico di audit sulla domanda concreta ancora senza risposta: se la correzione risolve il problema individuato, se occorre cercare un errore di accesso analogo in un’altra funzione e come l’azienda verificherà in futuro l’applicazione della procedura pertinente. Trasmetta al fornitore una descrizione degli eventi noti e distingua i fatti confermati dalle ipotesi. Se desidera ricostruire lo svolgimento dell’incidente, indichi anche questo lavoro separatamente e ne concordi il risultato, senza presumere che un audit generale del sito risponda automaticamente a tutte le domande sull’incidente. Per le correzioni da verificare mantenga invece il collegamento ai rilievi iniziali, così da poter dire, dopo le modifiche, quale problema sia stato ricontrollato e come.

I nostri clienti commissionano solitamente un audit una o due volte all’anno: è un’osservazione basata sulla nostra esperienza, non un intervallo stabilito per tutte le aziende. Nel Suo piano consigliamo di annotare, accanto alla prossima data, anche le modifiche che porteranno a rivalutare le attività da verificare, ad esempio un nuovo ruolo utente, una funzione di accesso riscritta o la sostituzione di un fornitore con diritti nel sistema. Incarichi il responsabile di confrontare queste modifiche con il campo di applicazione dell’audit precedente e di proporre la parte concreta da verificare. Conservi nell’incarico successivo i rilievi irrisolti del rapporto precedente, insieme alle decisioni di rinviarne la risoluzione, affinché la nuova verifica parta dalla situazione nota.