Evidenze per la registrazione NIS2 in ISO 27001:2022

L’e-mail arrivò nella casella di Anna con un tono discreto che suonò più come una sirena. In qualità di CISO di CloudFlow, un fornitore SaaS B2B in rapida crescita che serve clienti in tutta l’UE, era abituata ai questionari di sicurezza, agli audit di procurement e agli audit di sorveglianza ISO 27001. Questo messaggio era diverso.

L’oggetto recitava: “Richiesta di informazioni relativa all’attuazione nazionale della Direttiva (UE) 2022/2555 (NIS2)”. L’autorità nazionale per la cibersicurezza chiedeva a CloudFlow di confermare la propria classificazione, predisporre le informazioni per la registrazione dell’entità, identificare i servizi inclusi nell’ambito di applicazione ed essere pronta a dimostrare le misure di gestione del rischio di cibersicurezza.

Anna aveva un certificato ISO 27001:2022 incorniciato alla parete. Il team commerciale lo usava nelle trattative enterprise. Il consiglio di amministrazione aveva approvato la Politica per la sicurezza delle informazioni. L’audit interno aveva da poco chiuso due rilievi. Ma la domanda davanti a lei era più incisiva dello stato di certificazione.

CloudFlow poteva dimostrare, rapidamente e in modo sostenibile, che il suo SGSI ISO 27001:2022 copriva gli obblighi NIS2?

È qui che molte organizzazioni sbagliano approccio. Trattano la registrazione dell’entità NIS2 come un adempimento amministrativo, simile all’aggiornamento di un registro imprese o di un portale fiscale. Non lo è. La registrazione è la porta di ingresso alla visibilità da parte dell’autorità di vigilanza. Dopo quella porta, l’autorità competente può chiedere il razionale dell’ambito, le registrazioni di approvazione del consiglio di amministrazione, le procedure di segnalazione degli incidenti, le evidenze sui rischi dei fornitori, i punti di contatto, le metriche di efficacia dei controlli e la prova che l’organizzazione sa quali servizi sono critici.

Per fornitori SaaS, cloud, servizi gestiti, servizi di sicurezza gestiti, data center, infrastrutture digitali e alcuni operatori del settore finanziario, la domanda reale non è più “Abbiamo una politica di sicurezza?”. È “Siamo in grado di mostrare una catena di evidenze che colleghi l’obbligo legale all’ambito del SGSI, al trattamento del rischio, al funzionamento dei controlli e alla supervisione della direzione?”.

Il programma più solido di preparazione all’applicazione di NIS2 non è un foglio di calcolo parallelo. È un modello di evidenze tracciabile all’interno di ISO 27001:2022.

La registrazione NIS2 è prima di tutto un problema di evidenze

NIS2 si applica in modo ampio alle entità pubbliche o private dei settori elencati nell’Allegato I e nell’Allegato II che soddisfano o superano la soglia pertinente delle medie imprese. Include inoltre determinate entità indipendentemente dalle dimensioni, tra cui i fornitori di reti o servizi pubblici di comunicazione elettronica, i prestatori di servizi fiduciari, i registri TLD, i fornitori di servizi DNS, i fornitori unici di servizi essenziali e le entità la cui interruzione potrebbe incidere sulla sicurezza pubblica, sulla salute, sul rischio sistemico o sulla criticità nazionale o regionale.

Per le aziende tecnologiche, le categorie digitali sono particolarmente rilevanti. L’Allegato I include le infrastrutture digitali, quali i fornitori di servizi di cloud computing, i fornitori di servizi di data center, i fornitori di reti di distribuzione dei contenuti, i prestatori di servizi fiduciari, i fornitori di servizi DNS e i fornitori di reti o servizi pubblici di comunicazione elettronica. L’Allegato I include inoltre la gestione dei servizi ICT per servizi business-to-business, compresi i fornitori di servizi gestiti e i fornitori di servizi di sicurezza gestiti. L’Allegato II include i fornitori digitali, quali mercati online, motori di ricerca online e piattaforme di social networking.

