Contratti NIS2 con i fornitori supportati da evidenze ISO 27001

Sono le 07:40 di lunedì. Il Responsabile della sicurezza delle informazioni di una piattaforma logistica cloud-enabled apre un’e-mail ricevuta da un fornitore di servizi gestiti di rilevamento e risposta. Il messaggio è breve, prudente e scomodo: il fornitore ha rilevato un accesso sospetto a un ambiente di supporto utilizzato da più clienti. I dettagli sono limitati. Il fornitore promette un aggiornamento “non appena possibile”.

Alle 08:15, il responsabile della conformità chiede se l’evento possa attivare una segnalazione NIS2. Alle 08:40, la funzione acquisti sta cercando il contratto. Alle 09:10, la segreteria dell’organo di gestione chiede un briefing sulle responsabilità dell’organo stesso. Alle 10:00, l’ufficio legale chiede se il contratto includa notifica entro 24 ore, diritto di audit, controlli sui subappaltatori, accesso alle evidenze, obblighi di continuità operativa, restituzione dei dati e disposizioni sulla cancellazione.

Nessuno vuole scoprire, durante un incidente in corso, che un accordo con un fornitore critico si limita a prevedere “misure di sicurezza ragionevoli”.

È qui che le clausole contrattuali NIS2 con i fornitori smettono di essere formulari legali standard e diventano controlli operativi. Per soggetti essenziali e importanti, la governance dei fornitori è ormai parte della responsabilità dell’organo di gestione, delle evidenze per le autorità di vigilanza, della preparazione agli incidenti, dell’assurance verso i clienti, della conformità privacy e della pianificazione della resilienza. Un contratto firmato non basta. L’organizzazione deve dimostrare che i rischi dei fornitori sono identificati, approvati, trattati, monitorati e supportati da evidenze.

L’approccio di Clarysec parte da un principio semplice: se la clausola sul fornitore non può essere monitorata, supportata da evidenze e testata, non è un controllo.

Il Zenith Blueprint: roadmap dell’auditor in 30 passaggi colloca i rapporti con i fornitori nella fase Controlli in azione, Passaggio 23, in cui accordi, monitoraggio, onboarding, rivalutazione ed evidenze di audit vengono tradotti in attività pratiche del SGSI. Il Zenith Controls: guida alla conformità trasversale mappa poi i controlli ISO/IEC 27002:2022 sui fornitori rispetto a NIS2, DORA, GDPR, NIST, COBIT 2019, standard ISO di supporto e metodologie di audit.

Il risultato è un modello di governance dei fornitori utilizzabile da acquisti, legale, sicurezza, privacy e organo di gestione.

Perché NIS2 trasforma i contratti con i fornitori in registrazioni probatorie

NIS2 Article 20 richiede agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione ed essere responsabili delle violazioni. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, incluse analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e manutenzione sicure, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e MFA ove appropriato.

Article 21(3) rende esplicita la due diligence sui fornitori. Le organizzazioni devono considerare le vulnerabilità specifiche dei fornitori diretti e dei fornitori di servizi, la qualità complessiva dei prodotti e delle pratiche di cibersicurezza e le procedure di sviluppo sicuro.

Questo linguaggio crea un obbligo pratico: i rapporti con i fornitori devono essere basati sul rischio, applicabili contrattualmente e riesaminabili. Un questionario del fornitore archiviato in una cartella non è sufficiente. Un contratto generico senza tempi di notifica degli incidenti, senza diritti di accesso alle evidenze e senza visibilità sui subappaltatori non è sufficiente. Una certificazione del fornitore che nessuno ha riesaminato non è sufficiente.

ISO/IEC 27001:2022 fornisce il modello operativo. Le clausole da 4.1 a 4.4 richiedono all’organizzazione di comprendere il contesto, le parti interessate, gli obblighi legali e contrattuali, il campo di applicazione del SGSI e le dipendenze. Le clausole da 5.1 a 5.3 richiedono leadership, politica, ruoli e reporting. Le clausole da 6.1.1 a 6.1.3 richiedono valutazione del rischio, trattamento del rischio e Dichiarazione di applicabilità. Le clausole da 8.1 a 8.3 richiedono controllo operativo, ripetizione delle valutazioni del rischio e risultati documentati.

Per la governance dei fornitori, i controlli più importanti dell’Appendice A di ISO/IEC 27002:2022 includono:

