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

[DOCS] guida: fix ⚠️ review (cap-7 un mese/dies-a-quo/Nuovo Incidente, cap-5 maturita 0-5, cap-6 aggiornamento=buona pratica non art., cap-13 whistleblowing art.12+D.Lgs.24/2023) + 2o bottone questionario fornitore (dettaglio)

Browse Source 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
DevEnv nis2-agile
2026-05-31 08:20:19 +02:00
co-authored by Claude Opus 4.8
parent 5ff58aeceb
commit d11603a69d
2 changed files with 16 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
public/guida.html
+12 -10
View File
@@ -409,7 +409,7 @@
<ol class="step-list">
<li>Vai su <strong>Gap Analysis</strong> e clicca "Nuovo Assessment".</li>
<li>Rispondi alle 80 domande (sei modalità: implementato / parziale / non implementato / non applicabile).</li>
<li>Per ogni risposta, indica il <strong>livello di maturità</strong> (1–5).</li>
<li>Per ogni risposta, indica il <strong>livello di maturità</strong> (0–5).</li>
<li>Salva: puoi continuare in più sessioni.</li>
<li>Quando finisci, clicca <strong>"Analisi AI"</strong> per ricevere raccomandazioni prioritarie.</li>
</ol>
@@ -496,9 +496,11 @@
</ol>
<div class="norm-box">
<span class="article-tag">Art. 21 (2)(a)</span>
Le politiche di analisi dei rischi e di sicurezza dei sistemi informatici devono essere documentate,
approvate dagli organi di vertice, e aggiornate almeno una volta l'anno.
<span class="article-tag">Art. 21 (2)(a) + Art. 20</span>
Le politiche di analisi dei rischi e di sicurezza dei sistemi informatici devono essere documentate
e <strong>approvate dagli organi di amministrazione</strong> (art. 20). L'aggiornamento periodico
(es. almeno annuale) è una <em>buona pratica raccomandata</em>, non una cadenza fissata
letteralmente dall'art. 21.
</div>
<h3>Analisi quantitativa FAIR (vista "Quantitativo")</h3>
@@ -577,22 +579,22 @@
applicate, stima impatto.</p>
</div>
<div class="pillar-card">
<h4><span class="pillar-num">30d</span> Relazione finale <span style="font-weight:400;color:#64748b;">(final report)</span></h4>
<h4><span class="pillar-num">1 mese</span> Relazione finale <span style="font-weight:400;color:#64748b;">(final report)</span></h4>
<p>Analisi completa: causa radice, azioni correttive, lezioni apprese, raccomandazioni per il futuro.
<em>Termine normativo: relazione finale, entro 1 mese (art. 23 D.Lgs. 138/2024).</em></p>
<em>Termine normativo: relazione finale entro <strong>un mese dalla notifica</strong> (cioè dal momento delle 72h), non dall'incidente — art. 23 D.Lgs. 138/2024.</em></p>
</div>
<div class="example-box">
<strong>Esempio.</strong> Aurora Sanità subisce un DDoS sul portale prenotazioni alle 09:00 di lunedì.
Sono colpiti 8.500 utenti per 4 ore → significativo. Workflow: Early Warning entro martedì 09:00 →
Notifica entro giovedì 09:00 → Final Report entro mercoledì 28 (30 giorni dopo).
Sono colpiti 8.500 utenti per 4 ore → significativo. Workflow: preallarme entro martedì 09:00 →
notifica entro giovedì 09:00 → relazione finale entro un mese <em>dalla notifica</em> (giovedì + 1 mese).
</div>
<h3>Come si fa nella piattaforma</h3>
<ol class="step-list">
<li>Vai su <strong>Incidenti</strong> e clicca "Registra Incidente".</li>
<li>Vai su <strong>Incidenti</strong> e clicca "+ Nuovo Incidente".</li>
<li>Compila titolo, classificazione, severità, ora di rilevazione.</li>
<li>Il sistema calcola automaticamente le 3 scadenze (24h/72h/30d).</li>
<li>Il sistema calcola automaticamente le 3 scadenze (24h / 72h / 1 mese).</li>
<li>Quando arriva il momento, usa i bottoni <strong>"Invia Early Warning"</strong>,
<strong>"Invia Notifica"</strong> e <strong>"Invia Final Report"</strong>: le email partono verso
l'indirizzo CSIRT configurato.</li>