Mappatura tra NIS2 2024/2690 e ISO 27001 per fornitori cloud

Alle 08:17 di un martedì, Maria, CISO di un fornitore europeo di servizi gestiti, riceve l’allarme che ogni MSP teme. Un account privilegiato di gestione remota ha generato alert di impossible travel. Due tenant di clienti mostrano attività amministrative anomale. Il SOC ha già aperto un canale di coordinamento per un incidente critico.

Alle 09:00, l’amministratore delegato si collega alla chiamata. Le domande cambiano immediatamente.

Rientriamo nel campo di applicazione di NIS2? Il Regolamento di esecuzione (UE) 2024/2690 della Commissione si applica alla nostra organizzazione? Serve un preallarme entro 24 ore? Quali clienti devono essere notificati? Possiamo dimostrare che MFA, logging, segmentazione, gestione delle vulnerabilità, controlli sui fornitori ed escalation degli incidenti erano operativi prima dell’incidente?

L’azienda di Maria è certificata ISO/IEC 27001:2022. Fornisce gestione cloud, servizi di data center e supporto per servizi di sicurezza gestiti a clienti che includono un fornitore logistico e una banca regionale. Il certificato è rilevante, ma da solo non risponde alle domande operative. Il team legale dispone di una bozza del processo di notifica. Il responsabile della compliance ha un foglio di calcolo. L’auditor ha richiesto la Dichiarazione di Applicabilità, i test di risposta agli incidenti, i log degli accessi privilegiati, la due diligence sui fornitori, le evidenze del modello di responsabilità condivisa cloud e le assunzioni di continuità operativa.

È il momento in cui NIS2 smette di essere un testo giuridico e diventa un problema di controllo operativo.

Per i fornitori di servizi di cloud computing, i fornitori di servizi gestiti, i fornitori di servizi di sicurezza gestiti e i fornitori di data center, NIS2 e il Regolamento di esecuzione 2024/2690 innalzano l’asticella: dall’intenzione generale di sicurezza alle evidenze di controllo verificabili. Governance, gestione del rischio, controllo degli accessi, gestione degli asset, gestione delle vulnerabilità, risposta agli incidenti, sicurezza dei fornitori, logging, monitoraggio, cifratura, continuità operativa e resilienza fisica devono funzionare come un unico sistema.

ISO/IEC 27001:2022 è la migliore struttura portante per tale sistema, ma solo se l’organizzazione mappa i requisiti NIS2 nel SGSI, nel registro dei rischi, nella Dichiarazione di Applicabilità, nelle politiche e nel modello delle evidenze. Un certificato appeso alla parete non basta. Il lavoro reale consiste nel costruire un filo conduttore verificabile in audit: dalla normativa al rischio, dal rischio al controllo, dal controllo alla politica e dalla politica all’evidenza operativa.

Perché NIS2 2024/2690 cambia il confronto sulla conformità per cloud e MSP

NIS2 utilizza un modello basato su settore e dimensione, ma le categorie relative all’infrastruttura digitale e alla gestione dei servizi ICT sono volutamente ampie. Ai sensi di NIS2 Article 2 e Article 3, letti insieme ad Annex I e Annex II, molte organizzazioni possono essere classificate come soggetti essenziali o importanti, inclusi fornitori di servizi di cloud computing, fornitori di servizi di data center, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, provider DNS, registri TLD, reti di distribuzione dei contenuti e prestatori di servizi fiduciari. Gli Stati membri devono istituire e riesaminare periodicamente gli elenchi dei soggetti essenziali e importanti, con la prima scadenza fissata al 17 aprile 2025.

Questo è rilevante perché i fornitori cloud, MSP, MSSP e data center sono inseriti nelle catene del rischio di altre organizzazioni. La compromissione del control plane cloud può interessare migliaia di sistemi dei clienti. Un’interruzione di un data center può propagarsi a banche, sanità, logistica e pubblica amministrazione. Una violazione delle credenziali di un MSP può trasformarsi in un evento ransomware multi-cliente. Un mancato rilevamento da parte di un MSSP può ritardare il contenimento presso clienti regolamentati.

NIS2 Article 20 richiede agli organi di gestione di approvare le misure di gestione del rischio di cibersicurezza e di supervisionarne l’attuazione. Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, basate su un approccio multirischio. La baseline include analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, gestione e divulgazione delle vulnerabilità, valutazione dell’efficacia, igiene informatica, formazione, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset, MFA o autenticazione continua, comunicazioni protette e comunicazioni di emergenza.