• A.5.19 Sicurezza delle informazioni nei rapporti con i fornitori
• A.5.20 Gestione della sicurezza delle informazioni negli accordi con i fornitori
• A.5.21 Gestione della sicurezza delle informazioni nella catena di fornitura ICT
• A.5.22 Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori
• A.5.24 Pianificazione e preparazione della gestione degli incidenti
• A.5.25 Valutazione e decisione sugli eventi di sicurezza delle informazioni
• A.5.26 Risposta agli incidenti di sicurezza delle informazioni
• A.5.27 Apprendimento dagli incidenti di sicurezza delle informazioni
• A.5.28 Raccolta delle evidenze
• A.5.29 Sicurezza delle informazioni durante le interruzioni
• A.5.30 Prontezza ICT per la continuità operativa
• A.5.31 Requisiti legali, statutari, normativi e contrattuali
• A.5.34 Privacy e protezione dei dati personali identificabili
• A.8.8 Gestione delle vulnerabilità tecniche
• A.8.13 Backup delle informazioni
• A.8.15 Logging
• A.8.16 Attività di monitoraggio
• A.8.24 Uso della crittografia
• A.8.32 Gestione delle modifiche

Il punto chiave è la titolarità. Una clausola ha poco valore se nessuno è titolare del rischio, nessuno riesamina le evidenze, nessuno traccia le eccezioni e nessuno segnala la non conformità tramite escalation.

La policy Enterprise Politica di sicurezza delle terze parti e dei fornitori lo rende esplicito:

“Diritti di audit, ispezione e richiesta di evidenze di sicurezza”

Dalla sezione “Requisiti di governance”, clausola di policy 5.3.4.

Per le PMI, la Politica di sicurezza delle terze parti e dei fornitori per PMI definisce la stessa aspettativa pratica:

“Diritti di audit o disponibilità di evidenze di conformità”

Dalla sezione “Requisiti di governance”, clausola di policy 5.3.4.

Questa distinzione è importante. Un’organizzazione più piccola potrebbe non essere in grado di sottoporre ad audit on-site ogni principale fornitore cloud, ma può richiedere accesso a evidenze di assurance, come il campo di applicazione della certificazione ISO/IEC 27001:2022, rapporti SOC, sintesi dei test di penetrazione, attestazioni di remediation delle vulnerabilità, sintesi degli incidenti, rapporti dei test di continuità operativa e conferme di cancellazione dei dati.

La dorsale a tre controlli dell’assurance sui fornitori NIS2

Nel modello di conformità trasversale di Clarysec, tre controlli ISO/IEC 27002:2022 costituiscono la dorsale della governance dei fornitori NIS2: 5.19, 5.20 e 5.22.

A.5.19 identifica il rischio del fornitore

Il controllo A.5.19, Sicurezza delle informazioni nei rapporti con i fornitori, è il fondamento. Richiede alle organizzazioni di proteggere informazioni e asset cui i fornitori accedono o che trattano, archiviano o gestiscono.

Zenith Controls lo classifica come controllo preventivo relativo a riservatezza, integrità e disponibilità, con il concetto di cibersicurezza “Identificare” e la capacità operativa “sicurezza dei rapporti con i fornitori”. Collega A.5.19 ad A.5.20, A.5.21, A.5.14, A.5.36 e A.5.10. In termini pratici, l’organizzazione identifica il rischio dei fornitori, definisce le aspettative di sicurezza, controlla l’esposizione della catena di fornitura ICT, protegge il trasferimento delle informazioni, monitora la conformità ed estende gli obblighi di uso accettabile alle parti esterne.

Per NIS2, ciò si mappa direttamente su Article 21(2)(d) sicurezza della catena di fornitura e Article 21(3) due diligence sui fornitori. Per GDPR, supporta il requisito di utilizzare responsabili del trattamento che forniscano garanzie sufficienti. Per DORA, supporta la gestione del rischio delle terze parti ICT, la due diligence precontrattuale, il riesame della criticità, il rischio di concentrazione e la supervisione del ciclo di vita.

A.5.20 rende il requisito applicabile

Il controllo A.5.20, Gestione della sicurezza delle informazioni negli accordi con i fornitori, trasforma le aspettative di sicurezza in obblighi contrattuali. Zenith Controls spiega chiaramente il rapporto tra A.5.19 e A.5.20:

