Campo di applicazione del SGSI ISO 27001 per NIS2, DORA e GDPR

Maria, CISO di una fintech europea in rapida crescita, riteneva che l’audit di sorveglianza ISO 27001 fosse sotto controllo.

Il certificato era recente. La Dichiarazione di Applicabilità appariva matura. La dichiarazione del campo di applicazione copriva “il sistema di gestione per la sicurezza delle informazioni aziendale a supporto delle operazioni della piattaforma SaaS”. L’ambiente cloud di produzione era documentato. La procedura di risposta agli incidenti esisteva. Il registro dei rischi riportava proprietari, date e classificazioni del rischio residuo.

Poi l’auditor pose una domanda semplice:

“Quali parti di questa piattaforma SaaS rientrano anche nel perimetro di registrazione NIS2, quali servizi esternalizzati supportano funzioni critiche o importanti DORA per i vostri clienti finanziari e dove vengono trattati esattamente i dati personali ai sensi del GDPR?”

La sala rimase in silenzio.

L’ufficio legale aprì un foglio di calcolo degli obblighi normativi. Il prodotto aprì un diagramma di architettura. Il DPO aprì il registro delle attività di trattamento. L’ufficio acquisti aprì l’elenco dei fornitori. Le operations aprirono il piano di disaster recovery. Nessuno di questi documenti coincideva.

Il campo di applicazione del SGSI diceva “piattaforma SaaS”. La valutazione NIS2 identificava servizi di infrastruttura digitale in diversi Stati membri. I contratti con i clienti descrivevano la piattaforma come supporto a operazioni finanziarie regolamentate. Le registrazioni GDPR includevano dati di identità, telemetria, indirizzi IP, metadati di pagamento, ticket di supporto e sistemi di analytics subappaltati. Il piano di disaster recovery copriva la produzione, ma non la piattaforma di assistenza clienti utilizzata per le comunicazioni relative alle violazioni. La due diligence sui fornitori copriva il provider di hosting, ma non il servizio di rilevamento gestito collegato ai log di produzione.

Questo è il problema della definizione del campo di applicazione del SGSI nel 2026. La certificazione ISO 27001 resta preziosa, ma un “campo di applicazione minimo sostenibile” può diventare una responsabilità quando autorità di vigilanza, clienti e auditor si aspettano che lo stesso sistema di gestione spieghi servizi essenziali NIS2, funzioni critiche o importanti DORA e confini del trattamento GDPR.

Per ISO/IEC 27001:2022, NIS2, DORA e GDPR, un campo di applicazione debole non è un difetto amministrativo. È la prima tessera del domino. Se il campo di applicazione è errato, la valutazione del rischio è incompleta, la SoA è fuorviante, i controlli sui fornitori non intercettano provider critici, i tempi di segnalazione degli incidenti diventano incerti e la responsabilizzazione privacy si frammenta tra i team.

Perché il campo di applicazione del SGSI ISO 27001 è oggi un perimetro normativo

ISO/IEC 27001:2022 clausola 4.3 richiede all’organizzazione di determinare i confini e l’applicabilità del SGSI, tenendo conto dei fattori interni ed esterni, dei requisiti delle parti interessate e delle interfacce e dipendenze con altre organizzazioni ISO/IEC 27001:2022.

Questo linguaggio conta molto più nel 2026 rispetto ai cicli di certificazione precedenti. NIS2, DORA, GDPR, outsourcing cloud, contratti con i clienti, servizi tecnologici di gruppo e fornitori di servizi gestiti non sono note a margine. Sono input per la definizione del confine del SGSI.

NIS2 aumenta la rilevanza della governance per i soggetti essenziali e importanti. Richiede agli organi di gestione di approvare le misure di gestione dei rischi di cibersicurezza, supervisionarne l’attuazione e ricevere formazione. NIS2 Article 21 richiede misure tecniche, operative e organizzative adeguate e proporzionate, tra cui analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, acquisizione e sviluppo sicuri, valutazione dell’efficacia, igiene informatica, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e autenticazione a più fattori ove appropriato.