Article 23 aggiunge la segnalazione progressiva degli incidenti significativi, compreso un preallarme entro 24 ore, una notifica dell’incidente entro 72 ore, relazioni intermedie su richiesta e una relazione finale entro un mese dalla notifica o dalla gestione dell’incidente quando l’incidente è ancora in corso.

Il Regolamento di esecuzione 2024/2690 rende queste aspettative più concrete per i fornitori digitali interessati. In pratica, autorità, clienti e auditor non chiederanno solo se esistono politiche. Chiederanno se i controlli sono mappati, assegnati a un titolare, testati e supportati da evidenze.

ISO/IEC 27001:2022 trasforma NIS2 nel contesto operativo del SGSI

Un errore comune nella preparazione a NIS2 consiste nel partire da una grande checklist e assegnare attività tra IT, legale, SOC, infrastruttura, gestione dei fornitori e compliance. Questo può generare attività, ma spesso non regge in sede di audit, perché nessuno è in grado di mostrare perché i controlli sono stati selezionati, come si collegano al rischio, chi ha accettato il rischio residuo e quali evidenze ne dimostrano l’efficacia.

ISO/IEC 27001:2022 fornisce ai fornitori la struttura per evitare questo fallimento.

Le clausole 4.1-4.4 richiedono all’organizzazione di determinare le questioni interne ed esterne, identificare le parti interessate e i relativi requisiti, decidere quali requisiti saranno gestiti attraverso il SGSI e definire il campo di applicazione del SGSI, incluse interfacce e dipendenze. Per un fornitore cloud o MSP, il campo di applicazione deve considerare esplicitamente NIS2, il Regolamento di esecuzione 2024/2690, gli allegati di sicurezza dei clienti, i requisiti dei clienti derivanti da DORA, le regioni cloud, i subappaltatori, le dipendenze dai data center, le piattaforme di gestione remota, i percorsi di accesso privilegiato e gli obblighi di notifica degli incidenti.

Le clausole 5.1-5.3 richiedono leadership, allineamento delle politiche, risorse, comunicazione, responsabilità assegnate e accountability della direzione. Ciò supporta direttamente NIS2 Article 20.

Le clausole 6.1.1-6.1.3 richiedono valutazione del rischio, trattamento del rischio, titolari del rischio, analisi di probabilità e conseguenze, selezione dei controlli, confronto con Annex A, una Dichiarazione di Applicabilità, un Piano di trattamento del rischio e accettazione formale del rischio residuo. È qui che NIS2 diventa operativa. Ogni requisito normativo diventa un driver di rischio, un obbligo di conformità, un requisito di controllo o un requisito di evidenza.

Clarysec avvia questo lavoro con Zenith Blueprint: roadmap in 30 passi per auditor Zenith Blueprint, in particolare nella fase di gestione del rischio.

Dal passaggio 13, Pianificazione del trattamento del rischio e Dichiarazione di Applicabilità, Zenith Blueprint indica ai team di costruire la tracciabilità tra rischi, controlli e driver normativi:

“Riferimenti incrociati alle normative: se alcuni controlli sono attuati specificamente per conformarsi a GDPR, NIS2 o DORA, è possibile annotarlo nel Registro dei rischi o nelle note della SoA. Ad esempio, il controllo 8.27 (cancellazione sicura dei dati) può essere molto rilevante per il requisito GDPR relativo allo smaltimento dei dati personali; si potrebbe annotare ‘Applicabile – supporta GDPR Art.32 (sicurezza del trattamento)’. Non è richiesto da ISO, ma aiuta a dimostrare che tali quadri di riferimento sono stati considerati.”

Il passaggio 14, Politiche di trattamento del rischio e riferimenti incrociati normativi, aggiunge la disciplina pratica della mappatura:

“Per ciascuna normativa, se applicabile, è possibile creare una semplice tabella di mappatura che elenchi i principali requisiti di sicurezza della normativa e i controlli/le politiche corrispondenti nel vostro SGSI. Non è obbligatorio in ISO 27001, ma è un esercizio interno utile per assicurarsi che nulla sia stato trascurato.”

