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.