DORA cambia la discussione sul campo di applicazione per gli enti finanziari. Si applica dal 17 gennaio 2025 e stabilisce requisiti uniformi per la gestione del rischio ICT, la segnalazione degli incidenti connessi all’ICT, i test di resilienza operativa digitale, la condivisione delle informazioni e la gestione del rischio ICT di terze parti. DORA Article 6 richiede un quadro documentato di gestione del rischio ICT. DORA Article 8 richiede l’identificazione, la classificazione e la documentazione delle funzioni aziendali supportate dall’ICT, degli asset informativi e degli asset ICT, incluse le dipendenze. DORA Article 28 richiede la gestione del rischio ICT di terze parti.

Il GDPR aggiunge l’asse dei dati personali. Si applica al trattamento automatizzato o strutturato di dati personali, compreso il trattamento da parte di stabilimenti nell’UE e di determinati titolari o responsabili del trattamento non UE che offrono beni o servizi a persone nell’Unione o ne monitorano il comportamento. GDPR Article 30 richiede il registro delle attività di trattamento, Article 32 richiede la sicurezza del trattamento e Article 33 definisce le aspettative di notifica delle violazioni.

Un campo di applicazione del SGSI sostenibile in sede di audit non viene quindi scritto attorno ai dipartimenti. Viene scritto attorno a servizi regolamentati, funzioni critiche o importanti, trattamenti di dati personali, asset di supporto e dipendenze da terze parti.

L’errore: trattare ISO 27001, NIS2, DORA e GDPR come programmi separati

In molte organizzazioni si osserva uno schema ricorrente:

• La sicurezza redige il campo di applicazione ISO 27001.
• Il legale valuta l’applicabilità di NIS2.
• Il rischio o la compliance gestisce gli obblighi DORA.
• La privacy mantiene il registro delle attività di trattamento GDPR.
• L’ufficio acquisti è titolare dell’elenco dei fornitori.
• Le operations sono titolari della continuità operativa e del disaster recovery.

Ogni team può svolgere un lavoro ragionevole. Il problema è che la realtà regolamentata li attraversa tutti.

Un servizio di identità cliente ospitato in cloud può supportare contemporaneamente l’erogazione di servizi NIS2, le operazioni dei clienti regolamentate da DORA e il trattamento di dati personali GDPR. Un provider di rilevamento gestito può essere un fornitore di sicurezza, una dipendenza della risposta agli incidenti, un responsabile o sub-responsabile del trattamento dei dati di log e un input essenziale per le decisioni di notifica regolamentare. Una piattaforma di supporto può essere considerata “non di produzione” pur gestendo comunicazioni relative a violazioni dei dati personali e richieste di evidenze da parte dei clienti.

Il SGSI è il luogo più adatto per integrare questi obblighi perché ISO 27001 impone una domanda disciplinata: cosa è dentro il perimetro, cosa è fuori e perché?

Il Zenith Blueprint: roadmap in 30 passaggi per l’auditor di Clarysec Zenith Blueprint affronta questo aspetto nella fase ISMS Foundation & Leadership, Step 2: Stakeholder Needs and ISMS Scope:

“Una volta compreso il contesto e identificati i requisiti delle parti interessate, la clausola 4.3 richiede di determinare i confini e l’applicabilità del SGSI per stabilirne il campo di applicazione. Il campo di applicazione del SGSI è una definizione essenziale che stabilisce cosa è incluso nel programma di gestione della sicurezza e cosa non lo è.”

Il Zenith Blueprint evidenzia anche un punto che molte dichiarazioni del campo di applicazione continuano a trascurare:

“Se esternalizzi l’infrastruttura informatica a un fornitore cloud, questo non la esclude dal campo di applicazione; al contrario, includi la gestione di tale rapporto e gli asset cloud come parte del campo di applicazione.”

L’outsourcing sposta l’esecuzione. Non elimina la responsabilità.

Il modello a quattro confini per il campo di applicazione ISO 27001 nel 2026

Per le organizzazioni interessate da NIS2, DORA e GDPR, Clarysec raccomanda di definire il campo di applicazione del SGSI ISO 27001 attraverso quattro confini collegati.