Questa è la differenza tra dire “siamo certificati ISO” e dimostrare “il nostro SGSI ISO/IEC 27001:2022 copre il Regolamento di esecuzione NIS2 2024/2690”.

Mappatura unificata dei controlli NIS2 verso ISO/IEC 27001:2022

La seguente mappatura non costituisce consulenza legale né sostituisce l’analisi del recepimento nazionale. È un’architettura pratica dei controlli per i fornitori che necessitano di un percorso ISO/IEC 27001:2022 verificabile verso la preparazione a NIS2.

Questa mappatura diventa efficace quando viene incorporata nel registro dei rischi e nella Dichiarazione di Applicabilità. Ad esempio, un fornitore può creare uno scenario di rischio denominato “La compromissione della piattaforma di gestione remota comporta azioni non autorizzate negli ambienti dei clienti”. I controlli includono MFA, gestione degli accessi privilegiati, segmentazione, logging, gestione delle vulnerabilità, sicurezza dei fornitori, pianificazione degli incidenti e procedure di notifica ai clienti. Le note della SoA possono fare riferimento a NIS2 Article 21, Article 23, al Regolamento di esecuzione 2024/2690, ai contratti con i clienti e ai requisiti di due diligence dei clienti derivanti da DORA, ove pertinenti.

Governance cloud: il controllo ISO 5.23 è un’ancora NIS2

Per i fornitori cloud e gli MSP che utilizzano servizi cloud per erogare servizi ai clienti, il controllo 5.23 di Annex A di ISO/IEC 27001:2022, Sicurezza delle informazioni per l’uso dei servizi cloud, è una delle ancore più importanti.

Zenith Controls: guida alla conformità incrociata Zenith Controls sintetizza il controllo 5.23 come un controllo preventivo a supporto di riservatezza, integrità e disponibilità, collegato alla sicurezza dei rapporti con i fornitori, alla governance, al rischio dell’ecosistema e alla protezione. Copre governance dei servizi cloud, responsabilità condivisa, valutazione del provider, inventari, localizzazione dei dati, logging, cifratura, ruoli di identità, monitoraggio, clausole contrattuali, rischio dei fornitori, uscita dal cloud e pianificazione della resilienza.

Zenith Blueprint, nella fase Controlli in azione, passaggio 23, spiega la ragione pratica:

“Il cloud non è più una destinazione, è l’opzione predefinita. Il controllo 5.23 riconosce questa realtà e richiede che la sicurezza delle informazioni sia trattata esplicitamente nella selezione, nell’uso e nella gestione dei servizi cloud, non come un ripensamento, ma come principio di progettazione fin dall’inizio.”

Per un MSP, ogni piattaforma di monitoraggio e gestione remota, portale cliente, strumento di ticketing, piattaforma di telemetria di sicurezza, servizio di backup, directory cloud e console amministrativa SaaS deve essere governata. Per un fornitore di data center, la governance cloud può applicarsi a piattaforme di monitoraggio, sistemi di gestione dei visitatori, integrazioni del controllo degli accessi fisici, sistemi di gestione remota e infrastruttura del portale clienti.

La Politica di utilizzo del cloud Enterprise di Clarysec Politica di utilizzo del cloud rende obbligatoria la due diligence prima dell’attivazione:

“Tutto l’uso del cloud deve essere sottoposto a due diligence basata sul rischio prima dell’attivazione, inclusi valutazione del provider, validazione della conformità legale e riesami di convalida dei controlli.”

Dalla sezione “Requisiti di governance”, clausola 5.2 della politica.

Per i fornitori più piccoli, la Cloud Usage Policy-sme Cloud Usage Policy-sme - PMI crea un modello di approvazione leggero:

“Tutto l’uso dei servizi cloud deve essere riesaminato e approvato dal Direttore generale (GM) prima dell’attuazione o della sottoscrizione.”

Dalla sezione “Requisiti di governance”, clausola 5.1 della politica.

Entrambi gli approcci supportano la stessa aspettativa NIS2: il rischio di dipendenza dal cloud deve essere compreso prima che il servizio diventi parte della catena di erogazione.

Risposta agli incidenti: il conteggio delle 24 ore inizia prima della redazione del report

NIS2 Article 23 è rigoroso perché la tempistica di segnalazione decorre dalla conoscenza di un incidente significativo, non dal momento in cui è disponibile una perfetta analisi della causa radice. La sfida per i fornitori consiste nel determinare rapidamente se un evento è significativo, quali clienti sono interessati, se sono coinvolti dati personali, se esiste un impatto transfrontaliero sul servizio e quali termini contrattuali hanno iniziato a decorrere.