“5.20 rappresenta la formalizzazione contrattuale delle esigenze di sicurezza e dei rischi identificati nell’ambito di 5.19. Mentre 5.19 riguarda la valutazione dei rischi di terze parti e la definizione delle aspettative di sicurezza, 5.20 assicura che tali aspettative siano giuridicamente vincolanti tramite contratti o Accordi sul livello di servizio (SLA). Senza 5.20, le misure di sicurezza identificate in 5.19 non sarebbero applicabili.”

È qui che le decisioni di rischio NIS2 diventano clausole: notifica delle violazioni, diritti di audit e di accesso alle evidenze, cifratura, controllo degli accessi, gestione delle vulnerabilità, approvazione dei subappaltatori, trasferimento sicuro, continuità, cooperazione normativa, supporto all’uscita e cancellazione dei dati.

A.5.22 dimostra che il contratto è operativo

Il controllo A.5.22, Monitoraggio, riesame e gestione delle modifiche dei servizi dei fornitori, impedisce che l’assurance sui fornitori diventi un esercizio una tantum in fase di onboarding. Zenith Controls collega A.5.22 ad A.5.19 e A.5.20, ma anche ad A.5.29 sicurezza delle informazioni durante le interruzioni, A.8.8 gestione delle vulnerabilità tecniche, A.5.36 conformità a politiche, regole e standard per la sicurezza delle informazioni, A.5.15 controllo degli accessi e A.8.27 architettura sicura dei sistemi e principi di ingegneria.

Questo è rilevante perché i servizi dei fornitori cambiano. Cambiano le localizzazioni dei dati. Cambiano i sub-responsabili. Emergono vulnerabilità. Le certificazioni scadono. Si manifestano schemi ricorrenti di incidenti. Un fornitore accettabile l’anno scorso può essere troppo rischioso oggi.

Cosa devono includere le clausole contrattuali NIS2 con i fornitori

Il Zenith Blueprint, fase Controlli in azione, Passaggio 23, fornisce un insieme pratico di aree da coprire negli accordi con i fornitori:

“Le aree chiave normalmente trattate negli accordi con i fornitori includono:

✓ Obblighi di riservatezza, inclusi campo di applicazione, durata e restrizioni alla comunicazione a terze parti; ✓ Responsabilità di controllo degli accessi, ad esempio chi può accedere ai dati, come sono gestite le credenziali e quale monitoraggio è in essere; ✓ Misure tecniche e organizzative per la protezione dei dati, la cifratura, la trasmissione sicura, il backup e gli impegni di disponibilità; ✓ Tempi e protocolli di segnalazione degli incidenti, spesso con termini definiti, ad esempio “notificare entro 24 ore”; ✓ Diritto di audit, inclusi frequenza, ambito e accesso alle evidenze pertinenti, ad esempio rapporti di test di penetrazione, SoA e certificazioni; ✓ Controlli sui subappaltatori, richiedendo al fornitore di trasferire obblighi di sicurezza equivalenti ai propri partner a valle; ✓ Disposizioni di fine contratto, come restituzione o distruzione dei dati, ripristino degli asset e disattivazione degli account.”

Dalla fase Controlli in azione, Passaggio 23: Controlli organizzativi.

Una clausola NIS2 solida per i fornitori è abbastanza specifica da poter essere testata. “Il fornitore deve mantenere un livello di sicurezza appropriato” è debole. “Il fornitore deve notificare il referente di sicurezza del cliente entro 24 ore in caso di incidenti confermati o sospetti che incidano su sistemi del cliente, dati del cliente, disponibilità del servizio o obblighi di segnalazione normativa” è verificabile in audit.

Le clausole sugli incidenti devono allinearsi alla decorrenza dei termini di segnalazione NIS2

NIS2 Article 23 crea un modello di segnalazione per fasi per gli incidenti significativi: un preallarme entro 24 ore dalla presa di conoscenza, una notifica dell’incidente entro 72 ore, relazioni intermedie ove richieste e una relazione finale entro un mese dalla notifica dell’incidente. Un incidente significativo è un incidente che ha causato o è in grado di causare una grave interruzione operativa, una perdita finanziaria o un danno materiale o immateriale considerevole ad altri soggetti.