Una dichiarazione debole del campo di applicazione dice soltanto “la piattaforma SaaS”. Una dichiarazione più solida indica quali servizi aziendali, sistemi, ambienti, sedi, attività di trattamento dei dati, gruppi di personale, rapporti con i fornitori e processi di gestione sono inclusi.

Una versione più sostenibile potrebbe essere formulata così:

“Il SGSI copre la governance, la gestione del rischio, l’esercizio e il miglioramento continuo della sicurezza delle informazioni per la piattaforma SaaS di analisi dei pagamenti UE dell’azienda, inclusi gli ambienti cloud di produzione e non di produzione, i servizi di identità cliente, le interfacce amministrative, le attività di supporto, le piattaforme di logging e monitoraggio, la risposta agli incidenti, la continuità operativa, la gestione dei fornitori e tutte le attività di trattamento dei dati personali a supporto del servizio. Il SGSI include la gestione dell’hosting cloud esternalizzato, del rilevamento gestito e degli strumenti di assistenza clienti utilizzati per l’erogazione del servizio, la resilienza, il monitoraggio della sicurezza o le comunicazioni connesse al GDPR.”

Quel campo di applicazione non è solo più lungo. È più verificabile perché collega servizi, asset, trattamenti e dipendenze.

Come le politiche Clarysec trasformano il campo di applicazione in linguaggio di governance

Il campo di applicazione non deve vivere in un documento isolato. Deve essere allineato alla politica per la sicurezza delle informazioni, alla conformità legale e normativa, alla gestione del rischio, alla privacy, alla governance dei fornitori, ai criteri di audit e alla pianificazione della continuità.

La Politica per la sicurezza delle informazioni Enterprise Politica per la sicurezza delle informazioni evita ambiguità sulle esclusioni:

“Qualsiasi esclusione o limitazione a questo campo di applicazione deve essere documentata nella Dichiarazione del campo di applicazione del SGSI e giustificata con approvazione formale dell’alta direzione.”

Questa clausola è rilevante quando una business unit sostiene che l’assistenza clienti sia fuori dalla piattaforma, anche se gli operatori di supporto accedono a identificativi dei clienti e gestiscono comunicazioni relative alle violazioni. L’esclusione è possibile solo se documentata, giustificata e approvata.

La Politica di conformità legale e normativa Enterprise Politica di conformità legale e normativa rende operativa la mappatura legale:

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

Questo è il ponte tra applicabilità legale e Dichiarazione di Applicabilità. NIS2 Article 21 non deve restare in un memorandum legale. Gli obblighi ICT di terze parti previsti da DORA non devono restare solo nelle linee guida di procurement. Gli obblighi GDPR Article 30 e Article 32 non devono risiedere solo nel registro privacy. Devono avere proprietari, controlli ed evidenze mappati.

La Politica di gestione del rischio Enterprise Politica di gestione del rischio estende il campo di applicazione alle terze parti:

“Questa politica si applica a tutte le unità organizzative, ai processi aziendali, ai sistemi, al personale e agli incarichi con terze parti coinvolti nella gestione, nello sviluppo, nell’archiviazione o nell’amministrazione degli asset informativi.”

Questa formulazione è allineata alla sicurezza della catena di fornitura NIS2, al rischio ICT di terze parti DORA e alla responsabilizzazione del titolare o del responsabile del trattamento ai sensi del GDPR.

La Politica di protezione dei dati e privacy Enterprise Politica di protezione dei dati e privacy ancora il perimetro privacy al trattamento:

“Questa politica si applica a tutte le unità organizzative, al personale e ai sistemi coinvolti nel trattamento di dati personali identificabili (PII), inclusi:”

Il principio è decisivo. Se un sistema tratta PII, non può essere invisibile al SGSI perché è “solo di supporto”, “non di produzione” o “di proprietà del marketing”.

La Politica di continuità operativa e disaster recovery Enterprise Politica di continuità operativa e disaster recovery collega il campo di applicazione ai risultati della BIA:

“Questa politica si applica a tutte le unità organizzative, ai sistemi informativi, ai processi aziendali, al personale e ai servizi di terze parti classificati come critici o essenziali sulla base dei risultati della Business Impact Analysis (BIA).”

Questa clausola si allinea naturalmente alle funzioni critiche o importanti DORA e alla continuità dei servizi NIS2.

Per le organizzazioni più piccole, le politiche SME di Clarysec mantengono una formulazione concisa preservando la stessa logica. La Politica di audit e monitoraggio della conformità-sme SME Politica di audit e monitoraggio della conformità-sme - SME definisce la copertura dell’audit come:

“Tutti i controlli e i sistemi rientranti nel campo di applicazione del Sistema di gestione per la sicurezza delle informazioni (SGSI)”

La Politica di protezione dei dati e privacy-sme SME Politica di protezione dei dati e privacy-sme - SME definisce il perimetro privacy come:

“Qualsiasi sistema, applicazione o sede in cui i dati personali sono archiviati o trasmessi”

La Politica di gestione del rischio-sme SME Politica di gestione del rischio-sme - SME mantiene visibili i servizi esternalizzati:

“Tutte le informazioni, i servizi e gli asset gestiti internamente o tramite terze parti”

Clausole brevi come queste sono efficaci perché impediscono a un perimetro di certificazione di escludere dati regolamentati, servizi cloud o asset gestiti da fornitori.

L’inventario degli asset è il punto in cui il campo di applicazione diventa reale

Una dichiarazione del campo di applicazione è credibile solo se può essere ricondotta ad asset, proprietari, fornitori, flussi di dati ed evidenze.

Il Zenith Blueprint, nella fase Risk Management, Step 9: Identifying Assets, Threats, and Vulnerabilities, chiede alle organizzazioni di elencare gli asset nel campo di applicazione del SGSI e di registrare proprietario, posizione e classificazione. Fornisce un esempio pratico:

“Database clienti – di proprietà del reparto IT – ospitato su AWS – contiene dati personali e finanziari (alta sensibilità).”

Lo stesso passaggio aggiunge un promemoria di perimetrazione direttamente rilevante per NIS2 e GDPR:

“Assicurati che gli asset contenenti dati personali siano contrassegnati (per la rilevanza GDPR) e che gli asset dei servizi critici siano indicati (per la potenziale applicabilità NIS2 se operi in un settore regolamentato).”

La guida Zenith Controls: guida alla conformità trasversale di Clarysec Zenith Controls tratta il controllo ISO/IEC 27002:2022 5.9, Inventario delle informazioni e degli altri asset associati, come un controllo fondamentale di conformità trasversale. I suoi attributi classificano il controllo come preventivo, a supporto di riservatezza, integrità e disponibilità, allineato al concetto di cibersicurezza Identify, alla capacità operativa di gestione degli asset e ai domini di governance, ecosistema e protezione.

Zenith Controls spiega con chiarezza la rilevanza per GDPR e NIS2:

“Senza un inventario degli asset accurato e aggiornato, le organizzazioni non possono valutare o applicare protezioni adeguate.”

Per NIS2, l’inventario degli asset supporta l’identificazione dei sistemi e dei componenti critici alla base dei servizi essenziali o importanti. Per DORA, DORA Article 8 rende centrale per la resilienza operativa l’identificazione degli asset ICT e degli asset informativi. Per il GDPR, l’inventario degli asset supporta la mappatura dei flussi di dati, la qualità del RoPA e la risposta alle violazioni.

Gli standard ISO di supporto rafforzano la stessa logica. ISO/IEC 27005:2024 potenzia l’identificazione degli asset nella valutazione del rischio per la sicurezza delle informazioni. ISO 22301:2019 supporta l’identificazione delle risorse necessarie per la continuità operativa. ISO/IEC 19770-1:2017 supporta la maturità della gestione degli asset IT. ISO/IEC 27017:2015 e ISO/IEC 27018:2019 supportano controlli specifici per il cloud e la protezione delle PII nei cloud pubblici. ISO/IEC 27701:2019 estende la gestione delle informazioni sulla privacy. ISO/IEC 29100:2011 contribuisce ai principi privacy, quali trasparenza, minimizzazione e misure di sicurezza.