Ciò significa che un’organizzazione può rientrare nell’ambito di NIS2 senza considerarsi “infrastruttura critica”. Una società SaaS B2B con funzionalità di servizi di sicurezza gestiti, una piattaforma cloud a supporto di clienti regolamentati o un fornitore adiacente al fintech può improvvisamente avere bisogno di un fascicolo di registrazione, di un modello di contatto con l’autorità competente e di una narrazione di controllo sostenibile.

NIS2 distingue inoltre tra entità essenziali e importanti. Le entità essenziali sono generalmente soggette a un modello di vigilanza più proattivo, mentre le entità importanti sono di norma sottoposte a vigilanza dopo evidenze di non conformità o incidenti. La distinzione è rilevante, ma non elimina la necessità di prepararsi. Entrambe le categorie richiedono governance, gestione del rischio, segnalazione degli incidenti, sicurezza dei fornitori ed evidenze.

Le entità finanziarie devono considerare anche DORA. NIS2 Article 4 riconosce che, quando un atto giuridico dell’Unione specifico di settore impone obblighi almeno equivalenti di gestione del rischio di cibersicurezza e di segnalazione degli incidenti, tali norme settoriali si applicano alle aree corrispondenti. DORA si applica dal 17 gennaio 2025 e disciplina la gestione del rischio ICT, la segnalazione degli incidenti rilevanti connessi all’ICT, i test di resilienza operativa digitale, la condivisione delle informazioni, la gestione del rischio di terze parti ICT, i controlli contrattuali e la vigilanza sui fornitori critici terzi di servizi ICT. Per le entità finanziarie soggette a DORA, DORA è il principale quadro di riferimento per la resilienza cibernetica per i requisiti sovrapposti, ma le interfacce NIS2 e il coordinamento con le autorità nazionali possono comunque rilevare.

La lezione è semplice. Non aspettare il campo del portale o l’e-mail del regolatore prima di costruire le evidenze. Ogni risposta di registrazione implica una futura domanda di audit.

Parti dall’ambito del SGSI, non dal modulo del portale

ISO 27001:2022 è utile perché obbliga l’organizzazione a definire contesto, parti interessate, obblighi normativi, ambito di applicazione, rischi, piani di trattamento del rischio, funzionamento dei controlli, monitoraggio, audit interno, riesame della direzione e miglioramento.

Le clausole 4.1-4.4 richiedono all’organizzazione di determinare i fattori interni ed esterni, identificare le parti interessate e i relativi requisiti, decidere quali requisiti sono gestiti tramite il SGSI, definire l’ambito del SGSI considerando interfacce e dipendenze, documentare tale ambito e gestire i processi del SGSI.

Per NIS2, tale ambito deve rispondere a domande operative:

• Quali servizi UE, persone giuridiche, controllate, piattaforme, componenti infrastrutturali e unità aziendali sono rilevanti?
• Quale categoria dell’Allegato I o dell’Allegato II potrebbe applicarsi?
• L’organizzazione è essenziale, importante, soggetta a DORA, fuori ambito o in attesa di classificazione nazionale?
• Quali servizi sono critici per i clienti, la sicurezza pubblica, la stabilità finanziaria, la sanità, l’infrastruttura digitale o altri settori regolamentati?
• Quali fornitori cloud, MSP, MSSP, data center, subappaltatori e altri fornitori supportano tali servizi?
• Quali Stati membri, autorità competenti, CSIRT, autorità di controllo per la protezione dei dati e autorità di vigilanza finanziaria possono essere rilevanti?

Il Zenith Blueprint: roadmap in 30 passaggi per l’auditor Zenith Blueprint di Clarysec colloca questo lavoro nelle fasi iniziali, al passaggio 2, esigenze degli stakeholder e ambito del SGSI. Indica alle organizzazioni di identificare regolatori e autorità, esaminare i requisiti legali e normativi, riesaminare contratti e accordi, condurre interviste con gli stakeholder e considerare gli standard di settore attesi.

Azione 4.2: Compila un elenco di tutte le parti interessate significative e annota i loro requisiti relativi alla sicurezza delle informazioni. Sii accurato: considera chiunque potrebbe presentare reclami o subire conseguenze se la tua sicurezza fallisse o se mancasse un determinato controllo. Questo elenco guiderà ciò a cui devi conformarti o soddisfare tramite il tuo SGSI e confluirà nella valutazione del rischio e nella selezione dei controlli.

