nis2-agile/docs/Agile 27000/VALUTAZIONE_COPERTURA_NIS2AGILE_vs_ISO27001.md

Valutazione: avremmo risposto all'audit ISO/IEC 27001:2022 usando NIS2 Agile?

Per la direzione di Agile · 2026-06-17 · basata sulle due checklist dell'auditor in docs/Agile 27000/ (ISO27001_2022_Documenti_Registrazioni.xlsx, Check_List_27001_215_15.xlsx) e su verifica del codice del prodotto.

Risposta in breve

In buona parte sì — per la "carta" del SGSI; no, per i controlli tecnici reali. Con NIS2 Agile saremmo arrivati all'audit con SoA, registro rischi, non conformità, formazione, asset, evidenze e audit-trail già pronti e presentabili (è proprio dove fallisce la maggior parte delle PMI). L'auditor avrebbe però comunque dovuto verificare due cose che il software non fornisce: alcuni atti formali umani (verbale del riesame di direzione, programma e report degli audit interni) e soprattutto che i controlli tecnici (backup, antivirus, vulnerability/pentest, reti, fisici) funzionino davvero sull'infrastruttura.

Il software è un system-of-record + gestione del SGSI: tiene registri, SoA, ruoli, evidenze. Non esegue i controlli tecnici e non scrive da solo le policy (le bozza con AI, ma vanno riviste e approvate).

Copertura per le 28 clausole obbligatorie (4–10)

~13 PIENO, ~11 PARZIALE, 1 assente, ~3 fuori-scope.

• PIENO (il software produce/conserva l'artefatto): 4.1 contesto, 4.2 parti interessate (anche col registro stakeholder + matrice Mendelow), 4.3 scope, 4.4 ISMS, 5.3 ruoli (RACI), 6.1.1/6.1.2 rischi, 6.1.3.d SoA (93 controlli con stato+motivazione, derivato da NIS2 — punto di forza), 7.2 competenze, 7.3 formazione/awareness, 7.5 controllo documenti+versioni, 8.2/8.3 risultati rischio, 10.2 NC/azioni correttive (con root-cause).
• PARZIALE (il software struttura/traccia, ma l'atto formale è umano): 5.1 leadership, 5.2 policy (bozza+versioni, ma il testo va approvato), 6.1.3 approvazione direzione del piano trattamento, 6.2 obiettivi, 7.4 comunicazioni, 8.1 pianificazione operativa, 9.1 KPI di efficacia, 9.2 audit interni, 9.3 riesame direzione, 10.1 miglioramento.
• ASSENTE: 6.3 pianificazione delle modifiche al SGSI (nessun artefatto dedicato).

Annex A (93 controlli): documentare ≠ implementare

Il software copre al 100% il lato SoA/evidenza di tutti i 93 controlli (riga SoA con applicabilità, motivazione, stato, upload evidenze, mapping da NIS2). Ma:

• A.5 Organizzativi (37) — copertura ALTA: molti controlli sono un modulo (asset A.5.9, fornitori/cloud A.5.19–5.23, incidenti A.5.24–5.28, policy A.5.1/5.36/5.37, requisiti legali A.5.31 con feed+ACK, protezione registrazioni A.5.33 con audit hash-chain).
• A.6 Persone (8) — MEDIO-ALTA: awareness/formazione e segnalazione eventi coperti; screening/contratti/NDA/disciplinare restano atti HR/legali fuori software.
• A.7 Fisici (14) — bassa come esecuzione: il software conserva solo SoA + evidenze (registri accessi, contratti vigilanza…); i controlli fisici sono reali, non software.
• A.8 Tecnologici (34) — media come evidenza, bassa come esecuzione: backup, antivirus, vuln management/pentest, crittografia/chiavi, reti/firewall, monitoraggio, sviluppo sicuro sono infrastruttura IT — il software ne tiene l'evidenza, non li esegue.

Registro Documenti & Registrazioni (38 voci obbligatorie)

• ~22 generati/conservati dal software (system-of-record): scope, policy (versioni), obiettivi, SoA, risultati e trattamento rischi, competenze, formazione, controllo documenti, inventario asset, NC/AC, log eventi (hash-chain), evidenze, export certificato con SHA-256.
• ~9 strutturati ma con output umano: verbale riesame direzione, procedura+programma+report audit interni, KPI 9.1, comunicazioni 7.4, pianificazione operativa.
• ~7 da produrre fuori dal prodotto: pianificazione modifiche (6.3), contratti/NDA fornitori, procedura crittografia/chiavi, procedure accessi, test BCP/DRP, pentest, change/backup test (per questi il software offre lo slot SoA + upload evidenza, ma il documento nasce fuori).

Stima di copertura realistica

• Gestione/documentazione del SGSI: ~70–75% pieno, il resto strutturato → lo scheletro documentale sarebbe stato presentabile in un colpo solo.
• Implementazione dei controlli tecnici (gran parte A.7/A.8): ~10–15% → resta infrastruttura reale di Agile.

I 5 gap dove il software NON basta

1. Verbale del riesame di direzione (9.3) — pianificato/tracciato, ma il verbale è documento umano (migliorabile come funzione di prodotto: template "verbale riesame").
2. Programma e report degli audit interni (9.2) — manca un modulo "internal audit" dedicato (ci sono evidenze e log, non il ciclo).
3. Controlli tecnici A.8 reali (backup, antivirus, vuln/pentest, crittografia, reti, monitoraggio) — infrastruttura IT.
4. Controlli fisici A.7 — perimetri, accessi, ambientali.
5. KPI di efficacia (9.1) e pianificazione modifiche (6.3) — il software misura l'avanzamento %, non l'efficacia con target/metodo; 6.3 non ha artefatto.

Caveat onesti

• Aver popolato i moduli il giorno prima ≠ SGSI maturo: la certificazione vuole evidenza operativa nel tempo (cicli di audit interno, un riesame, NC trattate, log accumulati).
• Le policy/procedure vanno redatte e approvate (l'AI bozza con disclaimer di revisione umana obbligatoria).
• ISO 27001 è volontaria (best practice), non un obbligo di legge: per Agile gli obblighi vincolanti restano NIS2 / D.Lgs. 138/2024 / ACN. Il prodotto lo dichiara correttamente ovunque citi l'ISO.

In una frase

Con NIS2 Agile saremmo arrivati all'audit con la parte documentale e gestionale del SGSI sostanzialmente pronta e ben organizzata (SoA, rischi, NC/AC, formazione, evidenze, audit-trail immutabile); avremmo dovuto aggiungere il verbale del riesame, il programma degli audit interni e, soprattutto, dimostrare che i controlli tecnici girano davvero — cosa che nessun software di compliance esegue al posto dell'IT.

Opportunità di prodotto (per il roadmap NIS2 Agile): aggiungere modulo Audit interni (programma+checklist+report) e Verbale riesame direzione chiuderebbe i 2 gap gestionali principali e renderebbe il prodotto "audit-ready" quasi end-to-end sul lato SGSI.