Un esercizio pratico di definizione del campo di applicazione per team SaaS e fintech

Inizia da un servizio regolamentato, non dall’intera azienda. Ad esempio: “SaaS UE di analisi dei pagamenti per istituzioni finanziarie”.

Quindi costruisci una mappa servizio-asset-trattamento.

Un esempio di asset più dettagliato potrebbe essere il seguente.

Successivamente, usa Zenith Blueprint Step 13: Risk Treatment Planning and Statement of Applicability. La guida chiede agli utenti di costruire la SoA utilizzando il modello che elenca tutti i controlli dell’Annex A e di decidere l’applicabilità in base al trattamento del rischio, ai requisiti legali o contrattuali, alla rilevanza rispetto al campo di applicazione e al contesto organizzativo. Afferma:

“Per ciascun controllo (riga) nel foglio SoA, decidi se è applicabile al tuo SGSI.”

Per l’esempio sopra, la SoA dovrebbe considerare i controlli per la sicurezza dei fornitori, i servizi cloud, la gestione degli incidenti, la continuità, i requisiti legali e normativi, la privacy, la gestione delle vulnerabilità, i backup, il logging, il monitoraggio, la crittografia, lo sviluppo sicuro, i test di sicurezza e la gestione delle modifiche.

Un workflow pratico è:

1. Creare una scheda “Mappatura del campo di applicazione del SGSI” nel registro dei rischi e nel SoA Builder.
2. Aggiungere una riga per ogni servizio regolamentato o linea di prodotto.
3. Collegare ciascun servizio ad asset, tipi di dati, fornitori, sedi e titolari dell’attività.
4. Contrassegnare la rilevanza NIS2, la rilevanza DORA e la rilevanza del trattamento GDPR.
5. Aggiungere scenari di rischio per indisponibilità del servizio, violazione dei dati personali, guasto del fornitore, configurazione errata del cloud, vulnerabilità critica e mancata segnalazione degli incidenti.
6. Selezionare i controlli SoA in base a tali rischi e obblighi.
7. Documentare esclusioni, controlli compensativi e accettazione del rischio.
8. Ottenere l’approvazione dell’alta direzione per i confini e le esclusioni finali.
9. Trasferire il confine finale nell’audit interno, nel riesame della direzione e nel monitoraggio dei fornitori.

Il risultato non è solo una migliore dichiarazione del campo di applicazione. È una catena difendibile che va dal servizio regolamentato ad asset, fornitore, dati, controllo, proprietario ed evidenza.

Mappatura della conformità trasversale: un campo di applicazione, molti obblighi

Un SGSI ISO 27001 ben perimetrato diventa il livello operativo in cui possono essere riconciliate le aspettative di NIS2, DORA, GDPR, NIST CSF e COBIT.

Per il controllo ISO/IEC 27002:2022 5.31, Requisiti legali, statutari, normativi e contrattuali, Zenith Controls collega gli obblighi di conformità alla privacy, alla protezione delle PII, alla conservazione delle registrazioni, al riesame indipendente e alla conformità alle politiche interne. Si mappa naturalmente sulla responsabilizzazione GDPR, sulla conformità della catena di fornitura NIS2, sulla gestione del rischio ICT e sulla conformità DORA, sulla governance NIST CSF e sul monitoraggio della conformità esterna COBIT 2019.

Per il controllo ISO/IEC 27002:2022 5.34, Privacy e protezione delle PII, Zenith Controls collega la privacy all’inventario degli asset, ai servizi cloud, alla classificazione, al trasferimento delle informazioni, al controllo degli accessi, alla gestione delle identità e ai riesami delle modifiche di progetto. La sua mappatura GDPR copre la sicurezza del trattamento e la protezione dei dati fin dalla progettazione. La sua mappatura DORA supporta l’integrità, la sicurezza e la riservatezza dei dati, inclusi i dati personali trattati nei servizi ICT.

Il principio è semplice: non creare quattro programmi di conformità scollegati. Crea un unico SGSI perimetrato che possa spiegare come gli obblighi sono soddisfatti, dimostrati tramite evidenze e sottoposti ad audit.