Questo è il punto di partenza corretto per la registrazione NIS2. Prima della presentazione, crea una breve nota sull’ambito NIS2 che colleghi il modello operativo alle categorie dell’Allegato I o dell’Allegato II, documenti le ipotesi su dimensioni e servizi, registri l’interpretazione della normativa nazionale, identifichi le autorità competenti e indichi se si applicano anche DORA, GDPR, contratti con i clienti o norme settoriali.

La Politica di conformità legale e normativa per PMI di Clarysec Legal and Regulatory Compliance Policy - SME definisce chiaramente la finalità:

“Questa politica definisce l’approccio dell’organizzazione per identificare, soddisfare e dimostrare la conformità agli obblighi legali, normativi e contrattuali.”

Per i programmi più ampi, la Politica di conformità legale e normativa di Clarysec Legal and Regulatory Compliance Policy è ancora più esplicita:

“Tutti gli obblighi legali e normativi devono essere mappati su politiche, controlli e responsabili specifici all’interno del Sistema di gestione della sicurezza delle informazioni (SGSI).”

Questa frase è il fondamento della preparazione all’applicazione normativa. Se un regolatore chiede come sono stati identificati gli obblighi NIS2, la risposta non deve essere “ce lo ha indicato il legale”. La risposta deve essere un registro documentato, collegato ad ambito, rischi, responsabili dei controlli, procedure, evidenze conservate e riesame della direzione.

Costruisci la catena di evidenze NIS2 dentro ISO 27001:2022

NIS2 Article 21 richiede alle entità essenziali e importanti di attuare misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi per i sistemi informativi e di rete utilizzati per le operazioni o l’erogazione dei servizi. Le misure devono tenere conto dello stato dell’arte, degli standard europei e internazionali pertinenti ove applicabili, dei costi, dell’esposizione al rischio, delle dimensioni, della probabilità e gravità degli incidenti e dell’impatto sociale ed economico.

Article 21(2) elenca aree minime, tra cui analisi dei rischi e politiche di sicurezza dei sistemi informativi, gestione degli incidenti, continuità operativa, backup, Disaster Recovery, gestione delle crisi, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, gestione delle vulnerabilità, valutazione dell’efficacia, igiene cibernetica, formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset, autenticazione a più fattori o autenticazione continua e comunicazioni sicure ove opportuno.

ISO 27001:2022 si mappa naturalmente su questa struttura. Le clausole 6.1.1-6.1.3 richiedono valutazione del rischio e trattamento del rischio, inclusi criteri di accettazione del rischio, responsabili del rischio, analisi di probabilità e conseguenze, un Piano di trattamento del rischio, confronto con i controlli dell’Annex A e una Dichiarazione di Applicabilità. La clausola 8 richiede pianificazione e controllo operativi, evidenze che i processi abbiano operato come pianificato, controllo delle modifiche, controllo dei processi forniti dall’esterno, valutazioni del rischio ricorrenti e risultati documentati del trattamento. La clausola 9.1 richiede monitoraggio, misurazione, analisi e valutazione. La clausola 9.2 richiede audit interno. La clausola 10.2 richiede azioni sulle non conformità e azioni correttive.

La Politica di gestione del rischio di Clarysec Risk Management Policy - SME trasforma questo principio in una regola operativa:

“Tutti i rischi identificati devono essere registrati nel Registro dei rischi.”

La Politica di gestione del rischio enterprise Risk Management Policy collega il trattamento del rischio alla selezione dei controlli ISO 27001:2022:

“Le decisioni sui controlli derivanti dal processo di trattamento del rischio devono essere riflesse nella SoA.”

Questo è importante perché le evidenze NIS2 devono essere tracciabili. Se un’autorità chiede perché esiste un controllo, occorre indicare obbligo, rischio, decisione di trattamento, responsabile del controllo, voce della SoA, procedura ed evidenza. Se l’autorità chiede perché un controllo non è stato selezionato, occorre indicare la giustificazione nella SoA, l’accettazione del rischio approvata e il riesame della direzione.

La migliore catena di evidenze è noiosa nel senso migliore del termine. Ogni obbligo ha un responsabile. Ogni responsabile ha un controllo. Ogni controllo ha evidenze. Ogni eccezione ha un’approvazione. Ogni rilievo di audit ha un’azione correttiva.