I contratti con i fornitori devono supportare tale tempistica. Se un fornitore critico di servizi gestiti impiega quattro giorni per confermare se gli ambienti dei clienti sono stati interessati, il cliente può non rispettare la propria finestra regolatoria.

La policy Enterprise Politica di sicurezza delle terze parti e dei fornitori richiede:

“Tempi di notifica delle violazioni, ad esempio entro 24 o 72 ore, a seconda della criticità e dei requisiti normativi”

Dalla sezione “Requisiti di governance”, clausola di policy 5.3.3.

Anche la policy per PMI Politica di sicurezza delle terze parti e dei fornitori per PMI richiede tempi definiti di notifica delle violazioni dalla sezione “Requisiti di governance”, clausola di policy 5.3.3.

Per gli incidenti relativi ai dati personali identificabili, la policy Enterprise Politica di gestione degli incidenti e delle violazioni dei dati personali identificabili collega la reportistica per cibersicurezza, settore finanziario, clienti e destinatari del servizio:

“[Condizionale] Il Referente privacy / Responsabile PIMS DEVE coordinare qualsiasi segnalazione di incidente richiesta a livello settoriale, di cibersicurezza, del settore finanziario, del cliente o del destinatario del servizio quando un incidente relativo ai dati personali ad alto impatto soddisfa un presupposto di segnalazione applicabile, e DEVE registrare autorità, destinatario, tempistica, invio ed evidenza di ricezione in REG01 e REG10.”

Dalla sezione “Notifica e comunicazioni”, clausola di policy 4.4.6.

Questa è evidenza NIS2 matura: non solo un’e-mail di notifica, ma una registrazione di autorità, destinatario, tempistica, invio, conferma di ricezione, impatto, causa radice e azioni di follow-up.

Allineamento privacy e DORA senza programmi duplicati per i fornitori

Molti fornitori NIS2 trattano anche dati personali. GDPR Article 28 richiede ai titolari del trattamento di utilizzare responsabili del trattamento che forniscano garanzie sufficienti e di definire gli obblighi del responsabile in un contratto scritto. GDPR Article 5 richiede accountability per un trattamento sicuro e lecito. Anche gli obblighi GDPR in materia di violazione richiedono cooperazione tempestiva quando gli incidenti del fornitore incidono sui dati personali.

La policy Enterprise Politica di gestione privacy di responsabili del trattamento, sub-responsabili e terze parti definisce il gate di approvazione:

“[Entrambi] Il Responsabile fornitori/acquisti DEVE assicurare, prima dell’approvazione, che i contratti con responsabili del trattamento e sub-responsabili includano assistenza privacy, assurance di sicurezza, interfaccia per gli incidenti tramite PII15, restituzione o cancellazione tramite PII10, collegamento ai trasferimenti tramite PII13 e cooperazione per audit o assurance.”

Dalla sezione “Controlli contrattuali e sulle istruzioni documentate”, clausola di policy 4.3.6.

Richiede inoltre il riesame delle evidenze prima dell’approvazione:

“[Tutti] Il Responsabile della sicurezza delle informazioni DEVE riesaminare le evidenze di assurance di sicurezza per ciascun rapporto con responsabile del trattamento, sub-responsabile o terza parte con accesso ai dati personali identificabili o hosting prima dell’approvazione, e DEVE registrare l’esito in REG08 o REG12.”

Dalla sezione “Due diligence e valutazione del rischio”, clausola di policy 4.2.2.

DORA aggiunge un ulteriore livello quando il fornitore serve un’entità finanziaria. DORA Articles da 28 a 30 richiedono governance delle terze parti ICT, registri dei contratti di servizi ICT, due diligence basata sul rischio, valutazione della criticità, analisi del rischio di concentrazione, diritti di audit e ispezione, diritti di risoluzione, strategie di uscita e disposizioni contrattuali obbligatorie. Article 30 è particolarmente rilevante perché richiede contenuti contrattuali relativi a descrizioni dei servizi, localizzazioni, protezione dei dati, accesso e ripristino, livelli di servizio, assistenza in caso di incidenti, cooperazione con le autorità, diritti di audit, subappalto, misure di continuità e supporto alla transizione.

La risposta pratica non consiste in tre programmi separati per i fornitori per NIS2, GDPR e DORA. Consiste in un unico modello armonizzato di evidenze sui fornitori, mappato tra quadri di riferimento.