Campo di applicazione della segnalazione degli incidenti: dove i confini incidono sui tempi regolamentari

Un campo di applicazione errato diventa dolorosamente visibile durante gli incidenti.

NIS2 Article 23 richiede una segnalazione scaglionata degli incidenti significativi, inclusi un preallarme entro 24 ore, una notifica di incidente entro 72 ore, relazioni intermedie quando richieste e una relazione finale entro un mese. Può essere richiesta anche la comunicazione ai destinatari interessati.

DORA richiede agli enti finanziari di rilevare, gestire, classificare e segnalare gli incidenti gravi connessi all’ICT utilizzando criteri quali clienti o controparti interessati, durata, indisponibilità, diffusione geografica, perdite di dati, criticità dei servizi interessati e impatto economico. I clienti devono essere informati senza indebito ritardo quando un incidente ICT grave incide sui loro interessi finanziari.

La notifica di una violazione dei dati personali ai sensi del GDPR dipende dal fatto che una violazione comporti distruzione, perdita, modifica, divulgazione non autorizzata o accesso non autorizzato a dati personali, in modo accidentale o illecito.

Se la piattaforma di supporto, l’ambiente dei log, il servizio di identità, il canale di notifica ai clienti o il provider di rilevamento gestito restano fuori dal campo di applicazione del SGSI, i team di risposta agli incidenti potrebbero non sapere se un evento attiva NIS2, DORA, GDPR, obblighi contrattuali verso i clienti o tutti questi regimi. Questa incertezza consuma il tempo disponibile per la segnalazione.

Un campo di applicazione maturo include le dipendenze rilevanti per gli incidenti: strumenti di rilevamento, archivi di log, repository forensi, canali di comunicazione con i clienti, strumenti di supporto, ambienti di backup, bridge di incidente e fornitori coinvolti nel triage o nel ripristino.

Come auditor e autorità di vigilanza testeranno il campo di applicazione del tuo SGSI

Un campo di applicazione solido resiste al campionamento. Un campo di applicazione debole crolla quando gli auditor confrontano i documenti con la realtà.

Zenith Controls fornisce aspettative di audit utili per il controllo ISO/IEC 27002:2022 5.9. Gli auditor in stile ISO/IEC 19011 richiedono l’inventario nelle prime fasi per perimetrare altre valutazioni ed eseguire controlli a campione su asset fisici, software e cloud. Gli auditor in stile ISO/IEC 27007 chiedono come e quando viene aggiornato l’inventario, cercando collegamenti con procurement, gestione delle modifiche e dismissione. Gli auditor in stile NIST SP 800-53A verificano che i dettagli dell’inventario includano tipo di asset, proprietario, posizione, indirizzo di rete ove applicabile e stato, e che siano inclusi asset cloud, virtuali e mobili.

Per il controllo 5.31, Zenith Controls osserva che gli auditor di certificazione si aspettano un registro di conformità o un elenco di leggi e contratti, richiamato nella SoA e nei piani di trattamento del rischio. Gli auditor COBIT cercano proprietari della conformità, valutazioni e reportistica all’alta direzione. Gli auditor ISACA ITAF campionano le evidenze per confermare che l’organizzazione non solo conosca i propri obblighi, ma ne assicuri attivamente il rispetto.

Per il controllo 5.34, gli auditor esaminano politiche privacy, inventari dei dati, DPIA, registrazioni della formazione, evidenze di cifratura, controlli di accesso, campioni DSAR, evidenze di protezione dei dati fin dalla progettazione e registrazioni di incidenti che coinvolgono PII. Una dichiarazione del campo di applicazione che esclude un sistema che tratta dati personali sarà rapidamente contestata.

La domanda del consiglio: cosa non può essere escluso?

L’alta direzione chiede spesso se una business unit, una sede, un fornitore o un sistema possa restare fuori dal campo di applicazione del SGSI. Talvolta la risposta è sì. Ma non se l’esclusione impedisce all’organizzazione di rispettare obblighi legali, normativi, contrattuali o di sicurezza del servizio.