Porta la governance dell’Article 20 nelle evidenze del consiglio di amministrazione

NIS2 Article 20 porta la cibersicurezza nella sala del consiglio. Gli organi di gestione devono approvare le misure di gestione del rischio di cibersicurezza adottate ai fini dell’Article 21, vigilare sulla loro attuazione e possono essere ritenuti responsabili delle violazioni. I membri degli organi di gestione devono seguire una formazione e le entità sono incoraggiate a fornire regolarmente formazione sulla cibersicurezza ai dipendenti.

Un consiglio di amministrazione non può limitarsi a delegare NIS2 all’IT. Le evidenze devono mostrare che la direzione ha compreso l’analisi dell’ambito NIS2, approvato l’approccio di gestione del rischio, riesaminato i rischi significativi, allocato le risorse, monitorato l’attuazione, riesaminato incidenti ed esercitazioni e ricevuto formazione.

Le clausole 5.1-5.3 di ISO 27001:2022 supportano questo modello di governance richiedendo l’impegno dell’alta direzione, l’allineamento degli obiettivi di sicurezza delle informazioni alla strategia aziendale, l’integrazione dei requisiti del SGSI nei processi aziendali, risorse, comunicazione, responsabilità e rendicontazione delle prestazioni del SGSI all’alta direzione.

La Politica sui ruoli e sulle responsabilità di governance di Clarysec Governance Roles and Responsibilities Policy definisce il ruolo di collegamento per la sicurezza come un ruolo che:

“Funge da referente principale con auditor, regolatori e alta direzione per le questioni relative alla sicurezza delle informazioni.”

Questo ruolo deve essere indicato nominalmente nel pacchetto di evidenze di registrazione NIS2. Non deve restare implicito. Autorità, auditor e clienti vogliono sapere chi coordina il contatto regolatorio, chi è responsabile della segnalazione degli incidenti, chi mantiene il registro normativo, chi aggiorna i contatti delle autorità e chi riferisce al consiglio di amministrazione.

Un set pratico di evidenze di governance include:

• Approvazione da parte del consiglio di amministrazione del quadro di riferimento per la gestione del rischio di cibersicurezza.
• Verbali del riesame della direzione relativi ad ambito NIS2, rischi, incidenti, fornitori e preparazione.
• Registrazioni della formazione per i membri degli organi di gestione e i dipendenti.
• Una matrice RACI per obblighi NIS2, controlli ISO 27001:2022, segnalazione degli incidenti, assurance sui fornitori e comunicazione regolatoria.
• Evidenze che gli obblighi NIS2 sono inclusi nell’audit interno e nel monitoraggio della conformità.
• Tracciamento delle azioni correttive per lacune, rischi scaduti, eccezioni e test non riusciti.

Anche gli Articles 32 e 33 rendono importante la qualità delle evidenze, individuando fattori di violazione grave quali violazioni ripetute, mancata notifica o mancato rimedio di incidenti significativi, mancato trattamento delle carenze dopo istruzioni vincolanti, ostacolo ad audit o monitoraggio e informazioni false o gravemente inesatte. Evidenze deboli possono diventare un problema di enforcement anche quando i controlli tecnici esistono.

Prepara le evidenze sui contatti con le autorità e sulla segnalazione degli incidenti prima delle 02:00

I fallimenti più dolorosi nella segnalazione degli incidenti spesso iniziano con una domanda elementare: “Chi dobbiamo notificare?”. Durante un ransomware, un guasto DNS, una compromissione cloud o un’esposizione dei dati, i team perdono tempo a cercare il CSIRT corretto, l’autorità competente, l’autorità di controllo per la protezione dei dati, l’autorità di vigilanza finanziaria, il canale delle forze dell’ordine, il modello per i clienti e l’approvatore interno.