NIST CSF 2.0 è utile perché la sua funzione GOVERN richiede di comprendere dipendenze, obblighi legali, obblighi contrattuali, propensione al rischio, politiche, accountability e supervisione. La categoria della catena di fornitura GV.SC copre ruoli dei fornitori, criticità, requisiti contrattuali, due diligence, monitoraggio, inclusione negli incidenti, monitoraggio del ciclo di vita e disposizioni di fine rapporto.

Un flusso di lavoro Clarysec per l’onboarding di un fornitore critico

Supponiamo di effettuare l’onboarding di un fornitore di servizi di sicurezza gestiti che monitorerà la telemetria degli endpoint, riceverà allerte contenenti identificativi utente e supporterà il triage degli incidenti per un’organizzazione rientrante nell’ambito NIS2.

Passaggio 1: classificare il fornitore

Registrare il fornitore nel Registro dei fornitori con descrizione del servizio, sistemi e dati accessibili, coinvolgimento di dati personali identificabili, supporto a servizi essenziali o importanti, accessi privilegiati, paesi di erogazione del servizio, subappaltatori, dipendenze di quarta parte, classificazione di criticità, titolare del rischio, responsabile degli acquisti e referente del riesame di sicurezza delle informazioni.

Questo applica le clausole ISO/IEC 27001:2022 4.2, 4.3, 6.1.2 e 8.1 collegando requisiti delle parti interessate, dipendenze, titolarità del rischio e controllo operativo.

Passaggio 2: mappare il rischio sulla SoA

Nel Zenith Blueprint, fase Gestione del rischio, Passaggio 13, Clarysec raccomanda di indicare i riferimenti normativi nel Registro dei rischi o nella SoA:

“Riferimenti incrociati alle normative: se determinati controlli sono applicati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile annotarlo nel Registro dei rischi, come parte della giustificazione dell’impatto del rischio, oppure nelle note della SoA.”

Dalla fase Gestione del rischio, Passaggio 13: pianificazione del trattamento del rischio e Dichiarazione di applicabilità.

Per l’MSSP, includere almeno A.5.19, A.5.20, A.5.21, A.5.22, da A.5.24 ad A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 e A.8.24.

Passaggio 3: richiedere clausole applicabili

Utilizzare un addendum di sicurezza per il fornitore che richieda notifica iniziale dell’incidente entro 24 ore, aggiornamento dettagliato entro 72 ore, reportistica finale sugli incidenti, MFA per gli accessi privilegiati, account utente nominativi, controlli sui subappaltatori, trasferimento sicuro, cifratura, evidenze di assurance, cooperazione normativa, evidenze BCP e DR, supporto all’uscita, restituzione o cancellazione dei dati e revoca degli accessi.

La policy Enterprise Politica di gestione del rischio di dipendenza dai fornitori fornisce il requisito di continuità:

“Ove applicabile, un requisito affinché il fornitore mantenga i propri Piani di continuità operativa (BCP/DRP) e piani di gestione degli incidenti, li testi e ci fornisca sintesi o rapporti di test su richiesta.”

Dalla sezione “Requisiti di applicazione”, clausola di policy 6.8.4.

Passaggio 4: costruire il pacchetto di evidenze di assurance

Prima dell’approvazione, richiedere accordo firmato, SLA, addendum di sicurezza, campo di applicazione della certificazione ISO/IEC 27001:2022 o assurance equivalente, rapporto SOC ove disponibile, sintesi esecutiva del test di penetrazione, sintesi della gestione delle vulnerabilità, sintesi della procedura di risposta agli incidenti, sintesi del test BCP o DR, attestazione del controllo degli accessi e MFA, elenco dei subappaltatori, procedura di cancellazione dei dati e di uscita e DPA ove siano trattati dati personali identificabili.

La policy per PMI Politica di sicurezza delle terze parti e dei fornitori per PMI rende misurabili le evidenze contrattuali di base:

“Accordi e SLA firmati”

Dalla sezione “Applicazione e conformità”, clausola di policy 8.3.2.1.

Identifica inoltre evidenze ricorrenti dei fornitori:

“Certificazioni di sicurezza valide o evidenze dei controlli aggiornate”

Dalla sezione “Requisiti di applicazione della politica”, clausola di policy 6.3.1.2.