Il controllo 5.24 di Annex A di ISO/IEC 27001:2022, Pianificazione e preparazione della gestione degli incidenti di sicurezza delle informazioni, è il controllo di pianificazione. Zenith Controls lo sintetizza come controllo correttivo a supporto di riservatezza, integrità e disponibilità, collegato ai concetti di Respond e Recover, alla governance, alla gestione degli eventi e alla difesa. Include ruoli, responsabilità, percorsi di escalation, protocolli di comunicazione, preparazione alla notifica normativa, allineamento con logging e monitoraggio, integrazione con continuità operativa e Disaster Recovery, apprendimento post-incidente e mappatura verso NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 e COBIT 2019.

La Incident Response Policy-sme di Clarysec Incident Response Policy-sme - PMI trasforma la prima decisione in un requisito con limite temporale:

“Il Direttore generale, con il contributo del fornitore IT, deve classificare tutti gli incidenti per gravità entro un’ora dalla notifica.”

Dalla sezione “Requisiti di governance”, clausola 5.3.1 della politica.

Quella classificazione entro un’ora supporta la disciplina operativa necessaria per l’analisi del preallarme NIS2 entro 24 ore, la valutazione della violazione dei dati personali ai sensi del GDPR, l’escalation verso i clienti ai sensi di DORA e il triage delle notifiche contrattuali.

L’albero decisionale degli incidenti di un fornitore deve rispondere a quattro domande:

1. Esiste una compromissione confermata o sospetta di riservatezza, integrità o disponibilità?
2. L’evento incide sull’erogazione del servizio, sugli ambienti dei clienti, sui clienti regolamentati, sui dati personali o sulle funzioni critiche?
3. Può causare una grave interruzione operativa, una perdita finanziaria o un danno materiale o immateriale?
4. Quali obblighi di notifica si applicano: NIS2, GDPR, obblighi verso i clienti DORA, SLA contrattuali o aspettative dell’autorità nazionale di regolamentazione?

L’albero decisionale deve essere testato in esercitazioni tabletop prima di un incidente reale.

Gestione delle vulnerabilità: dimostrare la riduzione del rischio prima dell’impatto

NIS2 richiede la gestione e la divulgazione delle vulnerabilità. Per clienti e autorità di regolamentazione, la gestione delle vulnerabilità è una delle aree di controllo più semplici da misurare, perché produce evidenze chiare: copertura delle scansioni, tempistiche di applicazione delle patch, approvazioni delle eccezioni, analisi delle vulnerabilità sfruttate e registrazioni di remediation.

Il controllo 8.8 di Annex A di ISO/IEC 27001:2022, Gestione delle vulnerabilità tecniche, è sintetizzato in Zenith Controls come controllo preventivo trasversale a riservatezza, integrità e disponibilità, collegato a Identify e Protect, gestione di minacce e vulnerabilità, governance, ecosistema, protezione e difesa. Include identificazione delle vulnerabilità, valutazione, prioritizzazione, applicazione delle patch, controlli compensativi, integrazione della threat intelligence, divulgazione delle vulnerabilità, responsabilità sulle vulnerabilità cloud e applicative, evidenze di audit e tempistiche di remediation.

La Politica di gestione delle vulnerabilità e delle patch Enterprise di Clarysec Politica di gestione delle vulnerabilità e delle patch fornisce agli auditor un modello concreto da testare:

“L’organizzazione deve classificare tutte le vulnerabilità rilevate utilizzando una metodologia standardizzata (ad es. CVSS v3.x) e applicare tempistiche di remediation allineate alla criticità aziendale: 5.2.1 Critica (CVSS 9.0-10.0): riesame immediato; termine massimo di applicazione della patch pari a 72 ore. 5.2.2 Alta (7.0-8.9): risposta entro 48 ore; termine di applicazione della patch pari a 7 giorni di calendario. 5.2.3 Media (4.0-6.9): risposta entro 5 giorni; termine di applicazione della patch pari a 30 giorni di calendario. 5.2.4 Bassa (<4.0): risposta entro 10 giorni; termine di applicazione della patch pari a 60 giorni di calendario.”

Dalla sezione “Requisiti di governance”, clausola 5.2 della politica.