NIS2 Article 23 richiede la notifica senza indebito ritardo degli incidenti significativi che incidono sulla fornitura dei servizi. Un incidente significativo è un incidente che ha causato o potrebbe causare una grave interruzione operativa o una perdita finanziaria, oppure ha colpito o potrebbe colpire altri causando un considerevole danno materiale o immateriale. La tempistica è articolata: preallarme entro 24 ore dal momento in cui si viene a conoscenza dell’incidente, notifica dell’incidente entro 72 ore, aggiornamenti intermedi su richiesta e una relazione finale entro un mese dalla notifica delle 72 ore o, per gli incidenti in corso, dopo la gestione dell’incidente. Ove opportuno, anche i destinatari dei servizi devono essere informati degli incidenti significativi o delle minacce informatiche significative e delle misure di protezione.

Zenith Blueprint, fase Controls in Action, passaggio 22, tratta il contatto con le autorità come preparazione, non come panico:

Il principio è semplice: se la tua organizzazione fosse bersaglio di un attacco informatico, coinvolta in una violazione dei dati o sottoposta a indagine, chi chiamerebbe le autorità? Come saprebbe cosa dire? A quali condizioni verrebbe avviato tale contatto? Queste domande devono ricevere risposta in anticipo, non a posteriori.

Zenith Controls: guida alla cross-compliance Zenith Controls di Clarysec copre il controllo ISO/IEC 27002:2022 5.5, contatto con le autorità. Classifica il controllo come preventivo e correttivo, collegato a Riservatezza, Integrità e Disponibilità e connesso ai concetti Identify, Protect, Respond e Recover. Collega inoltre il controllo 5.5 ai controlli ISO/IEC 27002:2022 5.24 pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, 6.8 segnalazione degli eventi di sicurezza delle informazioni, 5.7 informazioni sulle minacce, 5.6 contatto con gruppi di interesse speciali e 5.26 risposta agli incidenti di sicurezza delle informazioni.

In ottica di cross-compliance, Zenith Controls mappa il contatto con le autorità su NIS2 Article 23, notifica delle violazioni GDPR, segnalazione degli incidenti DORA, NIST SP 800-53 IR-6 Incident Reporting e pratiche di escalation esterna COBIT 2019. Un unico registro dei contatti delle autorità può soddisfare più obblighi se è progettato correttamente.

La Politica di risposta agli incidenti di Clarysec Incident Response Policy - SME rende esplicito il triage legale:

“Quando sono coinvolti dati dei clienti, il direttore generale deve valutare gli obblighi legali di notifica in base all’applicabilità di GDPR, NIS2 o DORA.”

Un solido pacchetto di evidenze sui contatti con le autorità deve includere:

• Recapiti dell’autorità competente e del CSIRT per Stato membro e servizio.
• Contatti dell’autorità di controllo per la notifica delle violazioni dei dati personali ai sensi del GDPR.
• Contatti delle autorità di vigilanza finanziaria se si applica DORA.
• Canali di contatto con forze dell’ordine e unità cybercrime.
• Comunicatori interni autorizzati e sostituti.
• Soglie di incidente per NIS2, GDPR, DORA, contratti con i clienti e assicurazione cyber.
• Modelli di preallarme a 24 ore, notifica a 72 ore, aggiornamento intermedio e relazione finale a un mese.
• Registrazioni di esercitazioni tabletop che testano la notifica esterna.
• Registrazioni delle notifiche precedenti, delle decisioni di non notificare e del razionale legale.

Mappa NIS2 Article 21 sui controlli ISO 27001 e sulle evidenze di policy

Un certificato da solo non risponde alla domanda di un regolatore. Una mappatura dei controlli sì. La tabella seguente offre ai team di sicurezza e conformità un ponte pratico tra le aree di NIS2 Article 21, i controlli ISO/IEC 27002:2022, i riferimenti alle policy Clarysec e le evidenze.

Zenith Controls di Clarysec copre inoltre il controllo ISO/IEC 27002:2022 5.31, requisiti legali, statutari, normativi e contrattuali, come controllo preventivo con impatto su Riservatezza, Integrità e Disponibilità. Collega 5.31 alla privacy e protezione dei dati personali identificabili, alla conservazione delle registrazioni, al riesame indipendente e alla conformità alle politiche interne. Mappa inoltre 5.31 sulla responsabilizzazione GDPR, sulla conformità NIS2 della catena di fornitura, sulla gestione del rischio ICT DORA, sulla governance NIST CSF, sui controlli di programma NIST SP 800-53 e sulla vigilanza della conformità esterna COBIT 2019.