Per una più ampia due diligence sui fornitori, la Politica di audit e monitoraggio della conformità stabilisce:

“La due diligence sui fornitori deve includere il riesame delle certificazioni, ad esempio ISO 27001 e SOC 2, dei questionari di sicurezza e delle registrazioni degli incidenti.”

Passaggio 5: monitorare in base alla criticità

La policy Enterprise Politica di gestione privacy di responsabili del trattamento, sub-responsabili e terze parti richiede monitoraggio trimestrale per i rapporti PII ad alto rischio:

“[Tutti] Il Responsabile fornitori/acquisti DEVE monitorare trimestralmente i rapporti attivi ad alto rischio con responsabili del trattamento e sub-responsabili e annualmente gli altri rapporti attivi con responsabili del trattamento e sub-responsabili PII rispetto a condizioni di due diligence, stato contrattuale, stato di assurance, rilievi aperti e date di riesame in REG08.”

Dalla sezione “Monitoraggio continuo, assistenza, interfaccia di comunicazione e uscita”, clausola di policy 4.5.1.

È così che A.5.22 diventa reale. Il riesame deve determinare se il fornitore resta entro la propensione al rischio, se le evidenze sono aggiornate, se esistono rilievi aperti, se si sono verificati incidenti e se modifiche del servizio richiedono una rivalutazione.

Come gli auditor testeranno le clausole NIS2 con i fornitori

Gli auditor raramente iniziano leggendo la policy in modo isolato. Campionano i fornitori e seguono la traccia delle evidenze.

Un auditor ISO/IEC 27001:2022 richiederà inventario dei fornitori, classificazione del rischio, criteri per i fornitori, registrazioni di due diligence, contratti, evidenze, mappatura SoA e cronologia del monitoraggio. Per Appendice A 5.20, l’auditor verificherà se i contratti campionati contengono clausole applicabili. Per Appendice A 5.22, testerà se i rapporti sono stati riesaminati, le eccezioni sono state registrate e le azioni sono state seguite.

Un’autorità competente NIS2 può concentrarsi sulla verifica che le pratiche di cibersicurezza dei fornitori e le procedure di sviluppo sicuro siano state valutate ai sensi di Article 21(3). Un riesaminatore orientato a DORA può richiedere voci del registro dei contratti ICT, strategie di uscita, analisi del rischio di concentrazione e disposizioni obbligatorie di Article 30. Un auditor privacy può testare i contratti con i responsabili del trattamento, gli obblighi a cascata verso i sub-responsabili, le interfacce per le violazioni e le evidenze di garanzie sufficienti.

La policy Enterprise Politica di sicurezza e controllo degli accessi PII mostra come controllo degli accessi, vulnerabilità, configurazione, monitoraggio e crittografia si ricolleghino a ISO/IEC 27001:2022:

“ISO/IEC 27001:2022 — Clausola 6.1.3; Clausola 8.1; controlli dell’Appendice A 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Trattati dalle clausole [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”

Dalla sezione “Standard e quadri di riferimento”, clausola di policy 13.9.

Quando un fornitore ha accesso a dati personali identificabili, sistemi privilegiati o dati di monitoraggio, le evidenze del controllo degli accessi non sono separate dall’assurance sui fornitori. Fanno parte della stessa traccia di audit.

La trappola degli acquisti: contratti firmati senza attività operative di assurance

Il più comune fallimento della governance dei fornitori NIS2 non è l’assenza di contratti. È lo scarto tra linguaggio contrattuale e operatività quotidiana.

Un contratto può richiedere sintesi annuali dei test di penetrazione, ma nessun titolare le richiede. Può richiedere notifica degli incidenti entro 24 ore, ma il fornitore dispone solo di un indirizzo di supporto generico. Può richiedere l’approvazione dei subappaltatori, ma la funzione acquisti non riceve mai notifiche di modifica. Può includere diritti di audit, ma l’organizzazione non ha un processo per valutare le eccezioni nei rapporti SOC. Può richiedere la cancellazione dei dati all’uscita, ma l’IT non convalida mai la disattivazione degli account.

Il Zenith Blueprint, fase Controlli in azione, Passaggio 23, spiega come i controlli sui fornitori diventano operativi:

“In pratica, questo controllo prende forma tramite:

✓ Valutazioni del rischio dei fornitori, ✓ Questionari di due diligence pre-incarico, ✓ Modelli contrattuali con termini di sicurezza integrati, ✓ Checklist di onboarding dei fornitori che includono provisioning degli accessi e configurazione del monitoraggio, ✓ Rivalutazioni continue, in particolare quando cambia l’ambito del fornitore, si verificano incidenti o si avvicinano i rinnovi.

E questo controllo non si ferma ai fornitori di Tier 1. Il vostro fornitore può esternalizzare ai propri provider, e potreste comunque sostenere il rischio.”

Questo è il messaggio NIS2 a livello di organo di gestione: esternalizzare l’erogazione del servizio non esternalizza l’accountability.

Checklist di remediation dei contratti con i fornitori NIS2

Partire dai primi 20 fornitori per criticità ed eseguire un intervento mirato di remediation:

• Identificare i fornitori che supportano servizi essenziali o importanti.
• Confermare se ciascun fornitore tratta dati personali identificabili, supporta servizi regolamentati o dispone di accessi privilegiati.
• Assegnare un titolare di business, un responsabile degli acquisti e un referente del riesame di sicurezza.
• Verificare che la valutazione del rischio del fornitore sia aggiornata e allineata al campo di applicazione effettivo del servizio.
• Confermare che il contratto includa baseline di sicurezza, notifica degli incidenti, diritti di audit o di accesso alle evidenze, controlli sui subappaltatori, continuità, trasferimento sicuro, controllo degli accessi, cooperazione sulle vulnerabilità e clausole di uscita.
• Confermare che i tempi di notifica delle violazioni supportino le esigenze di escalation a 24 e 72 ore ove pertinenti.
• Richiedere evidenze di assurance aggiornate, incluse certificazioni, rapporti SOC, sintesi dei test di penetrazione, test BCP o DR e cronologia degli incidenti.
• Riesaminare le evidenze, non limitarsi ad archiviarle.
• Registrare le eccezioni e assegnare i titolari della remediation.
• Aggiornare la SoA e il Registro dei rischi quando i controlli sui fornitori supportano NIS2, GDPR, DORA o impegni verso i clienti.
• Pianificare la frequenza del monitoraggio in base alla criticità del fornitore.
• Testare un percorso di escalation degli incidenti del fornitore.
• Testare un percorso di cessazione del fornitore, incluse restituzione dei dati, cancellazione, ripristino degli asset e revoca degli accessi.

Se non è possibile dimostrare questi punti per un fornitore critico, il contratto non è ancora idoneo all’audit.

Trasformare le clausole sui fornitori in evidenze per le autorità di vigilanza

La governance dei fornitori NIS2 è ormai una disciplina operativa attiva. Autorità di vigilanza, clienti, auditor di certificazione, team privacy, partner del settore finanziario e organi di gestione non chiederanno solo se esistono clausole sui fornitori. Chiederanno se tali clausole sono basate sul rischio, applicabili, monitorate, supportate da evidenze e collegate a segnalazione degli incidenti, continuità, controllo degli accessi, gestione delle vulnerabilità, obblighi a cascata verso i subappaltatori e uscita.

Clarysec aiuta le organizzazioni a colmare questo divario con il Zenith Blueprint, che trasforma i controlli sui fornitori in fasi SGSI, trattamento del rischio, voci SoA, routine di onboarding ed evidenze di audit. Zenith Controls mappa i controlli ISO/IEC 27002:2022 sui fornitori A.5.19, A.5.20 e A.5.22 rispetto a NIS2, DORA, GDPR, NIST, COBIT 2019, standard ISO di supporto e metodologie di audit. Le politiche Clarysec sui fornitori e sulla privacy forniscono struttura delle clausole, aspettative sulle evidenze e routine di monitoraggio che rendono difendibile l’assurance sui fornitori.

La prossima azione è semplice: selezionare cinque fornitori critici, campionare i relativi contratti, mappare ogni clausola sul trattamento del rischio ISO/IEC 27001:2022 e sui controlli dell’Appendice A, richiedere evidenze di assurance aggiornate ed eseguire un’esercitazione tabletop sulla notifica degli incidenti entro 24 ore. Se la traccia delle evidenze si interrompe, i toolkit Clarysec forniscono la struttura per ripararla prima che lo facciano un incidente, un riesame del cliente o una richiesta dell’autorità di vigilanza.