Usa questo test di esclusione prima di approvare qualsiasi limitazione del confine:

• L’unità, il sistema o il fornitore supporta un servizio regolamentato da NIS2?
• Supporta una funzione critica o importante DORA per l’organizzazione o per i suoi clienti regolamentati?
• Raccoglie, archivia, trasmette, registra, supporta o cancella dati personali?
• Fornisce monitoraggio della sicurezza, identità, backup, risposta agli incidenti o ripristino per un servizio rientrante nel campo di applicazione?
• Fornisce evidenze necessarie per la classificazione degli incidenti o la notifica regolamentare?
• Un contratto con un cliente richiede che sia coperto dal SGSI?
• La sua compromissione inciderebbe su riservatezza, integrità, disponibilità, conformità legale o continuità del servizio entro il campo di applicazione dichiarato?

Se la risposta è sì, l’esclusione richiede evidenze solide, governance compensativa, accettazione del rischio e approvazione formale dell’alta direzione. In molti casi, non dovrebbe essere esclusa.

Un campo di applicazione moderno del SGSI ISO 27001 dovrebbe includere:

1. Servizi aziendali e linee di prodotto coperti.
2. Entità giuridiche, unità organizzative e sedi coperte.
3. Segmenti di clientela e giurisdizioni che generano obblighi.
4. Funzioni critiche o importanti e servizi essenziali basati sulla BIA.
5. Asset informativi, asset ICT e ambienti cloud.
6. Attività di trattamento dei dati personali e repository PII.
7. Processi di sviluppo, test, supporto, monitoraggio e risposta agli incidenti.
8. Fornitori e servizi esternalizzati a supporto dei servizi rientranti nel campo di applicazione.
9. Interfacce e dipendenze con società del gruppo o provider esterni.
10. Esclusioni esplicite con giustificazione, accettazione del rischio e approvazione dell’alta direzione.

È così che il campo di applicazione ISO 27001 diventa una posizione di governance a livello di consiglio, non una scorciatoia per la certificazione.

Rendi il tuo campo di applicazione del SGSI pronto per l’audit prima che lo definisca l’auditor

Il momento peggiore per scoprire un problema di campo di applicazione è durante la certificazione, il riesame dell’autorità di vigilanza, la due diligence del cliente o un incidente in corso.

Un certificato ristretto può soddisfare una casella di controllo del procurement, ma non reggerà a un esame serio se esclude i servizi, le funzioni ICT, i fornitori e il trattamento dei dati personali che generano esposizione normativa. Nel 2026, le organizzazioni che supereranno gli audit con fiducia saranno quelle in grado di mostrare una mappa coerente dal servizio regolamentato ad asset, fornitore, dati personali, controllo, proprietario ed evidenza.

Inizia con tre azioni concrete:

1. Usa Zenith Blueprint Zenith Blueprint Phase: ISMS Foundation & Leadership, Step 2, per riscrivere il campo di applicazione del SGSI attorno a servizi, funzioni, trattamenti e dipendenze.
2. Usa Zenith Controls Zenith Controls per mappare inventario degli asset, obblighi legali e protezione delle PII rispetto alle aspettative di audit di ISO 27001, NIS2, DORA, GDPR, NIST e COBIT 2019.
3. Allinea il campo di applicazione delle politiche utilizzando la Politica per la sicurezza delle informazioni di Clarysec Politica per la sicurezza delle informazioni, la Politica di conformità legale e normativa Politica di conformità legale e normativa, la Politica di gestione del rischio Politica di gestione del rischio, la Politica di protezione dei dati e privacy Politica di protezione dei dati e privacy e la Politica di continuità operativa e disaster recovery Politica di continuità operativa e disaster recovery.

Se il tuo attuale campo di applicazione del SGSI sembra ancora un’etichetta di dipartimento, ricostruiscilo come perimetro di conformità. Scarica i toolkit Clarysec, mappa un servizio regolamentato end-to-end e trasforma il tuo campo di applicazione ISO 27001 in evidenze pronte per l’audit per NIS2, DORA e GDPR.