“Il controllo 5.31 assicura che tutti i requisiti legali, normativi, statutari e contrattuali rilevanti relativi alla sicurezza delle informazioni siano identificati, documentati e gestiti in modo continuativo.”

È esattamente ciò che un’autorità nazionale vuole vedere dopo la registrazione: non solo che NIS2 sia elencata, ma che l’organizzazione disponga di un meccanismo vivo per identificare, mappare, attuare, monitorare e aggiornare gli obblighi.

Non separare NIS2 da DORA, GDPR, fornitori e cloud

Le evidenze NIS2 raramente esistono in isolamento.

NIS2 Article 21(2)(d) richiede la sicurezza della catena di fornitura, inclusi gli aspetti di sicurezza dei rapporti con fornitori e prestatori di servizi. Article 21(3) richiede che le decisioni sui rischi dei fornitori considerino vulnerabilità, qualità complessiva dei prodotti, pratiche di cibersicurezza, procedure di sviluppo sicuro e pertinenti valutazioni coordinate dell’UE sui rischi della catena di fornitura.

ISO 27001:2022 Annex A fornisce il ponte operativo tramite A.5.19-A.5.23. Per le organizzazioni SaaS e cloud, questi controlli spesso determinano se le evidenze di registrazione sono superficiali o sostenibili.

DORA rende più stringente il quadro dei fornitori per le entità finanziarie. Gli Articles 28-30 richiedono la gestione del rischio di terze parti ICT, un registro dei contratti di servizi ICT, la distinzione dei servizi a supporto di funzioni critiche o importanti, la valutazione del rischio precontrattuale, la due diligence, requisiti contrattuali di sicurezza, diritti di audit e ispezione, diritti di risoluzione, strategie di uscita testate, valutazione del subappalto, trasparenza sulla localizzazione dei dati, assistenza sugli incidenti, cooperazione con le autorità e disposizioni di transizione. Se un fornitore SaaS serve clienti regolamentati DORA, i suoi contratti e il suo pacchetto di assurance possono essere esaminati anche se non è esso stesso l’entità finanziaria.

La Politica di sicurezza di terze parti e fornitori - SME di Clarysec Third-party and supplier security policy - SME deve quindi essere collegata al pacchetto di evidenze NIS2. La preparazione sui fornitori deve includere:

• Inventario dei fornitori e classificazione della criticità.
• Due diligence sui fornitori e valutazioni del rischio.
• Clausole contrattuali su sicurezza, assistenza sugli incidenti, diritto di audit, localizzazione dei dati, subappalto e uscita.
• Matrici di responsabilità condivisa cloud.
• Registrazioni di monitoraggio per i fornitori critici.
• Test di uscita e ripristino per i servizi critici.
• Procedure di notifica ed escalation degli incidenti dei fornitori.

Anche GDPR deve essere integrato. Un incidente significativo NIS2 può essere anche una violazione dei dati personali se sono compromessi dati di clienti, dipendenti o utenti. GDPR richiede ai titolari del trattamento di dimostrare l’accountability e, quando le soglie di notifica sono soddisfatte, notificare l’autorità di controllo entro 72 ore dal momento in cui vengono a conoscenza di una violazione dei dati personali. Il workflow di risposta agli incidenti deve valutare in parallelo gli obblighi NIS2, GDPR, DORA, contrattuali e verso i clienti.

Assembla un pacchetto di evidenze NIS2 in una settimana

Un fornitore SaaS, MSP, MSSP, cloud provider o un’azienda di infrastrutture digitali può fare progressi sostanziali in una settimana di lavoro mirata.

Giorno 1, classifica l’entità e i servizi. Usa la dichiarazione dell’ambito del SGSI e il registro delle parti interessate. Aggiungi una nota sull’ambito NIS2 che identifichi le categorie dell’Allegato I o dell’Allegato II, i servizi UE, gli Stati membri, i clienti, le dipendenze, le ipotesi dimensionali e l’eventuale applicazione di DORA o di norme settoriali. Registra l’incertezza di classificazione come rischio se l’interpretazione legale non è definitiva.