Per un fornitore cloud, questo deve coprire componenti hypervisor, immagini di container, livelli di orchestrazione, API rivolte ai clienti, pipeline CI/CD, console amministrative e librerie di terze parti. Per un MSP, la domanda chiave è se le vulnerabilità interne siano separate dalle vulnerabilità gestite dal cliente e se i contratti definiscano la responsabilità. Per un fornitore di data center, il campo di applicazione può includere sistemi di gestione degli edifici, sistemi di controllo degli accessi, piattaforme di monitoraggio, strumenti di remote hands e infrastruttura di rete.

Il modello di responsabilità condivisa deve essere documentato. Un fornitore può non essere responsabile di ogni patch, ma deve comunque gestire il rischio, notificare il cliente ove opportuno e dimostrare che i confini di responsabilità sono compresi.

Logging, monitoraggio e segmentazione rendono gli incidenti investigabili

Quando un incidente di un fornitore impatta i clienti, le prime domande sulle evidenze sono semplici: chi ha effettuato l’accesso, da dove, con quale privilegio, verso quale tenant, che cosa è stato modificato, quali log esistono e se i percorsi amministrativi erano segmentati.

La Politica di logging e monitoraggio Enterprise di Clarysec Politica di registrazione e monitoraggio richiede ai sistemi coperti di generare i log necessari a responder e auditor:

“Tutti i sistemi coperti devono generare log che acquisiscano: 6.1.1.1 Autenticazione dell’utente e tentativi di accesso 6.1.1.2 Attività degli utenti privilegiati 6.1.1.3 Modifiche alla configurazione 6.1.1.4 Tentativi di accesso non riusciti o eventi di sistema 6.1.1.5 Rilevamenti di malware e allarmi di sicurezza 6.1.1.6 Comunicazioni esterne e trigger delle regole del firewall”

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

Per le PMI che si affidano a fornitori esterni, la Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - PMI aggiunge un requisito contrattuale:

“I contratti devono richiedere ai fornitori di conservare i log per almeno 12 mesi e di fornire accesso su richiesta.”

Dalla sezione “Requisiti di governance”, clausola 5.5.1.3 della politica.

La segmentazione è altrettanto importante. La Network Security Policy-sme Network Security Policy-sme - PMI stabilisce:

“Le reti interne devono essere segmentate per funzione (ad es. finanza, guest, IoT, sistemi amministrativi).”

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

Zenith Blueprint, nella fase Controlli in azione, passaggio 20, fornisce la procedura pratica di audit per architettura di rete e segmentazione. Indica ai team di riesaminare e documentare la topologia di rete, verificare regole del firewall, configurazioni IPS/IDS e di accesso remoto, confermare che i security group cloud e le regole VPC o di sottorete corrispondano all’architettura prevista, elencare i servizi di rete interni ed esterni e validare che i sistemi sensibili non siano raggiungibili da VLAN utente generiche o reti guest.

Per un MSP, gli strumenti di gestione remota non devono trovarsi su una rete d’ufficio piatta. Per un fornitore di data center, le interfacce di gestione di alimentazione, raffreddamento, controllo degli accessi e servizi di rete dei clienti devono essere isolate e monitorate. Per un fornitore cloud, l’accesso al control plane deve essere limitato tramite identità, rete, livello di sicurezza del dispositivo e controlli del flusso di lavoro privilegiato.

Sicurezza dei fornitori: anche il provider è un cliente

I fornitori cloud, MSP, MSSP e data center sono fornitori per clienti regolamentati, ma sono anche clienti di vendor software, operatori di telecomunicazioni, provider di identità, piattaforme SaaS, fornitori hardware, subappaltatori e operatori infrastrutturali.

NIS2 rende la sicurezza della catena di fornitura un requisito centrale. DORA, applicabile dal 17 gennaio 2025, rende centrale la gestione del rischio ICT di terze parti per gli enti finanziari. NIS2 Article 4 e Recital 28 riconoscono DORA come atto giuridico settoriale specifico dell’Unione per gli enti finanziari nei casi di sovrapposizione dei requisiti. Questo non riduce la pressione sui fornitori cloud e MSP. La aumenta, perché i clienti finanziari trasferiscono nei contratti con i fornitori requisiti contrattuali di livello DORA, diritto di audit, test di resilienza, strategie di uscita e aspettative di segnalazione degli incidenti.

