From d11603a69d4921bba8a440359d0aabc7e662a3ff Mon Sep 17 00:00:00 2001 From: DevEnv nis2-agile Date: Sun, 31 May 2026 08:20:19 +0200 Subject: [PATCH] =?UTF-8?q?[DOCS]=20guida:=20fix=20=E2=9A=A0=EF=B8=8F=20re?= =?UTF-8?q?view=20(cap-7=20un=20mese/dies-a-quo/Nuovo=20Incidente,=20cap-5?= =?UTF-8?q?=20maturita=200-5,=20cap-6=20aggiornamento=3Dbuona=20pratica=20?= =?UTF-8?q?non=20art.,=20cap-13=20whistleblowing=20art.12+D.Lgs.24/2023)?= =?UTF-8?q?=20+=202o=20bottone=20questionario=20fornitore=20(dettaglio)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- public/guida.html | 22 ++++++++++++---------- public/supply-chain.html | 4 ++++ 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/public/guida.html b/public/guida.html index 419abef..0c5ac6f 100644 --- a/public/guida.html +++ b/public/guida.html @@ -409,7 +409,7 @@
  1. Vai su Gap Analysis e clicca "Nuovo Assessment".
  2. Rispondi alle 80 domande (sei modalità: implementato / parziale / non implementato / non applicabile).
    3. -
  3. Per ogni risposta, indica il livello di maturità (1–5).
    4. +
  4. Per ogni risposta, indica il livello di maturità (0–5).
  5. Salva: puoi continuare in più sessioni.
  6. Quando finisci, clicca "Analisi AI" per ricevere raccomandazioni prioritarie.
@@ -496,9 +496,11 @@
- Art. 21 (2)(a) - 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. + Art. 21 (2)(a) + Art. 20 + Le politiche di analisi dei rischi e di sicurezza dei sistemi informatici devono essere documentate + e approvate dagli organi di amministrazione (art. 20). L'aggiornamento periodico + (es. almeno annuale) è una buona pratica raccomandata, non una cadenza fissata + letteralmente dall'art. 21.

Analisi quantitativa FAIR (vista "Quantitativo")

@@ -577,22 +579,22 @@ applicate, stima impatto.

-

30d Relazione finale (final report)

+

1 mese Relazione finale (final report)

Analisi completa: causa radice, azioni correttive, lezioni apprese, raccomandazioni per il futuro. - Termine normativo: relazione finale, entro 1 mese (art. 23 D.Lgs. 138/2024).

+ Termine normativo: relazione finale entro un mese dalla notifica (cioè dal momento delle 72h), non dall'incidente — art. 23 D.Lgs. 138/2024.

Esempio. 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 dalla notifica (giovedì + 1 mese).

Come si fa nella piattaforma

    -
  1. Vai su Incidenti e clicca "Registra Incidente".
    2. +
  2. Vai su Incidenti e clicca "+ Nuovo Incidente".
  3. Compila titolo, classificazione, severità, ora di rilevazione.
    4. -
  4. Il sistema calcola automaticamente le 3 scadenze (24h/72h/30d).
    5. +
  5. Il sistema calcola automaticamente le 3 scadenze (24h / 72h / 1 mese).
  6. Quando arriva il momento, usa i bottoni "Invia Early Warning", "Invia Notifica" e "Invia Final Report": le email partono verso l'indirizzo CSIRT configurato.
    7. diff --git a/public/supply-chain.html b/public/supply-chain.html index 92421a3..00ca5f1 100644 --- a/public/supply-chain.html +++ b/public/supply-chain.html @@ -737,6 +737,10 @@ Valuta Fornitore +