Giorno 2, aggiorna il registro degli obblighi legali e normativi. Aggiungi NIS2 Articles 20, 21 e 23, i requisiti di registrazione previsti dalla normativa nazionale, gli obblighi di notifica delle violazioni GDPR, gli obblighi DORA ove rilevanti e i principali requisiti contrattuali di notifica. Mappa ogni obbligo su una politica, un responsabile, un controllo, una fonte di evidenza e una frequenza di riesame.

Giorno 3, aggiorna la valutazione del rischio e il trattamento. Includi nei criteri di rischio l’impatto legale, normativo, operativo, sui fornitori, finanziario, reputazionale e sociale. Aggiungi rischi quali mancata registrazione, classificazione errata dell’entità, mancato preallarme entro 24 ore, indisponibilità dei contatti delle autorità, indisponibilità di un fornitore che incide su servizi critici, vigilanza insufficiente del consiglio di amministrazione e incapacità di dimostrare l’efficacia dei controlli.

Giorno 4, aggiorna la SoA. Conferma i controlli rilevanti per NIS2, inclusi A.5.5 contatto con le autorità, A.5.19-A.5.23 controlli su fornitori e cloud, A.5.24-A.5.28 controlli sugli incidenti, A.5.29 sicurezza durante le interruzioni, A.5.30 prontezza ICT per la continuità operativa, A.5.31 requisiti legali, A.5.34 privacy, A.8.8 gestione delle vulnerabilità, A.8.13 backup, A.8.15 registrazione, A.8.16 attività di monitoraggio, A.8.24 crittografia e controlli di sviluppo sicuro A.8.25-A.8.32.

Giorno 5, testa la segnalazione degli incidenti. Esegui un’esercitazione tabletop: una configurazione errata cloud espone dati dei clienti e interrompe il servizio in due Stati membri. Fai partire il cronometro. Il team riesce a classificare l’evento, valutare le soglie GDPR, NIS2, DORA, contrattuali e verso i clienti, preparare un preallarme entro 24 ore, redigere una notifica entro 72 ore, preservare le evidenze e assegnare l’analisi della causa radice?

Giorno 6, raccogli le evidenze. Crea una cartella pronta per l’autorità competente con la nota sull’ambito, il registro normativo, il Registro dei rischi, la SoA, l’elenco dei contatti delle autorità, il playbook sugli incidenti, il Registro dei fornitori, i verbali del consiglio di amministrazione, le registrazioni della formazione, i log, i report di monitoraggio, i test dei backup, i report di vulnerabilità, l’ambito dell’audit interno e il registro delle azioni correttive.

Giorno 7, riesame della direzione. Presenta il pacchetto di preparazione alla leadership. Registra approvazioni, rischi residui, azioni aperte, scadenze, risorse e responsabilità dei responsabili. Se la registrazione è imminente, allega l’indice delle evidenze alla registrazione della decisione di registrazione.

La Politica di audit e monitoraggio della conformità per PMI di Clarysec Audit and Compliance Monitoring Policy-sme - SME anticipa questa esigenza:

“Le evidenze devono essere allineate agli obblighi NIS2 quando l’organizzazione è designata come entità importante o comunque rientra nell’ambito di applicazione della normativa nazionale”

La Politica di audit e monitoraggio della conformità enterprise Audit and Compliance Monitoring Policy definisce l’obiettivo:

“Generare evidenze sostenibili e una traccia di audit a supporto di richieste regolatorie, procedimenti legali o richieste di assurance dei clienti.”

Questo è l’obiettivo: evidenze sostenibili prima che arrivi la richiesta.

Preparati a diverse prospettive di audit

Un auditor di certificazione, un’autorità nazionale, un auditor del cliente, un auditor privacy e un team di assurance sui fornitori non porranno domande identiche. Un solido pacchetto di evidenze NIS2 funziona per tutti.

Per il controllo ISO/IEC 27002:2022 5.5, gli auditor si aspettano comunemente contatti documentati con le autorità, responsabilità assegnate, manutenzione dei contatti, playbook di risposta agli incidenti e chiarezza basata su scenari. Una semplice domanda di audit può rivelare la maturità: “In caso di ransomware, chi contatta le forze dell’ordine o il CSIRT nazionale?”. Se la risposta dipende dal ricordo di un nome da parte di qualcuno, il controllo non è pronto.

