[DOCS] Valutazione copertura NIS2 Agile vs audit ISO 27001:2022 (per direzione Agile) + checklist sorgente

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-17 06:49:48 +02:00
parent 3d80aa8c57
commit fc1b424283
3 changed files with 49 additions and 0 deletions
@@ -0,0 +1,49 @@
 # 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.