La Politica di sicurezza delle terze parti e dei fornitori Enterprise di Clarysec Politica di sicurezza delle terze parti e dei fornitori richiede un accesso di terze parti controllato:

“Tutti gli accessi di terze parti devono essere registrati e monitorati e, ove possibile, segmentati tramite bastion host, VPN o gateway Zero Trust.”

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

La Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - PMI esprime il principio del privilegio minimo in termini diretti:

“Ai fornitori deve essere concesso accesso solo ai sistemi e ai dati minimi necessari per svolgere la loro funzione.”

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

Queste clausole si mappano naturalmente ai controlli 5.19, 5.20, 5.21 e 5.22 di Annex A di ISO/IEC 27001:2022. Supportano inoltre la governance di responsabili del trattamento e sub-responsabili ai sensi del GDPR, i riesami del rischio di terze parti DORA e i questionari di sicurezza dei clienti.

Continuità operativa e resilienza dei data center: dimostrare le assunzioni

NIS2 Article 21 include continuità operativa, gestione dei backup, Disaster Recovery e gestione delle crisi. DORA Articles 11 to 14 richiedono, per gli enti finanziari, politiche di continuità operativa ICT, piani di risposta e ripristino, Business Impact Analysis, politiche di backup, procedure di ripristino, obiettivi di ripristino, test, riesami post-incidente e comunicazioni di crisi.

Per i fornitori cloud e data center, la continuità non è un raccoglitore. È architettura, capacità, contratti, dipendenze, evidenze di ripristino e assunzioni testate.

La Politica di continuità operativa e disaster recovery Enterprise di Clarysec Politica di continuità operativa e disaster recovery richiede una BIA annuale e un riesame dopo modifiche significative:

“La Business Impact Analysis (BIA) deve essere eseguita almeno annualmente per tutte le unità aziendali critiche e riesaminata in caso di modifiche significative a sistemi, processi o dipendenze. Gli output della BIA devono definire: 5.2.1. Maximum Tolerable Downtime (MTD) 5.2.2. Recovery Time Objectives (RTOs) 5.2.3. Recovery Point Objectives (RPOs) 5.2.4. Dipendenze critiche (sistemi, fornitori, personale)”

Dalla sezione “Requisiti di governance”, clausola 5.2 della politica.

In uno scenario di data center, la BIA deve coprire linee di alimentazione, UPS, generatori, contratti di fornitura carburante, raffreddamento, sistemi antincendio, operatori di rete, sistemi di accesso fisico, remote hands, monitoraggio, hardware di ricambio e canali di comunicazione con i clienti. In uno scenario cloud, deve coprire regioni, zone di disponibilità, replica, immutabilità dei backup, dipendenze di identità, DNS, autorità di certificazione, gateway API e sistemi di supporto. In uno scenario MSP, deve coprire strumenti di gestione remota, vault per accessi privilegiati, console EDR, ticketing, repository documentali e comunicazioni di emergenza.

ISO 22301 può rafforzare la disciplina del Business Continuity Management, mentre ISO/IEC 27005:2022 supporta criteri di rischio, pianificazione del trattamento, monitoraggio, evidenze e miglioramento continuo. Questo è utile perché la preparazione a NIS2 richiede all’organizzazione di consolidare fattori legali, contrattuali, operativi, di fornitura, tecnologici, finanziari, di processo e umani in un unico processo di rischio.

Traccia pratica del rischio per una violazione dell’accesso remoto di un MSP

Un workshop pratico può iniziare con uno scenario:

“La compromissione dell’accesso remoto privilegiato determina accesso non autorizzato ai sistemi dei clienti, interruzione del servizio, possibile esposizione di dati personali e obblighi di notifica normativa.”

Create una riga nel registro dei rischi e completate la traccia.

Aggiornate quindi la Dichiarazione di Applicabilità. Per ciascun controllo pertinente di Annex A, spiegate perché si applica e quale tema NIS2 supporta. Infine, raccogliete evidenze prima dell’audit: report di applicazione MFA, elenchi di account privilegiati, impostazioni di conservazione dei log, stato delle patch RMM, alert SIEM, registrazioni di classificazione degli incidenti, approvazioni degli accessi dei fornitori e risultati delle esercitazioni tabletop.

Come auditor diversi testeranno lo stesso ambiente di controllo