La Politica di registrazione e monitoraggio di Clarysec Logging and Monitoring Policy - SME rafforza l’aspettativa sulle evidenze:

“I log devono essere disponibili e comprensibili per auditor esterni o regolatori su richiesta”

La Politica per la sicurezza delle informazioni di Clarysec Information Security Policy stabilisce lo standard enterprise più ampio:

“Tutti i controlli implementati devono essere verificabili, supportati da procedure documentate ed evidenze conservate del loro funzionamento.”

Questo è il test di audit in una frase. Se un controllo non può essere evidenziato, avrà poco peso quando un’autorità competente chiederà una prova.

Checklist finale delle evidenze di registrazione NIS2

Usa questa checklist prima della registrazione o prima di rispondere a una richiesta di un’autorità nazionale.

• Documenta l’analisi dell’ambito NIS2, inclusi il razionale dell’Allegato I o dell’Allegato II, le descrizioni dei servizi, le ipotesi dimensionali, la presenza negli Stati membri e la classificazione dell’entità.
• Identifica se DORA si applica direttamente oppure indirettamente tramite clienti del settore finanziario e contratti di servizi ICT.
• Aggiorna l’ambito del SGSI per includere servizi rilevanti, dipendenze, processi esternalizzati e interfacce regolatorie.
• Aggiungi NIS2, GDPR, DORA, norme settoriali e requisiti contrattuali al registro degli obblighi legali e normativi.
• Mappa ogni obbligo su politiche, controlli, responsabili, evidenze, frequenza di riesame e reporting alla direzione.
• Conferma approvazione e vigilanza del consiglio di amministrazione sulle misure di gestione del rischio di cibersicurezza.
• Mantieni le registrazioni della formazione sulla cibersicurezza per direzione e dipendenti.
• Aggiorna i criteri di rischio per includere impatto regolatorio, interruzione del servizio, danno ai clienti, impatto transfrontaliero e dipendenza dai fornitori.
• Registra i rischi connessi a NIS2 nel Registro dei rischi e collegali ai piani di trattamento del rischio.
• Aggiorna la SoA con i controlli dell’Annex A rilevanti per NIS2 e lo stato di attuazione.
• Mantieni elenchi dei contatti delle autorità e procedure di notifica per CSIRT, autorità competenti, autorità di controllo per la protezione dei dati, autorità di vigilanza finanziaria e forze dell’ordine.
• Testa il workflow di preallarme a 24 ore, notifica a 72 ore, aggiornamento intermedio e relazione finale a un mese.
• Mantieni le evidenze su fornitori e cloud, inclusi due diligence, contratti, diritto di audit, monitoraggio, subappalto e piani di uscita.
• Dimostra l’efficacia dei controlli tramite log, metriche, audit, dashboard, risultati dei test e azioni correttive.
• Prepara un indice delle evidenze affinché qualsiasi richiesta di regolatori, clienti o auditor possa ricevere risposta rapidamente.

Il prossimo passo con Clarysec

La registrazione dell’entità NIS2 non è il traguardo. È il punto in cui la tua organizzazione diventa visibile alla vigilanza nazionale sulla cibersicurezza. La domanda corretta non è “Possiamo registrarci?”. La domanda corretta è “Se l’autorità chiede evidenze dopo la registrazione, possiamo produrre una narrazione ISO 27001:2022 coerente in ore, non in settimane?”.

Clarysec aiuta le organizzazioni a costruire questa narrazione tramite Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls e set pratici di politiche ISO 27001:2022 che collegano obblighi legali, trattamento del rischio, segnalazione degli incidenti, sicurezza dei fornitori, registrazione, monitoraggio, evidenze dell’audit e responsabilità della direzione.

Esegui una gap analysis delle evidenze NIS2 rispetto al tuo SGSI attuale. Parti dalla nota sull’ambito, dal registro normativo, dal Registro dei rischi, dalla SoA, dall’elenco dei contatti delle autorità, dal workflow di segnalazione degli incidenti, dal Registro dei fornitori e dalla cartella delle evidenze dell’audit. Se questi artefatti sono incompleti o scollegati, Clarysec può aiutarti a trasformarli in un pacchetto di evidenze pronto per l’autorità competente prima che la tua autorità nazionale lo richieda.