AdminGit2026/nis2-agile
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[DOCS] Rischi 12 colonne: KB ARIA (inerente/residuo + eccezione conformità) + manuale d'uso

Browse Source 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
DevEnv nis2-agile
2026-07-30 10:54:54 +02:00
co-authored by Claude Opus 4.8
parent 8a0bc5ca39
commit ea57928226
2 changed files with 114 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/kb/RISCHI_MODELLO.md
+19 -4
View File
@@ -12,10 +12,25 @@ Nella pagina Rischi i rischi corrispondono ai **requisiti del framework di sicur
## Codifica
Ogni rischio ha un codice **RSK-‹misura›Com.‹n›** (es. `RSK-GV.OC-04Com.1`): è una **codifica INTERNA di NIS2 Agile**. La parte ‹misura› (es. GV.OC-04) è il codice della misura del **Framework Nazionale** richiamato dalla Determinazione ACN 164179/2025; ‹Com.n› identifica il comma del requisito. **RSK-… NON è un codice ufficiale ACN.**
## Valutazione e matrice 5×5
Ogni rischio-requisito può essere valutato (tasto **"Valuta"**, riservato ai profili che valutano: super_admin/org_admin/compliance_manager) con **Probabilità** (1-5) e **Impatto** (1-5). Il prodotto P×I posiziona il rischio nella **matrice 5×5**, che è sempre visibile. La matrice **esclude i requisiti "non applicabili"**.
- Probabilità = probabilità che la minaccia si concretizzi sfruttando la carenza; Impatto = conseguenze della non conformità/incidente. Non è "la probabilità del requisito".
- La matrice e il metodo probabilità×impatto sono uno **strumento di rappresentazione**, NON un obbligo: l'**art. 24 del D.Lgs. 138/2024** richiede un'analisi dei rischi proporzionata e con approccio **multirischio (all-hazard)**, senza imporre una metodologia specifica.
## Tabella a 12 colonne: rischio INERENTE e RESIDUO (aggiornamento Modulo Azioni)
La tabella dei rischi-da-requisito ha **12 colonne**:
1. **Codice rischio** (RSK-…): cliccabile, apre la voce in **Misure e Requisiti**.
2. **Descrizione rischio**: il rischio di default associato al requisito nel framework (campo `risk_descr`).
3-5. **VALUTAZIONE RISCHIO INERENTE** (prima del trattamento): Probabilità (1-5), Impatto (1-5), Valutazione (= P×I, 1-25).
6. **Alert**: dipende dal punteggio inerente — 15-25 *Azione Prioritaria*, 9-14 *Azione Critica*, 3-8 *Azione Necessaria*, 1-2 *Azione Suggerita*. Cliccando si vedono/creano le **azioni** su quel rischio.
7. **Rischio Inerente**: "Valutato" quando inerente è compilato.
8-10. **VALUTAZIONE RISCHIO RESIDUO** (dopo il trattamento): Probabilità, Impatto, Valutazione.
11. **Esito residuo**: *Rivalutare* (punteggio residuo 9-25) o *Adeguato* (1-8).
12. **Rischio Residuo**: "Valutato" + link per aggiornare **esplicitamente** lo stato di conformità del requisito.
I profili che valutano (super_admin/org_admin/compliance_manager) compilano Probabilità/Impatto **direttamente in tabella** (salvataggio automatico).
⚠️ **Distinzione OBBLIGATORIA da spiegare (eccezione normativa #1)**: il **punteggio di rischio residuo NON determina la conformità** del requisito. La **conformità** dipende dall'**attuazione della misura e dalle evidenze** (non da un numero); si aggiorna in modo esplicito dal link "stato". Sono due piani distinti: *punteggio di rischio* ≠ *stato di conformità*. Un requisito può essere conforme e avere comunque rischio residuo alto (o viceversa). Non dire mai "sei conforme perché il rischio è basso".
- Rischio **inerente** = rischio di non conformità **prima** del trattamento; **residuo** = **dopo** il trattamento (framing coerente con "rischio di non conformità"). "Inerente/residuo" è impostazione **ISO 27005 / ISO 27001 §6.1.3** (accettazione del rischio residuo dal risk owner): **best practice**, non obbligo NIS2.
- Le **soglie** dell'Alert e il metodo P×I sono una **scelta metodologica** dell'organizzazione (rif. ISO/IEC 27001 §6.1.2), **strumento di rappresentazione, NON obbligo**: l'**art. 24 del D.Lgs. 138/2024** richiede un'analisi dei rischi proporzionata e con approccio **multirischio (all-hazard)**, senza imporre una metodologia specifica.
- **Impatto** è una scala di severità 1-5 (non euro). La matrice 5×5 (sempre visibile) esclude i requisiti "non applicabili".
- Dall'Alert si possono creare **azioni** sul rischio (seme del futuro Modulo Azioni: registro azioni, audit, KPI, budget).
## Rischi aggiuntivi (all-hazard)
Oltre ai rischi derivati dai requisiti, i profili **amministrativi** possono aggiungere "Rischi aggiuntivi" non coperti da un singolo requisito (minacce fisiche, catena di fornitura, eventi naturali, errore umano). Serve a coprire l'approccio **multirischio/all-hazard** richiesto dall'art. 24. Gli utenti non amministrativi non vedono i tasti di inserimento.