Un SGSI integrato deve soddisfare diverse prospettive di assurance senza creare pacchetti di evidenze separati per ogni quadro di riferimento.

È qui che Zenith Controls aiuta come guida alla conformità incrociata. Per controlli come 5.23, 5.24 e 8.8, collega le aspettative di controllo ISO/IEC 27001:2022 ai temi NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF e ISO 22301. L’obiettivo non è creare programmi di conformità separati. L’obiettivo è un’unica architettura delle evidenze etichettata per controllo, rischio, driver normativo e proprietario.

Il modello di attuazione Clarysec

Per fornitori cloud, MSP, MSSP e data center, il lavoro deve procedere su cinque livelli.

Primo, confermare il campo di applicazione. Determinare se l’organizzazione e i servizi rientrano nel campo di applicazione di NIS2, quali norme dello Stato membro si applicano, se il Regolamento di esecuzione 2024/2690 si applica alla categoria del fornitore e se i clienti impongono obblighi DORA, GDPR, NIST o settoriali.

Secondo, costruire il contesto del SGSI. Ai sensi delle clausole 4 e 5 di ISO/IEC 27001:2022, identificare parti interessate, obblighi legali, impegni verso i clienti, dipendenze dai fornitori, confini del servizio e responsabilità della direzione.

Terzo, eseguire valutazione e trattamento del rischio utilizzando i principi di ISO/IEC 27005:2022. Consolidare NIS2, DORA, GDPR, contratti, politiche interne e rischi di servizio in un unico registro dei requisiti di base. Definire criteri di rischio, proprietari, probabilità, impatto, opzioni di trattamento, scelte di controllo e approvazioni del rischio residuo.

Quarto, mappare i controlli nella Dichiarazione di Applicabilità. Utilizzare i passaggi 13 e 14 di Zenith Blueprint per tracciare i rischi verso i controlli di Annex A e le aspettative normative. Utilizzare Zenith Controls per comprendere come controlli quali 5.23, 5.24, 8.8, 5.20 e 5.30 si mappano tra quadri di riferimento e prospettive di audit.

Quinto, rendere operative le evidenze. Le politiche non bastano. La libreria di politiche Clarysec fornisce requisiti applicabili per approvazione cloud, accesso dei fornitori, logging, remediation delle vulnerabilità, segmentazione della rete, classificazione degli incidenti e pianificazione della continuità. Il pacchetto di evidenze dimostra che tali requisiti funzionano.

Passo successivo: trasformare la pressione NIS2 in resilienza pronta per l’audit

Il Regolamento di esecuzione NIS2 2024/2690 non richiede caos. Richiede tracciabilità, titolarità e prova.

Se siete un fornitore di servizi cloud, un MSP, un MSSP o un operatore di data center, iniziate da servizi, clienti, dipendenze, scenari di incidente e obblighi di evidenza. Eseguite quindi un esercizio strutturato di mappatura da NIS2 a ISO/IEC 27001:2022:

1. Confermate se il vostro soggetto e i vostri servizi rientrano nel campo di applicazione.
2. Mappate i temi NIS2 e del Regolamento di esecuzione nel campo di applicazione del vostro SGSI.
3. Aggiornate il registro dei rischi e la Dichiarazione di Applicabilità.
4. Applicate le politiche Clarysec per uso del cloud, sicurezza dei fornitori, logging, gestione delle vulnerabilità, risposta agli incidenti, sicurezza della rete e continuità.
5. Utilizzate Zenith Blueprint Zenith Blueprint, passaggi 13, 14, 20 e 23, per creare tracciabilità ed evidenze operative.
6. Utilizzate Zenith Controls Zenith Controls per mappare in modo incrociato i controlli ISO/IEC 27001:2022 rispetto alle aspettative NIS2, DORA, GDPR, NIST e COBIT 2019.
7. Testate le evidenze tramite una simulazione di audit prima che un cliente, un’autorità di regolamentazione o un auditor di certificazione le richieda.

Clarysec può aiutarvi ad andare oltre la conformità da checklist e a costruire un SGSI integrato in grado di sostenere la pressione di audit NIS2, DORA, GDPR e dei clienti. Scaricate i toolkit Clarysec pertinenti, prenotate un workshop di mappatura o richiedete una valutazione della preparazione agli audit per trasformare la complessità normativa in governance della sicurezza difendibile e resilienza operativa.