[CLIENT] Nuova Agile: consolidamento documentale lean (36 -> 12) + archiviazione originali

Approccio ISO 27001 agile/lean: i 36 documenti v1.0 sono fusi per tema in 12 documenti consolidati v2.0 (Manuale, 6 politiche, 5 procedure), pubblicati. I 36 originali sono ARCHIVIATI (storico preservato, non cancellati). Idempotenza ignora gli archiviati (fix collisione titolo procedura incidenti).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
DevEnv nis2-agile
2026-06-20 15:33:41 +02:00
co-authored by Claude Opus 4.8
parent 6ca78f9669
commit c05520c7da
13 changed files with 1070 additions and 0 deletions
+67
View File
@@ -0,0 +1,67 @@
<!--META|doc_type=manuale_sgsi|title=Manuale del Sistema di Gestione per la Sicurezza delle Informazioni (approccio agile)|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>Il presente Manuale descrive il Sistema di Gestione per la Sicurezza delle Informazioni (SGSI) di <strong>Nuova Agile Technology srl</strong> (di seguito "l'Organizzazione" o "l'Azienda") e ne definisce l'impostazione secondo un approccio <strong>agile/lean</strong>, coerente con un'azienda cloud-native senza sede fisica. È progettato e mantenuto in conformità a <strong>ISO/IEC 27001:2022</strong>, integrata dalle linee guida <strong>ISO/IEC 27017:2015</strong> (controlli di sicurezza per i servizi cloud) e <strong>ISO/IEC 27018:2019</strong> (protezione dei dati personali nel cloud pubblico). Il Manuale è il documento di vertice della struttura documentale del SGSI: ne illustra contesto, leadership, ambito, approccio al rischio e miglioramento continuo, e orienta tutti gli altri documenti del Sistema.</p>
<h2>2. Ambito del SGSI</h2>
<p>Il SGSI si applica a tutti i processi di progettazione, sviluppo, erogazione e supporto dei servizi e prodotti software dell'Azienda, alle informazioni trattate (proprie e dei clienti, inclusi i dati personali e le credenziali aziendali) e a tutto il personale (dipendenti e collaboratori). Le due linee di business coperte sono:</p>
<ul>
<li><strong>Prodotti software in licenza d'uso</strong> installati on-premise sui server <em>dei clienti</em>;</li>
<li><strong>Servizi SaaS multi-tenant</strong> erogati in cloud.</li>
</ul>
<p>L'infrastruttura è <strong>interamente in cloud</strong> presso <strong>Aruba S.p.A.</strong> (data center in Italia) e <strong>Hetzner Online GmbH</strong> (Germania, UE), con utilizzo di piattaforme di intelligenza artificiale tramite API (es. Anthropic). <strong>L'Azienda non gestisce alcun server in sede</strong> e non esiste un perimetro fisico aziendale: niente data center proprietario. L'ambito si definisce quindi sui <em>dati, gli account e i dispositivi</em>, non sui luoghi. Le postazioni di lavoro sono esclusivamente <strong>PC portatili cifrati</strong>. La sicurezza fisica dei data center è ereditata dai fornitori cloud secondo il modello di <em>responsabilità condivisa</em> (vedi A.5.23).</p>
<h2>3. Contesto dell'Organizzazione</h2>
<p>Nuova Agile Technology srl è una software house italiana composta da circa 12 persone (9 dipendenti, 2 collaboratori esterni a P.IVA e la Presidente). I principali fattori di contesto interni ed esterni sono: dipendenza da fornitori cloud e da provider AI, requisiti contrattuali di sicurezza imposti dai clienti (supply chain), obblighi GDPR sui dati personali trattati nel SaaS e il quadro normativo NIS2. Le parti interessate rilevanti includono clienti, fornitori cloud/AI (sub-responsabili), personale, Autorità di controllo (Garante Privacy, ACN) e investitori.</p>
<h2>4. Principi dell'approccio agile/lean</h2>
<ul>
<li><strong>Scope stretto</strong>: si protegge ciò che conta (codice, dati clienti, credenziali cloud), senza estendere controlli a perimetri inesistenti.</li>
<li><strong>Documentazione minima e viva</strong>: regole brevi e pratiche, aggiornate spesso; niente burocrazia. Ogni documento è uno strumento operativo, non un adempimento.</li>
<li><strong>Responsabilità condivisa col cloud</strong>: la sicurezza fisica dei data center e gran parte dell'infrastruttura sono in capo ad Aruba/Hetzner; l'Azienda presidia account, accessi, configurazioni, dati e dispositivi (A.5.23, ISO 27017/27018).</li>
<li><strong>Secure-by-default</strong>: MFA ovunque, cifratura di default, SSO, account aziendali gestiti centralmente.</li>
<li><strong>Evidenze automatizzate</strong>: la piattaforma SGSI registra controlli periodici e audit; si privilegiano prove generate dal sistema rispetto a registri manuali.</li>
</ul>
<h2>5. Il modello Work-from-Anywhere</h2>
<p>Il luogo di lavoro può essere <strong>qualsiasi</strong>: casa, coworking, viaggio, all'aperto. La sicurezza non dipende dal luogo ma dal modo di lavorare:</p>
<ul>
<li>Ogni collaboratore usa <strong>un portatile e uno smartphone aziendali dedicati</strong>, cifrati e gestiti (MDM), con <strong>separazione netta tra strumenti privati e di lavoro</strong>.</li>
<li><strong>Posta e servizi sono aziendali</strong>, amministrati dalla società: niente account personali per il lavoro.</li>
<li>Le <strong>chiavi/credenziali di accesso al cloud</strong> hanno copie di sicurezza controllate (key escrow cifrato), così lo smarrimento di un dispositivo non causa perdita di accesso.</li>
</ul>
<p>Controlli ISO collegati a questo modello: <strong>A.6.7</strong> (lavoro a distanza), <strong>A.7.9</strong> (sicurezza degli asset fuori sede), <strong>A.8.1</strong> (dispositivi endpoint), <strong>A.5.10</strong> (uso accettabile), <strong>A.5.23</strong> (sicurezza nei servizi cloud).</p>
<h2>6. Ruoli e responsabilità (organigramma SGSI)</h2>
<table>
<tr><th>Ruolo</th><th>Persona</th><th>Responsabilità principali</th></tr>
<tr><td>Alta Direzione / Presidente</td><td><strong>Silvia Garretto</strong></td><td>Leadership, approvazione politiche, assegnazione risorse, riesame di direzione</td></tr>
<tr><td>Responsabile SGSI (RSGSI)</td><td><strong>Massimo Tagliavini</strong></td><td>Gestione operativa del SGSI, risk management, audit interni, documentazione</td></tr>
<tr><td>Responsabile IT e Sicurezza</td><td><strong>Simon Fattori</strong></td><td>Sicurezza tecnica, gestione cloud, controllo accessi, gestione incidenti</td></tr>
<tr><td>Referente Protezione Dati (DPO)</td><td><em>Consulente esterno (da nominare)</em></td><td>Conformità GDPR, pareri sul trattamento dei dati personali</td></tr>
</table>
<p>L'organigramma di dettaglio e la matrice RACI sono mantenuti nel registro dei ruoli del SGSI.</p>
<h2>7. Leadership e impegno della Direzione</h2>
<p>L'Alta Direzione, nella persona della Presidente, garantisce l'impegno verso il SGSI mediante: definizione e approvazione della Politica per la Sicurezza delle Informazioni; integrazione del SGSI nei processi aziendali; messa a disposizione delle risorse; promozione del miglioramento continuo; comunicazione dell'importanza della sicurezza al personale. Tali impegni soddisfano i requisiti della clausola 5 di ISO/IEC 27001 e i controlli <strong>A.5.1</strong> (Politiche per la sicurezza delle informazioni) e <strong>A.5.4</strong> (Responsabilità della direzione).</p>
<h2>8. Struttura documentale del SGSI</h2>
<p>La documentazione è organizzata su livelli gerarchici: (1) Manuale SGSI e Politica generale; (2) Politiche tematiche (controllo accessi, crittografia, classificazione, uso accettabile, lavoro da remoto e mobilità, dispositivi, posta e servizi, ecc.); (3) Procedure e istruzioni operative (incl. procedura chiavi cloud); (4) Registrazioni ed evidenze. Tutti i documenti sono soggetti a controllo di versione, approvazione e revisione periodica (A.5.37) e discendono dai principi agile/lean qui esposti.</p>
<h2>9. Approccio al rischio</h2>
<p>Il SGSI adotta un processo di valutazione e trattamento del rischio basato su ISO/IEC 27005, che prevede identificazione degli asset informativi e dei relativi rischi, analisi di probabilità e impatto, definizione del rischio accettabile e selezione delle opzioni di trattamento (mitigazione, trasferimento, accettazione, eliminazione). Particolare attenzione è posta ai rischi della <strong>supply chain cloud/AI</strong> e ai rischi sui dati personali. Gli esiti sono documentati nel Registro dei Rischi e riferiti alla <strong>Dichiarazione di Applicabilità (SoA)</strong>.</p>
<h2>10. Dichiarazione di Applicabilità (SoA)</h2>
<p>La SoA elenca i controlli dell'<strong>Annex A di ISO/IEC 27001:2022</strong> (93 controlli su 4 temi: organizzativi, persone, fisici, tecnologici), integrati dai controlli aggiuntivi di <strong>ISO/IEC 27017</strong> e <strong>27018</strong> per i servizi cloud e i dati personali. Per ciascun controllo sono indicati applicabilità, stato di implementazione e giustificazione delle esclusioni.</p>
<h2>11. Caveat sulla classificazione NIS2</h2>
<p>L'Azienda si autoclassifica <strong>in via PRELIMINARE</strong> come soggetto NIS2 "<strong>IMPORTANTE</strong>". Tuttavia l'Azienda è <strong>SOTTO le soglie dimensionali ordinarie</strong> (≥50 addetti oppure fatturato/bilancio >10 M€): la qualifica deve essere <strong>CONFERMATA dalla Direzione e dal Legale</strong>, ed eventualmente da ACN, in funzione del fatturato e della categoria di attività (provider di servizi cloud). L'adozione del SGSI è guidata anche dai <strong>requisiti di supply chain dei clienti</strong>. Il quadro di riferimento è la Direttiva (UE) 2022/2555, recepita in Italia dal <strong>D.Lgs. 138/2024</strong>: art.23 (governance e ruolo degli organi di gestione), art.24 (misure di gestione del rischio, equivalenti all'Art.21 della Direttiva), art.25 (obblighi di notifica al CSIRT, con tempistiche di pre-notifica entro 24 ore, notifica entro 72 ore e relazione finale entro 1 mese). Le misure di dettaglio sono definite dalle Determinazioni ACN. <strong>Le norme ISO citate sono buone prassi, non obblighi di legge.</strong></p>
<h2>12. Miglioramento continuo</h2>
<p>Il SGSI segue il ciclo PDCA. Sono previsti audit interni programmati, riesami di direzione almeno annuali, gestione delle non conformità e azioni correttive (NCR/CAPA), e monitoraggio di indicatori di prestazione. Gli esiti alimentano il piano di miglioramento.</p>
<h2>13. Registrazioni ed evidenze</h2>
<p>Verbali di riesame di direzione, registro dei rischi, SoA, rapporti di audit, registro delle non conformità, log di sicurezza e registro degli incidenti.</p>
<h2>14. Riesame e versionamento</h2>
<p>Documento di vertice approvato dalla Presidente. Documento vivo, riesaminato almeno annualmente o a fronte di cambiamenti significativi del contesto; versione tracciata nella piattaforma SGSI.</p>
+93
View File
@@ -0,0 +1,93 @@
<!--META|doc_type=procedura_continuita|title=Procedura di Continuità Operativa, Backup e Ripristino|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>La presente procedura definisce in modo unitario come <strong>Nuova Agile Technology srl</strong> (di seguito "l'Azienda") assicura la <strong>continuità operativa</strong> dei propri servizi critici, esegue e protegge i <strong>backup</strong> e garantisce il <strong>ripristino</strong> dei dati e dei servizi in caso di evento avverso (guasto cloud, attacco — es. ransomware —, errore, cancellazione accidentale, indisponibilità di personale). Considerata l'infrastruttura <strong>interamente in cloud</strong> e l'assenza di server in sede, l'obiettivo è garantire backup affidabili, capacità di ripristino del <strong>SaaS multi-tenant</strong> e dei dati dei clienti, e la continuità del lavoro di un team piccolo che opera da <strong>PC portatili cifrati</strong>, nel rispetto degli obiettivi di tempo (RTO) e di perdita dati (RPO) concordati. La procedura supporta gli obblighi di <strong>continuità operativa, gestione del backup e gestione delle crisi</strong> previsti dalle misure dell'<strong>art. 24 del D.Lgs. 138/2024</strong> (NIS2).</p>
<h2>2. Ambito</h2>
<p>Si applica alla disponibilità del servizio <strong>SaaS multi-tenant</strong>, ai database e ai dati dei clienti, al codice sorgente e alle configurazioni dei prodotti, alla posta e ai documenti aziendali, agli ambienti di sviluppo e rilascio e alla capacità di lavoro del team. L'infrastruttura è ospitata su <strong>Aruba S.p.A. (Italia)</strong> e <strong>Hetzner (Germania, UE)</strong>, nel rispetto del modello di responsabilità condivisa. Riguarda tutto il personale (9 dipendenti, 2 collaboratori esterni a P.IVA) e i fornitori cloud. Gli <strong>endpoint</strong> (PC portatili cifrati) non conservano dati critici come unica copia: i dati di lavoro risiedono nei servizi cloud aziendali. <strong>Non esistono backup su nastro né server in sede</strong>; gli scenari considerati riguardano indisponibilità di un provider o di una regione cloud, attacchi, errori gravi e indisponibilità del personale, non scenari di sala server in sede (assente per architettura).</p>
<h2>3. Riferimenti</h2>
<ul>
<li><strong>ISO/IEC 27001:2022</strong> – A.5.29 (sicurezza delle informazioni durante un'interruzione), A.5.30 (pronto intervento ICT per la continuità operativa), A.8.13 (backup delle informazioni), A.8.14 (ridondanza delle strutture di elaborazione), A.8.24 (uso della crittografia).</li>
<li><strong>ISO/IEC 27017:2015</strong> – continuità e responsabilità condivisa nei servizi cloud.</li>
<li><strong>ISO/IEC 27018:2019</strong> – conservazione, restituzione e ripristino dei dati personali (PII) nel cloud.</li>
<li><strong>D.Lgs. 4 settembre 2024, n. 138</strong> (NIS2): art. 24 (misure di gestione del rischio, inclusi continuità operativa, backup e gestione delle crisi); art. 25 (notifica degli incidenti significativi).</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<table>
<tr><th>Ruolo</th><th>Persona</th><th>Responsabilità</th></tr>
<tr><td>Direzione / Presidente</td><td><strong>Silvia Garretto</strong></td><td>Approva strategia di continuità e backup, gli obiettivi RTO/RPO; attiva lo stato di crisi, decide la comunicazione esterna e l'allocazione delle risorse.</td></tr>
<tr><td>RSGSI</td><td><strong>Massimo Tagliavini</strong></td><td>Mantiene la procedura e il piano BCP/DR, coordina i test di ripristino e le esercitazioni, ne verifica e documenta gli esiti e i riesami.</td></tr>
<tr><td>Resp. IT/Sicurezza</td><td><strong>Simon Fattori</strong></td><td>Configura, esegue e monitora i backup; gestisce ridondanza e immutabilità; esegue ripristini e test, e il recovery tecnico dei servizi e dei dati secondo il piano.</td></tr>
<tr><td>DPO esterno</td><td><em>Consulente esterno</em></td><td>Valuta gli impatti sui dati personali negli scenari di indisponibilità o perdita.</td></tr>
<tr><td>Tutto il personale</td><td>—</td><td>Segue le procedure di backup degli strumenti di lavoro e collabora alla continuità.</td></tr>
</table>
<h2>5. Strategia di continuità</h2>
<h3>5.1 Analisi di impatto e obiettivi (RTO/RPO)</h3>
<p>I servizi critici (in primis il SaaS e i dati dei clienti) sono individuati tramite <strong>Business Impact Analysis (BIA)</strong>; per ciascuno si definiscono <strong>RTO</strong> (tempo massimo di ripristino) e <strong>RPO</strong> (massima perdita di dati tollerata), approvati dalla Direzione. I valori puntuali sono definiti nelle procedure operative e nel piano BCP/DR <strong>[DA VERIFICARE]</strong>. Si identificano le dipendenze critiche: provider cloud, provider AI, DNS, posta, gestore password.</p>
<h3>5.2 Strategie di continuità e ridondanza</h3>
<ul>
<li>Si privilegiano architetture <strong>ridondate</strong> e, ove fattibile, la possibilità di ripristino su una <strong>regione/fornitore alternativo</strong> (A.8.14), sfruttando i backup cloud cifrati e, ove disponibile, immutabili.</li>
<li>Si valutano le garanzie di disponibilità (SLA) dei provider e si predispongono misure per ridurre l'impatto di un'indisponibilità prolungata, inclusa la <strong>portabilità dei dati</strong>; la ripartizione delle responsabilità di continuità tra azienda e fornitore è documentata (modello di responsabilità condivisa, ISO 27017).</li>
<li>Essendo il team interamente remoto su portatili cifrati, la <strong>continuità del lavoro</strong> è intrinsecamente resiliente all'indisponibilità di una singola sede; i dati di lavoro essenziali sono sincronizzati sui servizi cloud aziendali per evitarne la perdita in caso di guasto o furto del dispositivo.</li>
</ul>
<h3>5.3 Continuità delle persone chiave</h3>
<p>Trattandosi di un team piccolo, sono identificate le competenze critiche e previste misure di ridondanza minime (documentazione, accessi di backup custoditi in sicurezza, condivisione delle conoscenze) per evitare single point of failure umani.</p>
<h2>6. Backup (regola 3-2-1 su cloud)</h2>
<h3>6.1 Pianificazione</h3>
<ol>
<li>Per ciascun servizio critico si definiscono <strong>RPO</strong> e <strong>RTO</strong> coerenti con la BIA, approvati dalla Direzione.</li>
<li>Si adotta lo schema di riferimento <strong>3-2-1</strong> per quanto applicabile in cloud: più copie, su servizi/regioni distinti (preferibilmente data center diversi nell'UE), con almeno una copia logicamente separata e protetta da modifiche.</li>
</ol>
<h3>6.2 Esecuzione</h3>
<ol>
<li>I backup dei database SaaS, dei dati dei clienti e del codice sorgente sono <strong>automatici e schedulati</strong> (frequenza coerente con l'RPO, di norma giornaliera).</li>
<li>Le copie sono <strong>cifrate</strong> a riposo (A.8.24) e conservate in cloud con accesso ristretto e <strong>MFA</strong>, con gli stessi controlli di accesso dei dati di produzione.</li>
<li>Ove disponibile si attiva l'<strong>immutabilità</strong> delle copie (protezione anti-ransomware) e la separazione delle credenziali di gestione dei backup.</li>
<li>Si applica una <strong>politica di retention e rotazione</strong> definita (copie giornaliere a breve termine e copie a più lunga conservazione), nel rispetto degli obblighi sui dati personali (minimizzazione e cancellazione sicura, A.8.13 / ISO 27018).</li>
</ol>
<h3>6.3 Monitoraggio</h3>
<ol>
<li>Il Resp. IT/Sicurezza verifica l'<strong>esito di ogni job</strong> di backup; i fallimenti generano un alert e una verifica entro le 24 ore lavorative successive.</li>
<li>Gli esiti negativi ricorrenti sono registrati come <strong>non conformità</strong> nel modulo NCR/CAPA della piattaforma.</li>
</ol>
<h2>7. Ripristino e test</h2>
<h3>7.1 Test di ripristino</h3>
<ul>
<li>Con cadenza <strong>almeno trimestrale</strong> si esegue un <strong>test di ripristino</strong> su un dato/servizio campione, verificando integrità e tempi rispetto a RTO/RPO. <strong>Un backup non testato non è considerato affidabile.</strong></li>
<li>L'esito è documentato; gli scostamenti attivano azioni correttive nel modulo NCR/CAPA.</li>
</ul>
<h3>7.2 Ripristino reale</h3>
<p>In caso di incidente, il ripristino è autorizzato e coordinato secondo la presente procedura: si privilegia una copia integra e verificata, si rispettano RTO/RPO e al termine si validano i dati ripristinati.</p>
<h2>8. Gestione della crisi (BCP/DR)</h2>
<h3>8.1 Attivazione e gestione</h3>
<ol>
<li>Al verificarsi di un evento grave, la Direzione (o suo delegato) <strong>attiva il piano</strong> e nomina i referenti.</li>
<li>Si attiva in parallelo la <strong>gestione degli incidenti</strong>; il Resp. IT/Sicurezza esegue il ripristino dei servizi e dei dati dalle copie integre, rispettando RTO/RPO.</li>
<li>Se l'evento configura un <strong>incidente significativo NIS2</strong> e l'Azienda è soggetto obbligato, si applicano gli obblighi di <strong>notifica al CSIRT Italia (ACN)</strong> ai sensi dell'art. 25 del D.Lgs. 138/2024: <strong>pre-allarme entro 24 ore</strong>, <strong>notifica completa entro 72 ore</strong>, <strong>relazione finale entro 1 mese</strong>.</li>
</ol>
<h3>8.2 Comunicazione</h3>
<p>Si comunica <strong>tempestivamente ai clienti impattati</strong> lo stato del disservizio e i tempi stimati di ripristino, in adempimento agli obblighi contrattuali di supply chain verso i clienti NIS2.</p>
<h3>8.3 Ritorno alla normalità</h3>
<p>Verificato il pieno ripristino, si dichiara la chiusura della crisi e si redige il rapporto di evento con le <strong>lezioni apprese</strong>, che aggiornano il piano e alimentano azioni correttive. Il piano BCP/DR è <strong>testato almeno una volta l'anno</strong> (esercitazione/simulazione).</p>
<h2>9. Controlli ISO collegati e riferimenti NIS2</h2>
<p>La procedura attua i controlli <strong>A.5.29, A.5.30, A.8.13, A.8.14, A.8.24</strong> di ISO/IEC 27001:2022 e i controlli cloud di ISO/IEC 27017/27018 per continuità, ripristino e protezione dei PII. Soddisfa le <strong>misure di gestione del rischio dell'art. 24 del D.Lgs. 138/2024</strong> in tema di backup, continuità e gestione delle crisi; quando l'interruzione configura un incidente significativo valgono le tempistiche di notifica dell'<strong>art. 25</strong>. Le evidenze dei test di ripristino dimostrano resilienza anche ai clienti NIS2 nell'ambito della supply chain.</p>
<h2>10. Registrazioni ed evidenze</h2>
<ul>
<li>Piano BCP/DR con BIA, RTO/RPO per servizio e dipendenze critiche.</li>
<li>Piano di backup; log/report di esecuzione e di esito dei job.</li>
<li>Rapporti dei test di ripristino trimestrali e delle esercitazioni annuali.</li>
<li>Rapporti degli eventi reali con lezioni apprese e comunicazioni ai clienti durante i disservizi.</li>
<li>Inventario dei servizi critici e relative dipendenze cloud.</li>
<li>Non conformità collegate a fallimenti di backup/ripristino (modulo NCR/CAPA).</li>
</ul>
<h2>11. Riesame e versionamento</h2>
<p>La procedura è riesaminata <strong>almeno annualmente</strong> o a fronte di un incidente significativo, di un test di ripristino con esito negativo o di cambiamenti dell'architettura cloud o dei requisiti RTO/RPO. È approvata dalla Direzione; le revisioni sono tracciate nel sistema documentale del SGSI a cura del RSGSI secondo la Procedura di Governance del SGSI.</p>
+118
View File
@@ -0,0 +1,118 @@
<!--META|doc_type=procedura_operativa_sviluppo|title=Procedura di Gestione Operativa e Sviluppo Sicuro|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>La presente procedura stabilisce come <strong>Nuova Agile Technology srl</strong> integra la sicurezza nel ciclo di vita dello sviluppo software (Secure SDLC), governa i cambiamenti ai propri sistemi, gestisce le vulnerabilità tecniche e le patch, e presidia logging e monitoraggio. L'obiettivo è garantire che i prodotti — sia in <strong>licenza d'uso installati sui server dei clienti (on-premise)</strong>, sia il <strong>SaaS multi-tenant in cloud</strong> — siano progettati, sviluppati, rilasciati e mantenuti in modo da ridurre vulnerabilità e proteggere i dati, e che ogni cambiamento avvenga in modo controllato e tracciabile. Soddisfa i requisiti di sicurezza nell'acquisizione, sviluppo e manutenzione previsti dall'<strong>art. 24 del D.Lgs. 138/2024</strong> (NIS2).</p>
<h2>2. Ambito</h2>
<p>Si applica a tutte le attività di analisi, progettazione, codifica, test, rilascio e manutenzione del software, e ai relativi cambiamenti, vulnerabilità, patch e log su: ambienti <strong>cloud</strong> (Aruba IT, Hetzner DE), configurazioni di rete e di sicurezza, servizi <strong>SaaS</strong> multi-tenant e prodotti <strong>on-premise</strong> presso i clienti, dipendenze e librerie di terze parti, pipeline di build/deploy, integrazioni con <strong>piattaforme AI</strong> via API (es. LLM Anthropic) ed <strong>endpoint</strong> (PC portatili cifrati). Riguarda tutto il personale tecnico (9 dipendenti, 2 collaboratori esterni a P.IVA) ed eventuali fornitori che contribuiscono allo sviluppo. L'attività si svolge esclusivamente da PC portatili cifrati, senza alcun server in sede.</p>
<h2>3. Riferimenti</h2>
<ul>
<li>ISO/IEC 27001:2022 – Annex A: A.5.7 (threat intelligence), A.8.7 (protezione dai malware), A.8.8 (gestione delle vulnerabilità tecniche), A.8.9 (gestione della configurazione), A.8.15 (logging), A.8.16 (monitoraggio), A.8.25–A.8.33 (sviluppo sicuro, requisiti applicazioni, architettura e codifica sicura, test, sviluppo esterno, separazione ambienti, gestione cambiamenti, dati di test), A.5.17 (autenticazione).</li>
<li>ISO/IEC 27017:2015 e ISO/IEC 27018:2019 – sicurezza dello sviluppo, dei cambiamenti e delle vulnerabilità nei servizi cloud e protezione dei PII (privacy by design).</li>
<li>D.Lgs. 4 settembre 2024, n. 138 (NIS2): art. 24 (sicurezza nell'acquisizione/sviluppo/manutenzione, gestione delle modifiche e divulgazione delle vulnerabilità) e art. 25 (notifica incidenti significativi).</li>
<li>Regolamento (UE) 2016/679 (GDPR), artt. 25 e 32 (privacy by design e by default, sicurezza del trattamento).</li>
<li>Procedura di Gestione degli Incidenti dell'Azienda.</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<table>
<tr><th>Ruolo</th><th>Responsabilità</th></tr>
<tr><td>Presidente / Direzione (Silvia Garretto)</td><td>Approva la procedura e assegna le risorse; autorizza i cambiamenti ad alto impatto e le finestre di rilascio critiche; approva tempistiche di rimedio e deroghe motivate.</td></tr>
<tr><td>RSGSI (Massimo Tagliavini)</td><td>Mantiene la procedura, verifica che i cambiamenti e le vulnerabilità rilevanti siano valutati nel rischio e documentati, controlla il rispetto dei tempi di rimedio e registra le non conformità.</td></tr>
<tr><td>Resp. IT/Sicurezza (Simon Fattori)</td><td>Definisce gli standard tecnici; gestisce code review, analisi e prioritizzazione delle vulnerabilità, patch e test; valuta e attua i cambiamenti con il piano di rollback; esegue la revisione di log e accessi.</td></tr>
<tr><td>Sviluppatori (dipendenti e collaboratori)</td><td>Applicano le regole di codifica sicura, eseguono test e gestiscono le segnalazioni di vulnerabilità.</td></tr>
<tr><td>Richiedente del cambiamento</td><td>Apre la richiesta di cambiamento (RFC) descrivendo finalità e impatto atteso.</td></tr>
<tr><td>DPO (consulente esterno)</td><td>Valida i requisiti di privacy by design quando si trattano dati personali.</td></tr>
</table>
<h2>5. Sviluppo sicuro (Secure SDLC)</h2>
<h3>5.1 Requisiti e progettazione sicura</h3>
<ul>
<li>I requisiti di sicurezza e privacy sono definiti già in fase di analisi, considerando il modello di minaccia, la separazione tra tenant nel SaaS e l'isolamento delle istanze on-premise.</li>
<li>Si applicano i principi di <strong>privacy by design e by default</strong> (GDPR artt. 25 e 32) e di minimizzazione dei dati.</li>
</ul>
<h3>5.2 Codifica sicura e dipendenze</h3>
<ul>
<li>Si seguono regole di secure coding per prevenire le vulnerabilità più comuni (injection, autenticazione/sessione, controllo accessi, gestione errori, esposizione di dati).</li>
<li>I segreti (credenziali, chiavi API, incluse quelle dei servizi AI) non sono mai inseriti nel codice né nei repository: si usano meccanismi di gestione segreti dedicati. Gli ambienti di sviluppo risiedono su PC portatili cifrati con accesso autenticato.</li>
<li>Le librerie e i componenti open source sono censiti e tenuti aggiornati; si monitorano gli avvisi di vulnerabilità note e si applicano le patch in tempi proporzionati al rischio.</li>
</ul>
<h3>5.3 Test di sicurezza e separazione degli ambienti</h3>
<ul>
<li>Sono previsti test funzionali e di sicurezza prima del rilascio; per le componenti più esposte si eseguono verifiche statiche/dinamiche e, ove opportuno, test di penetrazione. Gli ambienti di test usano dati anonimizzati o sintetici (mai PII reali dei clienti).</li>
<li>Ambienti di sviluppo, test e produzione sono separati (A.8.31); il codice è versionato e le modifiche sono sottoposte a code review tra pari prima dell'integrazione.</li>
</ul>
<h3>5.4 Componenti di intelligenza artificiale</h3>
<p>L'uso di API LLM esterne è valutato per i rischi su confidenzialità dei dati inviati e affidabilità degli output; i dati personali e riservati inviati ai servizi AI sono minimizzati e protetti coerentemente con i contratti e i DPA dei fornitori.</p>
<h2>6. Gestione dei cambiamenti</h2>
<ol>
<li><strong>Richiesta (RFC).</strong> Il richiedente apre una richiesta di cambiamento descrivendo obiettivo, sistemi coinvolti, impatto atteso e urgenza.</li>
<li><strong>Valutazione di impatto e rischio.</strong> Simon Fattori classifica il cambiamento (standard a basso rischio / normale / emergenza) e ne valuta gli effetti su sicurezza, dati personali e continuità; i cambiamenti rilevanti sono registrati nel <strong>modulo "Rischi"</strong> ove pertinente.</li>
<li><strong>Autorizzazione.</strong> I cambiamenti standard a basso rischio sono approvati da Simon Fattori; quelli normali ad alto impatto richiedono l'autorizzazione della Direzione. Va sempre definito un <strong>piano di rollback</strong>.</li>
<li><strong>Test in ambiente separato.</strong> Le modifiche software sono validate in ambienti di sviluppo/test separati dall'esercizio (A.8.31), con test funzionali e di sicurezza (A.8.29) prima del rilascio.</li>
<li><strong>Attuazione.</strong> Il cambiamento è applicato in una finestra concordata; per il SaaS si privilegiano rilasci controllati. Per i prodotti on-premise, l'azienda fornisce ai clienti note di rilascio e indicazioni di aggiornamento, nel rispetto degli obblighi contrattuali di supply chain.</li>
<li><strong>Verifica post-cambiamento.</strong> Si verifica il corretto funzionamento e l'assenza di effetti collaterali; in caso di esito negativo si attiva il rollback.</li>
<li><strong>Chiusura.</strong> Esito e documentazione sono registrati; eventuali anomalie alimentano <strong>non conformità</strong> e azioni correttive.</li>
</ol>
<h3>6.1 Cambiamenti di emergenza</h3>
<p>Per cambiamenti urgenti (es. mitigazione di una vulnerabilità critica), l'attuazione può precedere l'autorizzazione formale, ma <strong>deve essere documentata a posteriori entro il giorno lavorativo successivo</strong> e ratificata dalla Direzione.</p>
<h2>7. Gestione delle vulnerabilità e delle patch</h2>
<h3>7.1 Identificazione</h3>
<ul>
<li>Simon Fattori monitora con continuità le fonti di vulnerabilità: bollettini dei fornitori cloud, avvisi CSIRT/ACN, advisory delle librerie/dipendenze usate dai prodotti, scansioni periodiche e avvisi automatici delle piattaforme (A.5.7, A.8.16).</li>
<li>Si mantiene un inventario aggiornato dei componenti software e delle dipendenze per correlare rapidamente le vulnerabilità ai sistemi interessati.</li>
</ul>
<h3>7.2 Valutazione, prioritizzazione e tempi di rimedio</h3>
<ul>
<li>Ogni vulnerabilità è valutata per <strong>gravità</strong> (es. punteggio CVSS), <strong>esposizione</strong> e <strong>impatto</strong> su dati e servizi, e registrata se rilevante nel <strong>modulo "Rischi"</strong>.</li>
<li>Si assegna una priorità con relativi <strong>tempi target di rimedio</strong>, ad esempio: critiche <strong>entro 48–72 ore</strong>, alte <strong>entro 7 giorni</strong>, medie <strong>entro 30 giorni</strong>, basse alla successiva finestra pianificata. <em>[I valori esatti sono da confermare nel piano di trattamento del rischio e negli SLA interni.]</em></li>
</ul>
<h3>7.3 Rimedio (applicazione delle patch)</h3>
<ul>
<li>L'applicazione delle patch segue la gestione dei cambiamenti (test in ambiente separato e piano di rollback); per le vulnerabilità critiche si attiva il percorso di cambiamento di emergenza. Dove la patch non è immediatamente disponibile si adottano <strong>misure compensative</strong> (restrizione accessi, isolamento, disattivazione della funzione vulnerabile).</li>
<li>Aggiornamenti automatici abilitati su sistema operativo (Windows Update, aggiornamenti macOS, gestore pacchetti Linux) e browser dei portatili; applicazioni (editor, strumenti di sviluppo, client VPN, antimalware, estensioni browser) tenute aggiornate; software non supportato rimosso o sostituito; riavvio del portatile almeno settimanale e quando richiesto.</li>
<li>Per i prodotti SaaS e on-premise si monitorano le dipendenze (librerie, container, runtime), si aggiornano le immagini e si ricostruiscono gli artefatti; sui servizi cloud (Aruba, Hetzner) si applicano gli aggiornamenti delle console e dei servizi gestiti annotando le finestre di manutenzione.</li>
<li>Per i prodotti on-premise, l'azienda rilascia la patch e <strong>informa tempestivamente i clienti impattati</strong> con le istruzioni di aggiornamento (obblighi contrattuali di supply chain), verificandola in ambiente di prova prima del rilascio per evitare regressioni.</li>
</ul>
<h3>7.4 Verifica, chiusura e registrazione</h3>
<ul>
<li>Si verifica l'effettiva risoluzione (riscansione/test) e si chiude la vulnerabilità; gli scostamenti dai tempi target sono registrati come <strong>non conformità</strong> con azione correttiva.</li>
<li>Patch, date e versioni sono tracciate nel registro aggiornamenti/asset; nessuna vulnerabilità critica nota resta non gestita oltre lo SLA interno.</li>
<li>Se una vulnerabilità è stata sfruttata, si attiva la Procedura di Gestione degli Incidenti. In caso di dubbio su un aggiornamento fallito o su una vulnerabilità segnalata si contatta il Resp. IT/Sicurezza Simon Fattori, senza disinstallare patch di sicurezza per "far funzionare" un'applicazione.</li>
</ul>
<h2>8. Logging e monitoraggio</h2>
<p>In assenza di server in sede, i log dei servizi cloud sono la principale fonte di visibilità. Il logging è attivo su tutti i servizi critici (posta, console Aruba/Hetzner, repository, piattaforme AI, password manager, prodotti SaaS), con orari di riferimento coerenti (Europe/Rome o UTC documentato) per correlare gli eventi.</p>
<ol>
<li><strong>Verifica giornaliera rapida.</strong> Controllo degli avvisi di sicurezza automatici dei fornitori (nuovi accessi, login da nuovi dispositivi/paesi, blocchi MFA); ogni avviso è da valutare, non da ignorare.</li>
<li><strong>Revisione settimanale degli accessi.</strong> Esame dei log di autenticazione dei servizi critici cercando login falliti ripetuti, accessi da località/orari inusuali, accessi notturni non giustificati, sessioni o dispositivi non riconosciuti.</li>
<li><strong>Controllo dei cambiamenti privilegiati.</strong> Verifica di modifiche a ruoli/permessi, creazione di account, generazione/rotazione di chiavi API e token; ogni cambiamento deve essere riconducibile a una richiesta legittima.</li>
<li><strong>Log dei prodotti SaaS.</strong> Controllo degli audit log applicativi per accessi anomali ai dati dei clienti ed errori ricorrenti.</li>
<li><strong>Correlazione degli eventi.</strong> A fronte di un'anomalia si ricostruisce la sequenza tra servizi diversi usando orari allineati, per distinguere un evento singolo da una catena.</li>
<li><strong>Conservazione e protezione dei log.</strong> I registri non sono modificabili dagli utenti finali e sono conservati per un periodo adeguato secondo le impostazioni dei fornitori <em>[da verificare rispetto alla policy di retention interna]</em>.</li>
<li><strong>Documentazione della revisione.</strong> Si annotano data, servizi controllati, anomalie rilevate ed esito (chiusa come falso positivo o escalata a incidente) nel registro delle revisioni.</li>
</ol>
<p>In presenza di accesso non autorizzato confermato o sospetto, chiave compromessa o attività anomale sui dati dei clienti, si avvia la Procedura di Gestione degli Incidenti (referente: Simon Fattori); per incidenti che possono ricadere sotto NIS2 si rispettano i tempi di notifica al CSIRT Italia (pre-allarme 24h, notifica 72h, relazione finale 1 mese).</p>
<h2>9. Controlli ISO collegati e riferimenti NIS2</h2>
<ul>
<li><strong>A.8.25</strong> – Ciclo di vita di sviluppo sicuro; <strong>A.8.26</strong> – requisiti di sicurezza delle applicazioni; <strong>A.8.27 / A.8.28</strong> – architettura e codifica sicura; <strong>A.8.29</strong> – test di sicurezza in sviluppo e accettazione; <strong>A.8.30</strong> – sviluppo affidato all'esterno; <strong>A.8.31</strong> – separazione ambienti; <strong>A.8.32 / A.8.33</strong> – gestione dei cambiamenti e dati di test.</li>
<li><strong>A.8.8</strong> – gestione delle vulnerabilità tecniche; <strong>A.8.7</strong> – protezione dai malware; <strong>A.8.9</strong> – gestione della configurazione; <strong>A.5.7</strong> – threat intelligence; <strong>A.8.16</strong> – monitoraggio; <strong>A.8.1</strong> – endpoint.</li>
<li><strong>A.8.15</strong> – logging; <strong>A.5.17</strong> – informazioni di autenticazione.</li>
<li>Controlli cloud di ISO/IEC 27017 e ISO/IEC 27018 per gli aspetti cloud e PII.</li>
<li><strong>NIS2 – D.Lgs. 138/2024, art. 24</strong>: sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi, gestione delle modifiche e delle vulnerabilità. Una vulnerabilità sfruttata o un cambiamento fallito che causino un incidente significativo attivano gli obblighi di notifica dell'<strong>art. 25</strong> (early warning 24 ore, notifica completa 72 ore, relazione finale 1 mese).</li>
</ul>
<h2>10. Registrazioni ed evidenze</h2>
<ul>
<li>Requisiti di sicurezza documentati per progetto/prodotto; registri delle code review e dei test di sicurezza; inventario delle dipendenze.</li>
<li>Richieste di cambiamento (RFC) e autorizzazioni; esiti di test e rilasci; note di rilascio per i clienti on-premise; documentazione dei cambiamenti di emergenza e relativa ratifica.</li>
<li>Registro delle vulnerabilità con gravità, priorità e tempi di rimedio; report delle scansioni e degli aggiornamenti applicati; registro aggiornamenti/asset; comunicazioni di patch ai clienti on-premise.</li>
<li>Registro delle revisioni dei log/accessi con anomalie ed esiti; non conformità e azioni correttive per cambiamenti falliti o ritardi di rimedio.</li>
</ul>
<h2>11. Riesame e versionamento</h2>
<p>La procedura è riesaminata almeno annualmente o a fronte di cambiamenti tecnologici significativi, nuove minacce, modifiche del processo di rilascio o degli strumenti di scansione, cambiamenti del parco software o requisiti contrattuali dei clienti. Versione corrente: <strong>2.0</strong>, approvata dalla Presidente. Le revisioni sono tracciate nel sistema documentale del SGSI a cura del RSGSI.</p>
+106
View File
@@ -0,0 +1,106 @@
<!--META|doc_type=procedura_governance_sgsi|title=Procedura di Governance del SGSI (documenti, audit, riesame, NC, competenze)|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>Definire le modalità con cui <strong>Nuova Agile Technology srl</strong> governa il proprio SGSI nei processi di sistema: controllo dei documenti e delle registrazioni, audit interni, riesame della direzione, gestione delle non conformità e delle azioni correttive, gestione delle competenze e consapevolezza del personale. La procedura assicura che il sistema sia conforme alla <strong>ISO/IEC 27001:2022</strong>, efficacemente attuato, mantenuto e migliorato nel tempo, attuando in particolare le cl. 7.2, 7.3, 7.5, 9.2, 9.3, 10.1 e 10.2.</p>
<h2>2. Ambito</h2>
<p>Si applica a tutto il SGSI e alle sue componenti: documentazione (politiche, procedure di sistema, istruzioni operative, SoA, registri) e registrazioni di processo (verbali, report di audit, valutazioni dei rischi, registri formazione, NC/CAPA); governance del SGSI, gestione dei rischi e degli incidenti, sicurezza del cloud (Aruba IT, Hetzner DE, piattaforme AI), gestione delle PII nel SaaS, sicurezza dei portatili, formazione e rapporti con i fornitori. Data la natura <em>cloud-only</em> dell'azienda (~12 persone: 9 dipendenti, 2 collaboratori P.IVA e la Direzione) non esiste documentazione cartacea controllata di default; i documenti esterni sono archiviati nel cloud aziendale (Aruba IT).</p>
<h2>3. Riferimenti</h2>
<ul>
<li>ISO/IEC 27001:2022 – cl. 7.2 (competenza), 7.3 (consapevolezza), 7.5.1/7.5.2/7.5.3 (informazioni documentate), 9.2.1/9.2.2 (audit interni), 9.3.1/9.3.2/9.3.3 (riesame della direzione), 10.1 (miglioramento continuo), 10.2 (non conformità e azioni correttive).</li>
<li>Controlli Annex A: A.5.1 (politiche), A.5.4 (responsabilità della direzione), A.5.24–A.5.28 (gestione e apprendimento dagli incidenti, evidenze), A.5.33 (protezione delle registrazioni), A.5.34 (privacy e PII), A.5.35 (riesame indipendente), A.5.36 (conformità a politiche e standard), A.5.37 (procedure operative documentate), A.6.1/A.6.2/A.6.3/A.6.5 (ciclo di vita del rapporto, awareness e formazione), A.8.7 (protezione dai malware), A.8.10/A.8.11/A.8.12 (cancellazione, mascheramento, prevenzione fuga di dati), A.5.17 (autenticazione), A.8.28 (codifica sicura).</li>
<li>ISO 19011 (linee guida per gli audit dei sistemi di gestione); ISO/IEC 27018 (conservazione/cancellazione delle PII nel cloud, consapevolezza del personale che tratta PII); GDPR per i periodi di conservazione dei dati personali.</li>
<li>D.Lgs. 138/2024 art. 23 (obblighi di governance e responsabilità degli organi di amministrazione, formazione della direzione), art. 24 (efficacia delle misure, igiene informatica e formazione), art. 25 (notifica degli incidenti significativi) [da verificare per i soggetti rientranti].</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<table>
<tr><th>Ruolo</th><th>Responsabilità</th></tr>
<tr><td>Direzione / Presidente (Silvia Garretto)</td><td>Approva politiche e procedure di sistema (autorità di approvazione); presiede il riesame e assume le decisioni; assicura le risorse per audit, azioni e formazione; partecipa alla formazione di governance NIS2.</td></tr>
<tr><td>RSGSI (Massimo Tagliavini)</td><td>Gestisce l'elenco master dei documenti, versioni e stato; predispone il programma di audit e nomina gli auditor; convoca il riesame, prepara gli input e redige il verbale; registra/classifica le NC e ne verifica la chiusura; definisce i fabbisogni di competenza e il piano formativo.</td></tr>
<tr><td>Resp. IT/Sicurezza (Simon Fattori)</td><td>Garantisce backup, controllo accessi e cifratura degli archivi documentali cloud; fornisce evidenze sulle aree auditate; riporta su incidenti, vulnerabilità e prestazioni dei controlli tecnici; attua le correzioni tecniche; supporta la formazione tecnica.</td></tr>
<tr><td>Auditor (interno indipendente o esterno)</td><td>Conduce gli audit, raccoglie le evidenze, formula i rilievi e redige il report.</td></tr>
<tr><td>Autori / Responsabili di processo</td><td>Redigono e aggiornano i documenti di competenza; segnalano e gestiscono le NC; concordano e attuano le azioni correttive.</td></tr>
<tr><td>Personale (dipendenti e collaboratori)</td><td>Partecipa alle attività formative assegnate e mantiene aggiornata la propria consapevolezza; segnala anomalie e NC.</td></tr>
<tr><td>DPO esterno</td><td>Indica i tempi di conservazione/cancellazione delle registrazioni con dati personali; è coinvolto nelle NC e nei riesami su tematiche PII e relativi obblighi di notifica.</td></tr>
</table>
<h2>5. Controllo dei documenti e delle registrazioni (cl. 7.5)</h2>
<ol>
<li><strong>Identificazione.</strong> Ogni documento riceve titolo, codice/slug, numero di versione, data e stato (bozza/in revisione/approvato/obsoleto).</li>
<li><strong>Redazione e aggiornamento</strong> (cl. 7.5.2): l'autore redige in formato e struttura standard; le modifiche sono tracciate con la cronologia delle versioni.</li>
<li><strong>Verifica e approvazione.</strong> Il RSGSI verifica adeguatezza e coerenza; la Direzione (o delegato) approva. Un documento è pubblicabile solo nello stato "approvato".</li>
<li><strong>Distribuzione e disponibilità</strong> (cl. 7.5.3): la versione vigente è resa disponibile tramite la piattaforma/archivio cloud, con accessi profilati per ruolo.</li>
<li><strong>Controllo delle modifiche.</strong> Ogni revisione genera una nuova versione; la precedente è marcata "obsoleta" e conservata per tracciabilità, non più utilizzabile come riferimento operativo.</li>
<li><strong>Documenti di origine esterna</strong> (leggi, norme, contratti cloud, manuali provider): identificati e con distribuzione controllata.</li>
<li><strong>Protezione e conservazione delle registrazioni.</strong> Le evidenze sono protette da perdita, alterazione e accesso non autorizzato mediante backup, cifratura e controllo accessi del provider cloud; i periodi di conservazione rispettano legge e GDPR; la cancellazione avviene in modo sicuro (A.8.10).</li>
</ol>
<h2>6. Audit interni (cl. 9.2)</h2>
<p>Data la dimensione del team (~12 persone), gli audit sono di norma condotti dal RSGSI o da risorsa interna indipendente dall'area auditata; per oggettività sulle aree gestite dallo stesso RSGSI è possibile ricorrere a un auditor esterno.</p>
<ol>
<li><strong>Programmazione</strong> (input: esiti audit precedenti, importanza dei processi, esiti valutazione rischi). Si pianifica almeno un ciclo di audit interno all'anno che copra tutte le clausole e i controlli applicabili; le aree a rischio più elevato possono essere auditate più di frequente.</li>
<li><strong>Pianificazione del singolo audit.</strong> Si definiscono obiettivi, criteri (la norma e i documenti del SGSI), ambito, date e auditor; il piano è registrato nel <strong>modulo "Audit interni"</strong>.</li>
<li><strong>Conduzione.</strong> L'auditor verifica documentazione, configurazioni cloud, registri e prassi operative; raccoglie evidenze oggettive e annota osservazioni e non conformità.</li>
<li><strong>Classificazione dei rilievi</strong> come Non Conformità (maggiore/minore) oppure Osservazione/Opportunità di miglioramento.</li>
<li><strong>Rendicontazione.</strong> L'auditor redige il report nel modulo "Audit interni" (esito, rilievi, raccomandazioni), condiviso con i responsabili di area e con la Direzione.</li>
<li><strong>Gestione dei rilievi e follow-up.</strong> Ogni Non Conformità apre una scheda nel modulo NCR/CAPA; il RSGSI ne verifica la chiusura. Esiti e stato delle azioni alimentano il successivo Riesame della Direzione.</li>
</ol>
<h2>7. Riesame della direzione (cl. 9.3)</h2>
<ol>
<li><strong>Convocazione e raccolta input.</strong> Il RSGSI raccoglie dai moduli della piattaforma gli elementi richiesti dalla cl. 9.3.2: stato delle azioni dai riesami precedenti; cambiamenti del contesto e delle parti interessate; esiti della valutazione e del trattamento dei rischi; prestazioni di sicurezza (incidenti, non conformità, monitoraggio e misurazioni); esiti degli audit interni; raggiungimento degli obiettivi di sicurezza; feedback delle parti interessate; opportunità di miglioramento.</li>
<li><strong>Conduzione della riunione.</strong> La Direzione esamina ciascun input e valuta idoneità, adeguatezza ed efficacia del SGSI, discutendo eventuali necessità di cambiamento.</li>
<li><strong>Decisioni e output</strong> (cl. 9.3.3): opportunità di miglioramento, cambiamenti al SGSI (politiche, obiettivi, controlli), fabbisogni di risorse e azioni con responsabili e scadenze.</li>
<li><strong>Verbalizzazione.</strong> Il RSGSI redige il verbale nel <strong>modulo "Riesame della Direzione"</strong>, riportando input considerati, decisioni e azioni assegnate.</li>
<li><strong>Attuazione e monitoraggio.</strong> Le azioni derivanti sono tracciate (come schede NCR/CAPA o voci del piano di trattamento rischi) e il loro stato è verificato al riesame successivo.</li>
</ol>
<h2>8. Non conformità e azioni correttive (cl. 10.1 e 10.2)</h2>
<ol>
<li><strong>Rilevazione e registrazione.</strong> La NC è aperta nel <strong>modulo "Non conformità / Azioni correttive (NCR/CAPA)"</strong> con descrizione, origine, data e responsabile (rilievi di audit, scostamenti dalla norma o dai documenti, incidenti, segnalazioni di clienti/fornitori, malfunzionamenti dei controlli cloud, esiti di monitoraggio).</li>
<li><strong>Correzione immediata</strong> (cl. 10.2 a): si contiene e corregge la NC e se ne gestiscono le conseguenze (es. revoca di un accesso, ripristino di una configurazione cloud, contenimento di un incidente).</li>
<li><strong>Valutazione della necessità di azione correttiva</strong> (cl. 10.2 b): per NC minori e isolate può bastare la correzione; per NC ricorrenti o significative si avvia un'azione correttiva.</li>
<li><strong>Analisi delle cause</strong> (root cause): si individuano le cause profonde (es. assenza di un controllo, configurazione errata, mancanza di competenza) con tecnica adeguata (5 perché / causa-effetto).</li>
<li><strong>Definizione e attuazione della CAPA</strong> (cl. 10.2 c/d): azioni, responsabili e scadenze registrate come azioni collegate alla scheda, e attuate.</li>
<li><strong>Verifica dell'efficacia</strong> (cl. 10.2 d/e): il RSGSI verifica che la causa sia eliminata e che la NC non si ripresenti; aggiorna, se necessario, rischi e SoA.</li>
<li><strong>Chiusura e comunicazione</strong> (cl. 10.2 f/g): la scheda è chiusa con evidenza dell'efficacia; le NC significative sono portate al Riesame della Direzione. Per incidenti che configurano violazioni di dati o incidenti significativi NIS2 si attivano i relativi flussi di notifica (art. 25 D.Lgs. 138/2024: pre-allarme 24h, notifica 72h, relazione finale 1 mese).</li>
</ol>
<h2>9. Competenze, formazione e consapevolezza (cl. 7.2 e 7.3)</h2>
<ol>
<li><strong>Definizione dei fabbisogni.</strong> Per ciascun ruolo si individuano le competenze richieste (cl. 7.2 a/b) e il divario rispetto a quelle possedute, considerando le specificità <em>cloud-only</em>: sicurezza dei servizi cloud, uso sicuro dei portatili, sviluppo sicuro (SaaS e on-premise), protezione delle PII, uso responsabile delle piattaforme AI.</li>
<li><strong>Pianificazione formativa.</strong> Il RSGSI definisce il piano annuale con priorità, destinatari e scadenze, includendo almeno: awareness generale per tutti, formazione tecnica per IT/sviluppo, sessione di governance per la Direzione, modulo sulla protezione delle PII.</li>
<li><strong>Assegnazione ed erogazione.</strong> I corsi sono assegnati tramite il <strong>modulo "Formazione"</strong> (e-learning, aula o on-the-job).</li>
<li><strong>Consapevolezza continua</strong> (cl. 7.3): comunicazioni periodiche su politiche, minacce attuali e responsabilità individuali; sessione di awareness obbligatoria al nuovo ingresso, prima dell'accesso ai sistemi.</li>
<li><strong>Registrazione, verifica ed efficacia.</strong> Stato, data di completamento ed esiti di test/quiz sono registrati nel modulo "Formazione"; il RSGSI verifica tasso di completamento e adeguatezza delle competenze (es. riduzione di incidenti da errore umano); le carenze diventano azioni di miglioramento o NC.</li>
<li><strong>Ingressi e cessazioni.</strong> All'assunzione si definiscono i requisiti di competenza e consapevolezza; alla cessazione si rammentano gli obblighi di riservatezza residui (A.6.5).</li>
</ol>
<h3>9.1 Consapevolezza anti-phishing (istruzione per il personale)</h3>
<p>Il phishing è la porta d'ingresso più comune per gli attacchi; ogni persona deve saperlo riconoscere (email, SMS/smishing, telefono/vishing) e segnalarlo rapidamente. Regole essenziali: fermarsi prima di agire di fronte a messaggi che creano urgenza/paura/curiosità; verificare il mittente reale e diffidare di domini simili; non cliccare d'impulso (controllare l'URL, nel dubbio digitare l'indirizzo nel browser); non aprire allegati inattesi (eseguibili, archivi, "abilita macro"); <strong>mai inserire credenziali o codici MFA da un link ricevuto</strong>; verificare su canale diverso e noto le richieste anomale del "capo" o di fornitori (pagamenti, cambio IBAN, invio credenziali); nessuno deve farsi leggere o inoltrare un codice MFA. Prerequisito: MFA attivo su posta e servizi critici. In caso di messaggio sospetto si inoltra l'originale (senza cliccare) al Resp. IT/Sicurezza <strong>Simon Fattori</strong>; se si è già cliccato o inserito credenziali, avvisare subito Simon Fattori, cambiare la password interessata e, se possibile, scollegare il dispositivo dalla rete. Una segnalazione tempestiva può evitare un incidente; un click confessato non è una colpa. Integrare con simulazioni di phishing periodiche.</p>
<h2>10. Moduli della piattaforma come repository delle evidenze</h2>
<p>Le registrazioni di processo risiedono nei rispettivi moduli della piattaforma, che fungono da repository controllato delle evidenze: <strong>Audit interni</strong> (programma e piani di audit, report e rilievi), <strong>Riesame della Direzione</strong> (verbali, input considerati, decisioni e azioni), <strong>NCR/CAPA</strong> (schede di non conformità, analisi delle cause, azioni correttive con responsabili/scadenze/verifica di efficacia), <strong>Rischi</strong> (valutazioni e piano di trattamento), <strong>Formazione</strong> (matrice competenze, piano formativo, assegnazioni e attestati di completamento). L'<strong>elenco master dei documenti</strong> con stato e versione è mantenuto dal RSGSI nella piattaforma/archivio cloud.</p>
<h2>11. Controlli ISO/clausole collegati e riferimenti NIS2</h2>
<ul>
<li><strong>cl. 7.5.1/7.5.2/7.5.3</strong>; A.5.33, A.5.37, A.8.10/A.8.11/A.8.12; requisiti ISO/IEC 27018 su conservazione, restituzione e cancellazione delle PII.</li>
<li><strong>cl. 9.2.1/9.2.2</strong>; A.5.35 (riesame indipendente), A.5.36 (conformità); ISO 19011.</li>
<li><strong>cl. 9.3.1/9.3.2/9.3.3</strong>; A.5.1, A.5.4; collegamento con cl. 9.2 (audit), cl. 6.1/8.2 (rischi), cl. 10.1/10.2 (miglioramento) e cl. 5 (leadership).</li>
<li><strong>cl. 10.1 e 10.2 (a–g)</strong>; A.5.24 (preparazione gestione incidenti), A.5.27 (apprendimento dagli incidenti), A.5.28 (raccolta evidenze).</li>
<li><strong>cl. 7.2/7.3</strong>; A.6.3 (formazione e awareness), A.6.1/A.6.2/A.6.5 (ciclo di vita del rapporto), A.8.28 (codifica sicura), A.5.17 (autenticazione), A.8.7 (protezione dai malware).</li>
<li><strong>NIS2 – D.Lgs. 138/2024</strong>: art. 23 (governance e formazione della direzione), art. 24 (efficacia delle misure, igiene informatica e formazione), art. 25 (notifica incidenti).</li>
</ul>
<h2>12. Registrazioni ed evidenze</h2>
<ul>
<li>Elenco master dei documenti del SGSI con stato e versione; cronologia delle versioni di ciascun documento (versione + data + autore).</li>
<li>Programma di audit annuale, piani e report di audit con rilievi ed evidenze; evidenza di indipendenza/competenza degli auditor.</li>
<li>Verbale di riesame della direzione con input, decisioni e azioni; pacchetto di input estratto dai moduli operativi.</li>
<li>Schede NC con analisi delle cause e azioni correttive (responsabili, scadenze, stato, verifica di efficacia) e relativi collegamenti ad audit, rischi e incidenti.</li>
<li>Matrice delle competenze per ruolo e piano formativo annuale; assegnazioni e attestati di completamento; evidenze di awareness di onboarding e comunicazioni periodiche.</li>
</ul>
<h2>13. Riesame e versionamento</h2>
<p>I processi di governance del SGSI e i relativi documenti sono riesaminati <strong>almeno annualmente</strong> e ad ogni cambiamento organizzativo, tecnologico o normativo rilevante (nuovi servizi/provider, incidenti gravi, nuove minacce, nuovi ruoli). Ogni nuova edizione incrementa la versione (modifiche minori → incremento minore; modifiche sostanziali → incremento maggiore). Versione corrente: <strong>2.0</strong>, approvata dalla Direzione secondo la presente procedura di controllo dei documenti.</p>
+44
View File
@@ -0,0 +1,44 @@
<!--META|doc_type=politica_sicurezza_informazioni|title=Politica Generale per la Sicurezza delle Informazioni|status=approved|version=2.0-->
<h2>1. Scopo e ambito</h2>
<p>La presente Politica esprime l'impegno formale dell'Alta Direzione di <strong>Nuova Agile Technology srl</strong> verso la protezione di riservatezza, integrità e disponibilità delle informazioni proprie e di quelle affidate dai clienti, inclusi i dati personali. È il documento di indirizzo del Sistema di Gestione per la Sicurezza delle Informazioni (SGSI) conforme a <strong>ISO/IEC 27001:2022</strong> e alle linee guida <strong>ISO/IEC 27017:2015</strong> e <strong>27018:2019</strong> per i servizi cloud e i dati personali. Si applica a tutto il personale (dipendenti e collaboratori a P.IVA), a tutte le informazioni trattate, ai prodotti software in licenza d'uso installati presso i clienti e ai servizi SaaS multi-tenant erogati in cloud. L'infrastruttura è interamente cloud (<strong>Aruba</strong>, Italia; <strong>Hetzner</strong>, Germania-UE) con piattaforme AI via API; non esistono server gestiti in sede e le postazioni sono solo PC portatili cifrati.</p>
<h2>2. Riferimenti</h2>
<ul>
<li>ISO/IEC 27001:2022, 27017:2015, 27018:2019</li>
<li>Regolamento (UE) 2016/679 (GDPR)</li>
<li>Direttiva (UE) 2022/2555 (NIS2) e D.Lgs. 138/2024</li>
<li>Manuale SGSI, Dichiarazione di Applicabilità (SoA)</li>
</ul>
<h2>3. Ruoli e responsabilità</h2>
<p>La <strong>Presidente Silvia Garretto</strong> (Alta Direzione) approva e sostiene la Politica. Il <strong>Responsabile SGSI Massimo Tagliavini</strong> ne cura attuazione e monitoraggio. Il <strong>Responsabile IT e Sicurezza Simon Fattori</strong> presidia le misure tecniche. Il <strong>DPO (consulente esterno, da nominare)</strong> supervisiona la conformità GDPR. Ogni membro del personale è responsabile del rispetto della Politica nell'ambito delle proprie attività.</p>
<h2>4. Principi e impegni</h2>
<p>L'Alta Direzione si impegna a:</p>
<ul>
<li><strong>Riservatezza</strong>: garantire l'accesso alle informazioni solo a chi è autorizzato, applicando il minimo privilegio e la separazione dei tenant nel SaaS.</li>
<li><strong>Integrità</strong>: assicurare accuratezza e completezza di informazioni e sistemi, con controlli su modifiche e sviluppo software sicuro.</li>
<li><strong>Disponibilità</strong>: garantire l'accesso ai servizi secondo i livelli concordati, mediante backup, continuità operativa e gestione resiliente del cloud.</li>
<li><strong>Conformità</strong>: rispettare gli obblighi legali e contrattuali, in particolare GDPR e i requisiti NIS2 ove applicabili.</li>
<li><strong>Gestione del rischio</strong>: identificare, valutare e trattare i rischi in modo sistematico, con attenzione alla supply chain cloud e AI.</li>
<li><strong>Consapevolezza</strong>: formare e sensibilizzare il personale sui temi di sicurezza.</li>
<li><strong>Miglioramento continuo</strong>: riesaminare periodicamente il SGSI e adottare azioni correttive e preventive.</li>
<li><strong>Gestione degli incidenti</strong>: rilevare, gestire e segnalare tempestivamente gli incidenti di sicurezza e le violazioni di dati personali, nel rispetto degli obblighi di notifica al CSIRT (NIS2: 24h/72h/1 mese).</li>
</ul>
<p>L'Azienda adotta una <strong>politica di tolleranza zero</strong> verso comportamenti che mettano deliberatamente a rischio la sicurezza delle informazioni.</p>
<h2>5. Obiettivi di sicurezza</h2>
<p>Gli obiettivi misurabili del SGSI sono definiti annualmente dalla Direzione e includono, a titolo esemplificativo: copertura della formazione del personale, tempi di risposta agli incidenti, percentuale di rischi trattati entro i termini, livello di conformità dei fornitori cloud. Sono monitorati e riesaminati nel riesame di direzione.</p>
<h2>6. Controlli ISO collegati e riferimenti NIS2</h2>
<p>Controlli Annex A pertinenti: <strong>A.5.1</strong> (Politiche per la sicurezza delle informazioni), <strong>A.5.2</strong> (Ruoli e responsabilità), <strong>A.5.4</strong> (Responsabilità della direzione), <strong>A.5.31</strong> (Requisiti legali e contrattuali), <strong>A.5.36</strong> (Conformità alle politiche). Riferimenti NIS2 (D.Lgs. 138/2024): <strong>art.23</strong> (governance e ruolo degli organi di gestione), <strong>art.24</strong> (misure di gestione del rischio), <strong>art.25</strong> (obblighi di notifica). Le ISO costituiscono buone prassi, non obblighi di legge.</p>
<h2>7. Caveat NIS2</h2>
<p>L'Azienda si autoclassifica in via <strong>preliminare</strong> come soggetto NIS2 "<strong>IMPORTANTE</strong>", pur essendo <strong>sotto le soglie dimensionali ordinarie</strong>: la qualifica va <strong>confermata da Direzione e Legale</strong>, ed eventualmente da ACN, in base a fatturato e categoria di attività. <strong>[DA VERIFICARE]</strong> in sede di registrazione presso ACN.</p>
<h2>8. Comunicazione e applicazione</h2>
<p>La Politica è comunicata a tutto il personale e accessibile in qualsiasi momento. La sua violazione può comportare provvedimenti disciplinari secondo le norme contrattuali e di legge vigenti. Evidenze: documento firmato dalla Presidente, evidenza di comunicazione al personale, verbali di riesame.</p>
<h2>9. Riesame e versionamento</h2>
<p>Approvata dall'Alta Direzione. Riesame almeno annuale o a fronte di modifiche significative del contesto.</p>
+110
View File
@@ -0,0 +1,110 @@
<!--META|doc_type=politica_controllo_accessi|title=Politica e Procedura di Controllo degli Accessi (incl. MFA, onboarding/offboarding)|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>Definire le regole e i passi operativi con cui <strong>Nuova Agile Technology srl</strong> autorizza, concede, modifica, riesamina e revoca gli accessi logici alle informazioni, ai sistemi cloud (Aruba, Hetzner), alle piattaforme AI, agli ambienti di sviluppo e ai servizi SaaS multi-tenant, garantendo che ogni utente disponga esclusivamente dei privilegi necessari al proprio ruolo (<em>least privilege</em>) e che ogni accesso sia protetto da <strong>autenticazione a più fattori (MFA)</strong>. Il documento copre principi, l'intero ciclo di vita dell'identità (onboarding, variazioni di ruolo, riesame periodico, offboarding) e le istruzioni operative MFA.</p>
<h2>2. Ambito</h2>
<p>Si applica a tutti gli accessi logici di dipendenti, collaboratori a P.IVA, utenze tecniche/di servizio e — ove pertinente — di clienti e fornitori. Riguarda: account dei provider cloud (Aruba IT, Hetzner DE), repository di codice, ambienti di produzione e staging, console di amministrazione e pannelli SaaS multi-tenant, posta elettronica, strumenti di collaborazione, database, gestore di password e gestore segreti aziendali, chiavi API (incluse quelle dei provider AI) e i <strong>PC portatili cifrati</strong> in dotazione. <strong>Non esistono server in sede</strong>: non sono previsti accessi fisici a sale macchine, la cui sicurezza è ereditata dai fornitori cloud secondo il modello di responsabilità condivisa.</p>
<h2>3. Riferimenti</h2>
<ul>
<li><strong>ISO/IEC 27001:2022</strong> – Annex A: A.5.15 (Controllo degli accessi), A.5.16 (Gestione delle identità), A.5.17 (Informazioni di autenticazione), A.5.18 (Diritti di accesso), A.6.3 (Consapevolezza in fase di ingresso), A.8.1 (Dispositivi endpoint), A.8.2 (Diritti di accesso privilegiati), A.8.3 (Restrizione dell'accesso alle informazioni), A.8.5 (Autenticazione sicura).</li>
<li><strong>ISO/IEC 27017:2015</strong> (gestione accessi nei servizi cloud) e <strong>27018:2019</strong> (accesso ai dati personali nel cloud).</li>
<li><strong>D.Lgs. 4 settembre 2024, n. 138</strong> (recepimento Direttiva (UE) 2022/2555 – NIS2): art. 24 (misure di gestione del rischio).</li>
<li>Politica per la Sicurezza delle Informazioni; Politica di Crittografia; Manuale SGSI.</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<table>
<tr><th>Ruolo</th><th>Persona</th><th>Responsabilità</th></tr>
<tr><td>Direzione / Presidente</td><td><strong>Silvia Garretto</strong></td><td>Approva il documento, autorizza i profili di accesso privilegiato critico e le deroghe</td></tr>
<tr><td>Responsabile SGSI</td><td><strong>Massimo Tagliavini</strong></td><td>Approva le matrici di accesso (RBAC), coordina i riesami periodici e mantiene le evidenze</td></tr>
<tr><td>Responsabile IT/Sicurezza</td><td><strong>Simon Fattori</strong></td><td>Crea/modifica/revoca le utenze, configura l'MFA, custodisce le credenziali, esegue le verifiche tecniche</td></tr>
<tr><td>Responsabile dell'unità richiedente</td><td><em>variabile</em></td><td>Richiede e giustifica gli accessi del proprio personale</td></tr>
<tr><td>DPO</td><td><em>Consulente esterno</em></td><td>Consultato per gli accessi che coinvolgono dati personali dei clienti</td></tr>
</table>
<h2>5. Principi di controllo degli accessi</h2>
<ul>
<li><strong>Minimo privilegio</strong>: a ogni utente sono concessi solo i diritti necessari al ruolo.</li>
<li><strong>Need-to-know</strong>: l'accesso alle informazioni è limitato a chi ne ha effettiva necessità.</li>
<li><strong>Segregazione dei compiti</strong>: ove possibile, separazione tra chi sviluppa, chi rilascia in produzione e chi amministra.</li>
<li><strong>Default deny</strong>: in assenza di autorizzazione esplicita, l'accesso è negato.</li>
<li><strong>Account nominativi</strong>: nessuna condivisione di credenziali; ogni account è personale.</li>
</ul>
<h2>6. Autenticazione e MFA</h2>
<p>L'<strong>MFA è obbligatoria</strong> per ogni servizio critico: console cloud Aruba/Hetzner, repository di codice, accessi amministrativi al SaaS, account di posta, SSO, piattaforme AI, password manager e gestore segreti. La sola password non è mai sufficiente. Le password devono essere robuste secondo standard aziendale ed è obbligatorio l'uso di un <strong>password manager</strong> approvato.</p>
<h3>6.1 Istruzione operativa MFA</h3>
<ol>
<li><strong>Scegli il secondo fattore corretto.</strong> Ordine di preferenza: (1) chiave di sicurezza FIDO2/passkey, (2) app di autenticazione (codici TOTP o notifiche push), (3) come ultima scelta SMS. <strong>Evita gli SMS</strong> dove esiste un'alternativa.</li>
<li><strong>Attiva l'MFA su ogni servizio critico.</strong> Impostazioni di sicurezza dell'account → "Autenticazione a due fattori / MFA" → abilita, servizio per servizio (posta, repository, console Aruba e Hetzner, piattaforme AI, password manager).</li>
<li><strong>Registra il dispositivo.</strong> Inquadra il QR code con l'app di autenticazione o registra la chiave FIDO2; conferma con il primo codice generato.</li>
<li><strong>Salva i codici di recupero</strong> monouso <strong>solo</strong> nel password manager aziendale, mai in chiaro su file, email o foglietti.</li>
<li><strong>Imposta un secondo metodo</strong> (seconda passkey o chiave fisica di backup) per non restare bloccato in caso di smarrimento dello smartphone; sui servizi più critici (posta e console cloud) devono risultare registrati almeno due metodi.</li>
<li><strong>Proteggi il password manager</strong>: master password lunga, unica, mai riutilizzata, con MFA attivo.</li>
<li><strong>Account/segreti di servizio</strong> nel gestore segreti aziendale, mai scambiati via chat o email.</li>
</ol>
<h3>6.2 Verifiche di esito MFA</h3>
<ul>
<li>Un login di prova deve richiedere il secondo fattore; nessun servizio critico accessibile con la sola password.</li>
<li>I codici di recupero sono presenti nel password manager per ogni servizio.</li>
</ul>
<p>In caso di smarrimento smartphone, mancata ricezione codici, esaurimento dei codici di recupero o sospetto accesso non autorizzato, contattare <strong>subito</strong> il Resp. IT/Sicurezza <strong>Simon Fattori</strong> per il reset controllato. È <strong>vietato disattivare l'MFA</strong> per "comodità".</p>
<h2>7. Accessi privilegiati e chiavi API</h2>
<ul>
<li>Gli account amministrativi sono ridotti al minimo, nominativi, monitorati e soggetti a logging e revisione.</li>
<li>Le <strong>chiavi API</strong> (cloud, AI, integrazioni) sono custodite in un vault cifrato, mai inserite in chiaro nel codice o committate nei repository, e ruotate periodicamente o in caso di sospetta compromissione.</li>
</ul>
<h2>8. Accesso nel SaaS multi-tenant</h2>
<ul>
<li>Isolamento logico dei tenant: ogni cliente accede esclusivamente ai propri dati.</li>
<li>I dati personali dei clienti sono accessibili al personale dell'Azienda solo per finalità di erogazione e supporto, con tracciabilità (rif. ISO 27018).</li>
</ul>
<h2>9. Ciclo di vita dell'identità</h2>
<h3>9.1 Onboarding (ingresso di un nuovo utente)</h3>
<ol>
<li>Il responsabile (o la Direzione) invia a Simon Fattori la richiesta formale con ruolo, profilo di accesso, data di inizio (ed eventuale fine, per i collaboratori esterni).</li>
<li>Simon Fattori crea l'identità (account aziendale: posta + SSO se presente) sulle sole piattaforme necessarie al ruolo, applicando il <em>least privilege</em> e profili predefiniti per mansione (RBAC); per i collaboratori esterni limita l'accesso ai soli progetti pertinenti, se possibile con scadenza.</li>
<li>Si attiva obbligatoriamente l'<strong>MFA su tutte le utenze</strong> e si forza il cambio password al primo accesso. Senza MFA l'accesso non è abilitato.</li>
<li>Il PC portatile viene consegnato già <strong>cifrato a disco intero</strong> (configurato secondo l'Istruzione Hardening: antimalware, blocco schermo) e registrato nell'inventario; le credenziali sono custodite solo nel password manager/gestore segreti, mai via email o chat.</li>
<li>L'utente sottoscrive la Politica d'uso accettabile, riceve la formazione di sicurezza di base (MFA, phishing, uso AI, hardening) e si registra l'avvenuta consapevolezza.</li>
<li>Si annota nel registro accessi data, ruolo e servizi concessi.</li>
</ol>
<h3>9.2 Variazione di ruolo</h3>
<ol>
<li>A ogni cambio di mansione il responsabile richiede l'aggiornamento del profilo.</li>
<li>Simon Fattori adegua i privilegi <strong>rimuovendo quelli non più pertinenti prima di aggiungere i nuovi</strong> (no accumulo di permessi).</li>
</ol>
<h3>9.3 Riesame periodico degli accessi</h3>
<ol>
<li>Con cadenza <strong>almeno semestrale</strong>, Massimo Tagliavini e Simon Fattori riesaminano tutte le utenze, con particolare attenzione agli <strong>accessi privilegiati</strong> e alle utenze di servizio, confrontando gli accessi attivi con il personale in forza.</li>
<li>Gli accessi non più giustificati vengono revocati; gli scostamenti sono registrati come <strong>non conformità</strong> nel modulo dedicato e gli esiti del riesame sono conservati.</li>
</ol>
<h3>9.4 Offboarding (cessazione)</h3>
<ol>
<li>Alla data di cessazione (o prima, se richiesto), Simon Fattori <strong>disabilita l'account principale e tutte le utenze</strong> e revoca le sessioni attive: non ci si limita a cambiare la password.</li>
<li>Si rimuove l'utente da posta, repository, console cloud, piattaforme AI, password manager, gestore segreti e MDM, revocando chiavi API e token.</li>
<li>Si <strong>ruotano i segreti condivisi</strong> (password, chiavi API, token) di cui l'utente era a conoscenza — specialmente per i collaboratori esterni.</li>
<li>Si recupera il PC portatile, se ne verifica la cifratura e si esegue il wipe sicuro prima della riassegnazione; per dispositivi personali si rimuovono dati e accessi aziendali.</li>
<li>Si riassegnano repository, documenti e caselle condivise a un referente designato.</li>
<li>Si registra l'avvenuto offboarding (data di revoca e segreti ruotati). In caso di uscita conflittuale, priorità assoluta alla revoca immediata degli accessi.</li>
</ol>
<h2>10. Controlli ISO collegati e riferimenti NIS2</h2>
<p>Il documento attua i controlli ISO/IEC 27001:2022 <strong>A.5.15</strong> (Controllo degli accessi), <strong>A.5.16</strong> (Gestione delle identità), <strong>A.5.17</strong> (Informazioni di autenticazione), <strong>A.5.18</strong> (Diritti di accesso), <strong>A.6.3</strong> (Consapevolezza in fase di ingresso), <strong>A.8.1</strong> (Dispositivi endpoint), <strong>A.8.2</strong> (Diritti di accesso privilegiati), <strong>A.8.3</strong> (Restrizione dell'accesso alle informazioni), <strong>A.8.5</strong> (Autenticazione sicura), oltre ai controlli cloud di ISO/IEC 27017/27018. Risponde alle <strong>misure di gestione del rischio dell'art. 24 del D.Lgs. 138/2024</strong> (NIS2) in materia di controllo degli accessi, autenticazione a più fattori e igiene informatica. Le evidenze sono richiamabili anche per gli obblighi di supply chain verso i clienti NIS2.</p>
<h2>11. Registrazioni ed evidenze</h2>
<ul>
<li>Matrice dei ruoli e dei privilegi (RBAC), registro delle richieste di accesso e relative autorizzazioni;</li>
<li>Report dei riesami periodici (semestrali) degli accessi;</li>
<li>Registrazioni di onboarding/offboarding e di ritiro dei dispositivi;</li>
<li>Configurazione MFA e log di accesso conservati dalle piattaforme cloud;</li>
<li>Log degli accessi privilegiati e inventario delle chiavi API.</li>
</ul>
<h2>12. Riesame e versionamento</h2>
<p>Approvato dal Responsabile SGSI e dall'Alta Direzione (Presidente). Revisione almeno annuale o a fronte di cambiamenti significativi delle piattaforme o dei ruoli.</p>
+75
View File
@@ -0,0 +1,75 @@
<!--META|doc_type=politica_crittografia|title=Politica di Crittografia e Gestione delle Chiavi (incl. chiavi cloud)|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>Definire i criteri con cui <strong>Nuova Agile Technology srl</strong> impiega la crittografia per proteggere riservatezza e integrità delle informazioni — in particolare i dati personali dei clienti trattati nel SaaS — e per gestire in modo sicuro chiavi crittografiche e segreti applicativi lungo l'intero ciclo di vita. Include la regola specifica per la <strong>custodia e il backup delle chiavi di accesso al cloud (key escrow controllato)</strong>, affinché lo smarrimento dell'unico dispositivo non causi mai la perdita di accesso ai servizi, senza creare nuovi rischi di esposizione.</p>
<h2>2. Ambito</h2>
<p>Si applica ai dati a riposo nei servizi cloud (Aruba, Hetzner), ai dati in transito tra utenti, servizi e provider AI, ai PC portatili del personale, ai backup, ai segreti applicativi (chiavi API cloud e AI, credenziali di database, token, chiavi SSH, certificati TLS, codici di recupero MFA) e ai prodotti in licenza installati presso i clienti, per la parte di configurazione crittografica raccomandata.</p>
<h2>3. Riferimenti</h2>
<ul>
<li>ISO/IEC 27001:2022 Annex A: A.8.24 (crittografia), A.8.5 (autenticazione sicura), A.5.33 (protezione delle registrazioni), A.5.17 (informazioni di autenticazione), A.8.13 (backup), A.5.23 (sicurezza nei servizi cloud).</li>
<li>ISO/IEC 27017:2015 e 27018:2019 (crittografia dei dati personali nel cloud).</li>
<li>GDPR art. 32 (misure tecniche, tra cui cifratura); Politica di Controllo degli Accessi.</li>
<li>NIS2 — D.Lgs. 138/2024, art. 24 (misure di gestione del rischio, incluse politiche e procedure relative all'uso della crittografia).</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<p>Il <strong>Responsabile IT e Sicurezza (Simon Fattori)</strong> definisce e gestisce algoritmi, chiavi, vault dei segreti, accessi e rotazione; è il primo autorizzatore al recupero delle chiavi critiche. Il <strong>Responsabile SGSI (Massimo Tagliavini)</strong> verifica la conformità della Politica ed è il secondo autorizzatore al recupero. Il <strong>DPO (consulente esterno)</strong> è consultato per la cifratura dei dati personali. L'<strong>Alta Direzione (Silvia Garretto)</strong> approva la Politica. I <strong>collaboratori</strong> registrano e proteggono le proprie credenziali secondo le regole seguenti.</p>
<h2>5. Regole di crittografia</h2>
<h3>5.1 Dati in transito</h3>
<ul>
<li>Tutte le comunicazioni esterne avvengono tramite <strong>TLS 1.2 o superiore</strong> (preferibilmente TLS 1.3); protocolli e cifrature obsolete sono disabilitati.</li>
<li>Le connessioni tra applicazione e database e tra microservizi adottano canali cifrati ove tecnicamente possibile.</li>
<li>Le chiamate alle API dei provider AI e cloud avvengono esclusivamente su canali cifrati.</li>
</ul>
<h3>5.2 Dati a riposo</h3>
<ul>
<li>I dati a riposo nei servizi cloud sono cifrati; database e volumi che contengono dati personali utilizzano cifratura (es. AES-256) secondo le funzionalità del provider.</li>
<li>I <strong>PC portatili</strong> del personale hanno la <strong>cifratura completa del disco</strong> attiva (BitLocker/FileVault/LUKS).</li>
<li>I <strong>backup</strong> sono cifrati e conservati in modo sicuro.</li>
</ul>
<h3>5.3 Algoritmi ammessi</h3>
<ul>
<li>Cifratura simmetrica: <strong>AES-256</strong> (modalità autenticate come GCM).</li>
<li>Hashing password: funzioni dedicate e resistenti (es. <strong>bcrypt/Argon2</strong>); vietato MD5/SHA-1 per scopi di sicurezza.</li>
<li>Firma/integrità: <strong>HMAC-SHA-256</strong> o equivalente; certificati basati su algoritmi robusti.</li>
</ul>
<h3>5.4 Provider AI e dati</h3>
<p>Le informazioni inviate alle piattaforme AI sono trasmesse su canali cifrati e, ove possibile, <strong>minimizzate/anonimizzate</strong> per evitare l'esposizione di dati personali o riservati non necessari all'elaborazione.</p>
<h2>6. Gestione delle chiavi e dei segreti</h2>
<h3>6.1 Principi generali</h3>
<ul>
<li><strong>Custodia centralizzata</strong>: i segreti (chiavi API, credenziali, token, chiavi SSH, codici di recupero MFA) vivono in un <strong>vault cifrato / password manager aziendale</strong>, mai in chiaro nel codice sorgente, nei file di configurazione versionati, nei log, nelle email, chat o note personali.</li>
<li><strong>Sempre cifrate, mai sul portatile</strong>: nessuna credenziale in chiaro su portatili, repository o supporti locali non protetti.</li>
<li><strong>Minimo privilegio e tracciabilità</strong>: l'accesso alle chiavi segue il principio del minimo privilegio ed è registrato (audit log).</li>
<li><strong>Rotazione</strong>: rotazione periodica e rotazione immediata in caso di sospetta compromissione, leak o cessazione di personale con accesso.</li>
<li><strong>Certificati TLS</strong>: monitorati per la scadenza e rinnovati tempestivamente.</li>
</ul>
<h3>6.2 Custodia e backup delle chiavi di accesso al cloud (key escrow controllato)</h3>
<p>Le chiavi e credenziali di accesso ai servizi cloud (Aruba, Hetzner, piattaforme AI, repository, console di amministrazione) seguono regole rafforzate affinché la perdita di un dispositivo non comporti mai la perdita di accesso:</p>
<ul>
<li><strong>Copia di sicurezza obbligatoria</strong>: ogni chiave critica ha una copia di backup cifrata; perdere un dispositivo non deve significare perdere l'accesso.</li>
<li><strong>Backup dei codici MFA</strong>: i codici di recupero MFA sono salvati nella cassaforte digitale cifrata, mai sullo stesso dispositivo che genera l'OTP.</li>
<li><strong>Backup periodico verificato</strong>: la cassaforte digitale è inclusa nei backup cifrati; si verifica periodicamente l'integrità e la ripristinabilità delle copie.</li>
<li><strong>Recupero a doppia autorizzazione</strong>: il recupero o l'estrazione di chiavi critiche richiede l'approvazione di <strong>due persone</strong> (Responsabile IT + RSGSI), per evitare abusi.</li>
<li><strong>Rotazione post-incidente</strong>: dopo furto, smarrimento o sospetta compromissione si rigenerano le credenziali coinvolte e si aggiorna la cassaforte.</li>
<li><strong>Dismissione</strong>: alla cessazione del rapporto si revocano gli accessi del collaboratore e si trasferiscono/ruotano le chiavi di sua competenza.</li>
</ul>
<h3>6.3 Divieti</h3>
<ul>
<li>Niente credenziali in chiaro su portatile, repository, email, chat o note personali.</li>
<li>Niente condivisione di password fuori dal gestore di segreti.</li>
<li>Niente backup delle chiavi su cloud personali o supporti non cifrati.</li>
</ul>
<h2>7. Controlli ISO collegati e riferimenti NIS2</h2>
<p><strong>A.8.24</strong> (uso della crittografia), <strong>A.8.5</strong> (autenticazione sicura), <strong>A.5.33</strong> (protezione delle registrazioni), <strong>A.5.17</strong> (informazioni di autenticazione), <strong>A.8.13</strong> (backup), <strong>A.5.23</strong> (sicurezza nei servizi cloud). Riferimenti cloud: ISO/IEC 27017/27018. Riferimento NIS2: D.Lgs. 138/2024 <strong>art.24</strong> (misure di gestione del rischio, incluse crittografia, controllo accessi e continuità). Le ISO sono buone prassi, non obblighi di legge.</p>
<h2>8. Registrazioni ed evidenze</h2>
<p>Inventario delle chiavi e dei certificati, log di rotazione, configurazioni TLS, evidenza della cifratura disco sui PC portatili, registro degli accessi al vault, log delle autorizzazioni doppie al recupero delle chiavi cloud.</p>
<h2>9. Riesame e versionamento</h2>
<p>Approvata dal Responsabile SGSI. Documento vivo, riesaminato almeno annualmente o a fronte di nuove vulnerabilità crittografiche, incidenti o cambiamenti rilevanti. Versione tracciata nella piattaforma SGSI.</p>
+124
View File
@@ -0,0 +1,124 @@
<!--META|doc_type=politica_uso_dispositivi|title=Politica di Uso Accettabile, Dispositivi e Lavoro da Remoto|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>Definire, in un unico documento "persone e strumenti", le regole con cui <strong>Nuova Agile Technology srl</strong> classifica le informazioni e usa in sicurezza dispositivi, account e servizi aziendali. L'azienda opera con modello <strong>Work-from-Anywhere senza sede fissa né perimetro fisico</strong> e interamente in cloud: il portatile è il principale punto di esposizione e va trattato come asset critico. La Politica copre classificazione delle informazioni, uso accettabile degli strumenti, dispositivi dedicati e separazione privato/lavoro, lavoro da remoto, posta e servizi aziendali, hardening degli endpoint e uso sicuro dell'AI.</p>
<h2>2. Ambito</h2>
<p>Si applica a tutto il personale (dipendenti e collaboratori esterni a P.IVA) che utilizza dispositivi, account e servizi aziendali (cloud Aruba/Hetzner, repository di codice, posta, strumenti di collaborazione, gestionali, piattaforme AI), ovunque si trovi e con qualsiasi rete. Riguarda tutte le informazioni gestite dall'Azienda — codice sorgente, documentazione, dati dei servizi SaaS inclusi i dati personali dei clienti, credenziali e segreti, documenti amministrativi e contrattuali — indipendentemente da formato e supporto. Non essendoci server in sede, l'attenzione è sugli <strong>endpoint mobili</strong> e sull'uso responsabile dei servizi cloud.</p>
<h2>3. Riferimenti</h2>
<ul>
<li>ISO/IEC 27001:2022 Annex A: A.5.10, A.5.12, A.5.13, A.5.14, A.5.17, A.6.7, A.7.9, A.8.1, A.8.5, A.8.7, A.8.9, A.8.10, A.8.12, A.8.24, A.5.23.</li>
<li>ISO/IEC 27018:2019 (protezione dei dati personali nel cloud); ISO/IEC 27017:2015 (servizi cloud).</li>
<li>GDPR; Direttiva NIS2 / D.Lgs. 138/2024.</li>
<li>Politica per la Sicurezza delle Informazioni; Politica di Controllo degli Accessi; Politica di Crittografia e Gestione delle Chiavi.</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<p>Il <strong>Responsabile IT e Sicurezza (Simon Fattori)</strong> configura e mantiene gli endpoint sicuri (cifratura, aggiornamenti, antimalware, firewall), gestisce MDM, MFA, SSO, account e revoche, e implementa le misure tecniche per livello di classificazione. Il <strong>Responsabile SGSI (Massimo Tagliavini)</strong> mantiene lo schema di classificazione e vigila sul rispetto della Politica. Il <strong>DPO (consulente esterno)</strong> presidia il corretto trattamento dei dati personali. L'<strong>Alta Direzione (Silvia Garretto)</strong> approva la Politica. Ogni utente è personalmente responsabile dell'uso corretto degli strumenti assegnati e, come proprietario o utilizzatore dell'informazione, della sua corretta classificazione e gestione.</p>
<h2>5. Classificazione delle informazioni</h2>
<h3>5.1 Schema di classificazione</h3>
<table>
<tr><th>Livello</th><th>Descrizione</th><th>Esempi</th></tr>
<tr><td><strong>Pubblico</strong></td><td>Destinato alla diffusione, nessun impatto se divulgato.</td><td>Materiale marketing, documentazione pubblica del prodotto</td></tr>
<tr><td><strong>Interno</strong></td><td>Uso interno; impatto limitato in caso di divulgazione non autorizzata.</td><td>Procedure interne, comunicazioni di team</td></tr>
<tr><td><strong>Riservato</strong></td><td>Sensibile aziendale o di terzi; impatto significativo se divulgato.</td><td>Codice sorgente proprietario, contratti, dati clienti non personali</td></tr>
<tr><td><strong>Strettamente riservato</strong></td><td>Massima sensibilità; impatto grave (legale, reputazionale, sanzionatorio).</td><td>Dati personali dei clienti nel SaaS, credenziali, chiavi API, segreti</td></tr>
</table>
<h3>5.2 Etichettatura e misure minime per livello</h3>
<p>Documenti e repository riportano, ove pertinente, il livello di classificazione; i dati personali sono trattati come <strong>Strettamente riservati</strong> per impostazione predefinita.</p>
<ul>
<li><strong>Pubblico</strong>: nessuna restrizione di accesso particolare; verifica di accuratezza prima della pubblicazione.</li>
<li><strong>Interno</strong>: accesso limitato al personale; non condividere all'esterno senza autorizzazione.</li>
<li><strong>Riservato</strong>: accesso su base need-to-know; trasmissione cifrata; conservazione nei sistemi aziendali autorizzati; divieto di copia su supporti non controllati.</li>
<li><strong>Strettamente riservato</strong>: cifratura obbligatoria a riposo e in transito; accesso con MFA e minimo privilegio; tracciabilità degli accessi; divieto di trasmissione a piattaforme AI senza minimizzazione/anonimizzazione; nessuna conservazione su supporti personali.</li>
</ul>
<h3>5.3 Dati personali nel SaaS, conservazione e cancellazione sicura</h3>
<ul>
<li>Trattamento secondo le istruzioni documentate dei clienti (in qualità di responsabile del trattamento), con isolamento per tenant; minimizzazione e limitazione della conservazione; supporto ai diritti degli interessati e alle richieste di cancellazione (ISO 27018 / GDPR).</li>
<li>I periodi di conservazione sono definiti per categoria e in base a obblighi legali e contrattuali.</li>
<li>La cancellazione avviene in modo sicuro (cancellazione logica irreversibile nei sistemi cloud, distruzione delle copie); per i PC portatili la dismissione prevede wipe sicuro o riformattazione con disco già cifrato.</li>
</ul>
<h2>6. Uso accettabile degli strumenti</h2>
<ul>
<li>Gli strumenti aziendali sono destinati prevalentemente a finalità professionali; un uso personale limitato e ragionevole è tollerato se non compromette sicurezza e produttività.</li>
<li>È <strong>vietato</strong>: installare software non autorizzato o da fonti non attendibili; disattivare le misure di sicurezza (cifratura, antimalware, aggiornamenti); condividere credenziali; aggirare i controlli di accesso; trattare dati aziendali su servizi personali non approvati.</li>
<li>Condividere informazioni riservate solo con destinatari autorizzati e tramite canali e strumenti aziendali approvati; evitare app di messaggistica personali per documenti di lavoro.</li>
</ul>
<h2>7. Dispositivi aziendali e separazione privato/lavoro</h2>
<ul>
<li><strong>Un portatile e uno smartphone aziendali per persona</strong>, dedicati e gestiti centralmente tramite <strong>MDM</strong>; l'accesso a sistemi e dati avviene esclusivamente da questi dispositivi, mai da dispositivi privati.</li>
<li><strong>Uso solo professionale</strong>: niente uso personale, niente account privati, niente app fuori dal catalogo approvato; privilegi di amministratore limitati e concessi solo da IT.</li>
<li><strong>Cifratura di default</strong>: full-disk encryption su portatili (BitLocker/FileVault/LUKS), smartphone cifrato con blocco schermo obbligatorio (PIN/biometria).</li>
<li><strong>Secure-by-default</strong>: aggiornamenti automatici di sistema e applicazioni, antimalware attivo e aggiornato, firewall locale attivo, blocco automatico dello schermo dopo inattività, servizi non necessari disabilitati.</li>
<li><strong>Nessuna credenziale in chiaro sul dispositivo</strong>: password e chiavi vivono nel password manager aziendale (vedi Politica di Crittografia e Gestione delle Chiavi).</li>
<li><strong>MDM e controllo remoto</strong>: IT può applicare policy, distribuire aggiornamenti e, in caso di furto/smarrimento, eseguire blocco o cancellazione remota (wipe).</li>
<li><strong>Separazione privato/lavoro</strong>: i dati personali del collaboratore non risiedono sui dispositivi aziendali e i dati aziendali non risiedono sui dispositivi privati; niente sincronizzazione con cloud personali. Così, in caso di wipe remoto, non si perdono dati personali perché non devono esserci.</li>
<li><strong>Restituzione e fine rapporto</strong>: alla cessazione o riassegnazione il dispositivo è restituito, ripulito (wipe) e riconfigurato; gli accessi associati sono revocati e le chiavi ruotate.</li>
</ul>
<h2>8. Hardening del PC portatile</h2>
<p>Passi minimi e obbligatori per configurare ogni portatile aziendale, indipendentemente dal sistema operativo:</p>
<ol>
<li><strong>Cifratura del disco (obbligatoria)</strong> prima di salvare qualsiasi dato (BitLocker con TPM+PIN / FileVault / LUKS); chiave di recupero solo nel password manager aziendale.</li>
<li><strong>Account e privilegi</strong>: account standard per il lavoro quotidiano (non navigare né leggere email da account amministratore); account ospite/predefiniti rinominati o disabilitati.</li>
<li><strong>Blocco schermo</strong> automatico dopo massimo 5 minuti di inattività con password/biometria allo sblocco; blocco manuale lasciando la postazione.</li>
<li><strong>Firmware/UEFI</strong>: password al firmware ove possibile, Secure Boot abilitato, avvio da USB disabilitato se non necessario.</li>
<li><strong>Firewall e servizi</strong>: firewall locale attivo; condivisione file/stampanti, desktop remoto e servizi non usati disattivati.</li>
<li><strong>Antimalware</strong> attivo con protezione in tempo reale e aggiornamenti automatici.</li>
<li><strong>Aggiornamenti</strong> automatici di sistema e applicazioni abilitati.</li>
<li><strong>Backup</strong>: lavoro su repository e storage cloud aziendali (codice versionato in git, documenti sui drive aziendali), non solo in locale; si evita l'accumulo di dati riservati in locale e l'uso di supporti rimovibili non cifrati.</li>
<li><strong>Software</strong>: solo da fonti ufficiali e necessario al lavoro; rimosse applicazioni inutili ed estensioni browser non indispensabili.</li>
<li><strong>MDM</strong>: non rimuovere l'agente né eludere le policy applicate.</li>
</ol>
<p><strong>Verifiche di esito</strong>: disco cifrato con chiave nel password manager; blocco schermo ≤ 5 minuti; firewall e antimalware attivi con ultimo aggiornamento entro 7 giorni; nessun account amministratore usato per attività quotidiane.</p>
<h2>9. Lavoro da remoto e mobilità</h2>
<ul>
<li><strong>Solo dispositivi aziendali</strong> e accesso sempre con <strong>MFA e SSO</strong>; le sessioni hanno timeout automatico.</li>
<li><strong>Reti non fidate</strong>: su Wi-Fi pubblici o di terzi usare sempre connessioni cifrate (HTTPS/TLS, VPN aziendale ove prevista); mai disattivare la cifratura per "far funzionare" un servizio.</li>
<li><strong>Privacy fisica dello schermo</strong>: in luoghi pubblici evitare la visibilità (shoulder surfing), usare filtri privacy quando possibile, bloccare lo schermo allontanandosi anche per pochi minuti.</li>
<li><strong>Asset fuori sede</strong>: dispositivi mai lasciati incustoditi in auto, mezzi o spazi pubblici; in viaggio sempre con sé o in luogo sicuro.</li>
<li><strong>Nessun dato sensibile in chiaro fuori dai sistemi gestiti</strong>: niente download su supporti non cifrati, stampe non necessarie o copie su servizi personali.</li>
</ul>
<h2>10. Posta elettronica e servizi aziendali</h2>
<ul>
<li><strong>Account aziendali, non personali</strong>: il lavoro si svolge solo con caselle e account forniti e amministrati dalla società; vietato usare account personali per attività lavorative.</li>
<li><strong>Controllo della società</strong>: l'azienda amministra creazione, configurazione, sospensione e cancellazione degli account (admin centralizzato, SSO), nel rispetto della normativa privacy e con il coinvolgimento del DPO per gli aspetti di protezione dei dati personali.</li>
<li><strong>Niente inoltro a caselle personali</strong>: vietato l'auto-inoltro o l'inoltro sistematico di email di lavoro verso indirizzi personali o esterni non autorizzati.</li>
<li><strong>MFA obbligatoria</strong> su email e su tutti i servizi; password robuste gestite nel password manager aziendale; <strong>SSO ove possibile</strong> per centralizzare controllo e revoche.</li>
<li><strong>Ciclo di vita degli account</strong>: onboarding con privilegi minimi necessari (least privilege), diritti rivisti periodicamente secondo il ruolo, offboarding con disattivazione e revoca tempestiva alla cessazione del rapporto (la casella resta sotto controllo della società).</li>
</ul>
<h2>11. Posta, phishing e segnalazione degli eventi</h2>
<ul>
<li>Prudenza con allegati e link sospetti; verifica dell'identità del mittente prima di azioni sensibili (es. cambi di pagamento, invio credenziali).</li>
<li>Segnalazione tempestiva al Responsabile IT/SGSI di tentativi di phishing, social engineering, anomalie o sospette compromissioni.</li>
<li>Smarrimento o furto di un dispositivo o accesso anomalo va segnalato <strong>immediatamente</strong> al Responsabile IT: IT procede con blocco/wipe remoto via MDM e revoca/rotazione delle credenziali coinvolte. Le chiavi di accesso al cloud restano recuperabili grazie al key escrow controllato (vedi Politica di Crittografia e Gestione delle Chiavi), quindi lo smarrimento del dispositivo non causa perdita di accesso.</li>
<li>La segnalazione consente la valutazione e, se necessario, la notifica secondo gli obblighi NIS2 (pre-allarme entro 24 ore, notifica entro 72 ore, relazione finale entro 1 mese al CSIRT Italia/ACN, ove l'Azienda risulti soggetto obbligato, art. 25 D.Lgs. 138/2024).</li>
</ul>
<h2>12. Uso sicuro delle piattaforme AI</h2>
<ul>
<li><strong>Solo strumenti approvati</strong> dal Resp. IT, protetti da MFA; eventuali accordi/DPA con il fornitore verificati da Resp. IT/DPO.</li>
<li><strong>Mai dati personali dei clienti</strong> nei prompt (nomi, email, contatti, dati contenuti nel SaaS) salvo accordo/DPA adeguato e minimizzazione.</li>
<li><strong>Mai segreti</strong>: password, chiavi API, token, certificati, stringhe di connessione o configurazioni di produzione restano nel gestore segreti, non nei prompt.</li>
<li><strong>Minimizza e anonimizza</strong>: sostituisci i dati identificativi con segnaposto (es. "CLIENTE_X"); condividi solo il minimo necessario.</li>
<li><strong>Codice sorgente</strong>: non caricare interi repository proprietari o codice contenente segreti; estrai solo lo snippet rilevante e ripulito.</li>
<li><strong>Verifica gli output</strong>: tratta le risposte come bozze da verificare per correttezza, sicurezza del codice e assenza di riferimenti inventati prima dell'uso in produzione o verso i clienti.</li>
<li><strong>Impostazioni privacy</strong>: dove possibile, disabilita l'uso dei tuoi dati per l'addestramento e usa i piani/impostazioni aziendali concordati.</li>
<li><strong>Nel dubbio non inviare</strong> e chiedi prima al Resp. IT. Se hai inviato per errore dati personali o segreti, contatta subito il Resp. IT (e il DPO per i dati personali): può configurare un incidente da valutare.</li>
</ul>
<h2>13. Controlli ISO collegati e riferimenti NIS2</h2>
<p><strong>A.5.10</strong> (uso accettabile), <strong>A.5.12/A.5.13/A.5.14</strong> (classificazione, etichettatura, trasferimento delle informazioni), <strong>A.5.17</strong> (informazioni di autenticazione), <strong>A.6.7</strong> (lavoro da remoto), <strong>A.7.9</strong> (sicurezza degli asset fuori sede), <strong>A.8.1</strong> (dispositivi endpoint), <strong>A.8.5</strong> (autenticazione sicura), <strong>A.8.7</strong> (protezione dai malware), <strong>A.8.9</strong> (gestione della configurazione), <strong>A.8.10/A.8.12</strong> (cancellazione delle informazioni, prevenzione della fuga di dati), <strong>A.8.24</strong> (crittografia), <strong>A.5.23</strong> (sicurezza nei servizi cloud). Cloud: ISO/IEC 27017/27018. Riferimenti NIS2: D.Lgs. 138/2024 <strong>art.24</strong> (misure di gestione del rischio, tra cui igiene informatica di base, crittografia, controllo accessi e formazione) e <strong>art.25</strong> (obblighi di notifica degli incidenti). Le ISO sono buone prassi, non obblighi di legge.</p>
<h2>14. Registrazioni ed evidenze</h2>
<p>Accettazione della Politica da parte del personale; schema di classificazione e inventario degli asset informativi con livello; inventario degli endpoint con stato di cifratura e aggiornamento; registro delle segnalazioni di eventi/incidenti; registro dei trattamenti (GDPR) ed evidenze di cancellazione sicura.</p>
<h2>15. Riesame e versionamento</h2>
<p>Approvata dall'Alta Direzione. Documento vivo, riesaminato almeno annualmente o a fronte di nuove minacce rilevanti, cambiamenti del parco dispositivi o adozione di nuovi strumenti (incl. AI). Versione tracciata nella piattaforma SGSI.</p>
+91
View File
@@ -0,0 +1,91 @@
<!--META|doc_type=politica_cloud_privacy|title=Politica di Sicurezza del Cloud e Protezione dei Dati (ISO 27017/27018, GDPR)|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>La presente Politica definisce i principi e le regole con cui <strong>Nuova Agile Technology srl</strong> utilizza in sicurezza i servizi cloud su cui poggia interamente la propria operatività e protegge i dati personali (PII) che vi tratta per conto dei propri clienti. Poiché l'infrastruttura aziendale è <strong>integralmente in cloud</strong> (Aruba S.p.A. – Italia; Hetzner – Germania, UE) e in sede non esiste alcun server, la corretta configurazione e gestione dei servizi cloud è essenziale per la sicurezza delle informazioni dell'azienda e dei clienti. La Politica recepisce i controlli cloud-specifici della <strong>ISO/IEC 27017:2015</strong> (chiarendo il <strong>modello di responsabilità condivisa</strong> tra azienda e fornitori) e i controlli della <strong>ISO/IEC 27018:2019</strong> per la tutela dei PII nei cloud pubblici, in coerenza con il <strong>Regolamento (UE) 2016/679 (GDPR)</strong>. Nel trattare i PII via <strong>SaaS multi-tenant</strong>, l'azienda agisce di norma come <strong>responsabile del trattamento</strong> per conto del cliente (titolare).</p>
<h2>2. Ambito</h2>
<p>La Politica si applica a tutti i servizi cloud utilizzati per: l'erogazione del SaaS multi-tenant; l'ospitalità di ambienti di sviluppo, test e strumenti interni; l'archiviazione di dati aziendali e dei clienti; i servizi di intelligenza artificiale fruiti via API (es. LLM Anthropic). Copre tutti i trattamenti di PII di clienti e interessati finali svolti tramite l'infrastruttura cloud (Aruba IT, Hetzner DE) e i servizi accessori, per l'intero ciclo di vita del dato: raccolta, archiviazione, elaborazione, trasferimento, conservazione e cancellazione. Si applica a tutto il personale (9 dipendenti, 2 collaboratori esterni a P.IVA) che configura, amministra o accede a tali servizi — esclusivamente tramite <strong>PC portatili cifrati</strong> — e ai sub-fornitori che concorrono al trattamento.</p>
<h2>3. Riferimenti</h2>
<ul>
<li>ISO/IEC 27017:2015 – controlli cloud-specifici (CLD.6.3, CLD.8.1, CLD.9.5, CLD.12.1, CLD.12.4, CLD.13.1) e modello di responsabilità condivisa.</li>
<li>ISO/IEC 27018:2019 – codice di condotta per la protezione dei PII nei cloud pubblici.</li>
<li>ISO/IEC 27001:2022 – Annex A, in particolare A.5.23 (uso di servizi cloud), A.5.34 (privacy e protezione dei PII), A.8.9, A.8.10, A.8.11, A.8.12, A.8.13, A.8.15, A.8.24.</li>
<li>Regolamento (UE) 2016/679 (GDPR) – artt. 5, 28, 30, 32, 33, 44-49.</li>
<li>D.Lgs. 138/2024, art. 24 (misure di gestione del rischio) e art. 25 (notifica incidenti).</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<table>
<tr><th>Ruolo</th><th>Responsabilità</th></tr>
<tr><td>Presidente (Silvia Garretto)</td><td>Approva la Politica e l'adozione/dismissione di servizi cloud strategici; garantisce le risorse per la conformità privacy.</td></tr>
<tr><td>RSGSI (Massimo Tagliavini)</td><td>Mantiene la Politica, coordina la valutazione dei rischi cloud, integra i requisiti privacy nel SGSI e gestisce i riesami.</td></tr>
<tr><td>Resp. IT/Sicurezza (Simon Fattori)</td><td>Configura e amministra i servizi cloud secondo la responsabilità condivisa; attua le misure tecniche (accessi, cifratura, log, hardening, cancellazione).</td></tr>
<tr><td>DPO (consulente esterno)</td><td>Sorveglia la conformità GDPR/27018, supporta i DPA, le richieste degli interessati, i trasferimenti di dati personali e la gestione dei data breach.</td></tr>
</table>
<h2>5. Modello di responsabilità condivisa</h2>
<p>Per ogni servizio cloud è documentata la ripartizione delle responsabilità di sicurezza tra <strong>fornitore</strong> (sicurezza fisica dei data center, hypervisor, rete sottostante, disponibilità dell'infrastruttura) e <strong>azienda cliente</strong> (configurazione dei servizi, gestione degli account e degli accessi, cifratura dei dati a riposo e in transito, gestione delle chiavi, backup applicativi, logging). La consapevolezza di "ciò che il fornitore fa per noi e ciò che dobbiamo fare noi" è la base della Politica (CLD.6.3).</p>
<h2>6. Selezione, collocazione e trasferimenti</h2>
<ul>
<li>Si privilegiano fornitori cloud con certificazioni di sicurezza riconosciute e data center nell'UE/SEE (Aruba in Italia, Hetzner in Germania) per favorire la conformità GDPR; i PII sono ospitati di preferenza su tali data center.</li>
<li>Eventuali servizi e trasferimenti extra-UE (es. API AI) sono adottati solo con garanzie adeguate ai sensi degli artt. 44-49 GDPR, DPA idonei e documentazione del trasferimento.</li>
</ul>
<h2>7. Ruolo di responsabile, trasparenza e sub-fornitori</h2>
<ul>
<li>L'azienda tratta i PII dei clienti <strong>solo su istruzione documentata del titolare</strong> (art. 28 GDPR; principio 27018) e per le finalità del servizio, senza usi propri non autorizzati.</li>
<li>Con ogni cliente che affida PII è stipulato un <strong>DPA ex art. 28 GDPR</strong> che disciplina finalità, durata, misure di sicurezza, sub-responsabili e assistenza al titolare.</li>
<li>I sub-fornitori che trattano PII (provider cloud, eventuali servizi AI) sono dichiarati al cliente e vincolati a obblighi di protezione equivalenti; i cambi rilevanti di sub-fornitore sono comunicati al titolare secondo gli accordi.</li>
</ul>
<h2>8. Misure di sicurezza tecniche</h2>
<ul>
<li>Cifratura dei dati e dei PII in transito (TLS) e a riposo; gestione sicura delle chiavi (A.8.24).</li>
<li>Accessi amministrativi nominali, autenticazione forte (MFA), principio del minimo privilegio, separazione dei ruoli e revisione periodica delle utenze, con revoca tempestiva al termine del rapporto; tracciamento degli accessi ai PII. L'accesso avviene solo da PC portatili cifrati e aggiornati.</li>
<li>Isolamento e segregazione dei dati tra tenant nel SaaS multi-tenant (CLD.9.5); gli ambienti di test non utilizzano PII reali (dati anonimizzati/sintetici).</li>
<li>Configurazioni sicure (hardening) e disabilitazione dei servizi non necessari.</li>
</ul>
<h2>9. Logging, monitoraggio e gestione operativa</h2>
<ul>
<li>Abilitazione dei log di sicurezza, degli accessi amministrativi e delle operazioni sui PII resi disponibili dai fornitori; conservazione e revisione periodica (CLD.12.1, CLD.12.4).</li>
<li>Monitoraggio della disponibilità dei servizi e degli avvisi di sicurezza dei fornitori cloud.</li>
<li>Gestione coordinata dei cambiamenti che impattano i servizi cloud.</li>
</ul>
<h2>10. Diritti degli interessati, continuità, conservazione e cancellazione</h2>
<ul>
<li>L'azienda assiste il titolare nel dare seguito alle richieste degli interessati (accesso, rettifica, cancellazione, portabilità, opposizione), fornendo gli strumenti tecnici per individuare ed estrarre/cancellare i dati nel SaaS.</li>
<li>Backup e ripristino sono gestiti coerentemente con la Politica di Continuità, tenendo conto della responsabilità condivisa.</li>
<li>I PII sono conservati per il tempo previsto dal contratto/dalla finalità; alla cessazione di un servizio o del rapporto si garantisce l'esportazione dei dati e la loro cancellazione sicura, anche presso i provider cloud (CLD.8.1).</li>
</ul>
<h2>11. Gestione incidenti e violazioni di dati personali</h2>
<p>Gli incidenti che coinvolgono i servizi cloud sono gestiti secondo il processo di gestione incidenti del SGSI. In caso di data breach, l'azienda informa <strong>senza ingiustificato ritardo</strong> il titolare (art. 33 GDPR), supportandolo nelle valutazioni e notifiche. Se l'evento è anche un incidente NIS2 rilevante e l'azienda è soggetto obbligato, si rispettano i tempi di notifica al CSIRT Italia (pre-allarme 24h, notifica 72h, relazione finale 1 mese, art. 25 D.Lgs. 138/2024); il coordinamento tra notifica privacy e notifica NIS2 è gestito dal DPO con il RSGSI.</p>
<h2>12. Controlli ISO collegati e riferimenti NIS2</h2>
<ul>
<li><strong>CLD.6.3</strong> – Ripartizione delle responsabilità tra cliente e fornitore cloud.</li>
<li><strong>CLD.8.1</strong> – Rimozione/restituzione degli asset cliente al termine del servizio.</li>
<li><strong>CLD.9.5</strong> – Segregazione negli ambienti virtuali multi-tenant.</li>
<li><strong>CLD.12.1 / CLD.12.4</strong> – Operatività e logging dei servizi cloud.</li>
<li><strong>CLD.13.1</strong> – Gestione della sicurezza di rete nel cloud.</li>
<li>Controlli <strong>ISO/IEC 27018</strong>: consenso e scopo, trasparenza sui sub-fornitori, cancellazione sicura, notifica accessi, restrizione d'uso dei PII, tracciamento.</li>
<li><strong>A.5.23</strong> – Sicurezza nell'uso di servizi cloud; <strong>A.5.34</strong> – privacy e protezione dei PII.</li>
<li><strong>A.8.10 / A.8.11</strong> – Cancellazione e mascheramento dei dati; <strong>A.8.12</strong> – prevenzione della fuga di dati; <strong>A.8.24</strong> – uso della crittografia.</li>
<li><strong>GDPR</strong>: artt. 5, 28, 30, 32, 33, 44-49.</li>
<li><strong>NIS2 – D.Lgs. 138/2024</strong>: art. 24 (misure di gestione del rischio), art. 25 (notifica incidenti).</li>
</ul>
<h2>13. Registrazioni ed evidenze</h2>
<ul>
<li>Matrice di responsabilità condivisa per ciascun servizio cloud; inventario dei servizi cloud e relative configurazioni di sicurezza.</li>
<li>DPA con i clienti e con i sub-responsabili; elenco dei sub-fornitori; registro dei trattamenti per conto del titolare (supporto art. 30 GDPR).</li>
<li>Registro degli accessi amministrativi e ai PII; log di sicurezza conservati; registro delle richieste degli interessati.</li>
<li>Registro dei data breach e relative comunicazioni al titolare; evidenze dei riesami periodici di configurazioni e accessi.</li>
</ul>
<h2>14. Riesame e versionamento</h2>
<p>La Politica è riesaminata almeno annualmente o a fronte dell'adozione di nuovi servizi cloud, nuovi trattamenti, cambi di sub-fornitori, modifiche architetturali, aggiornamenti normativi o incidenti rilevanti. Versione corrente: <strong>2.0</strong>, approvata dalla Presidente con il parere del DPO. Le revisioni sono tracciate nel sistema documentale del SGSI a cura del RSGSI.</p>
+89
View File
@@ -0,0 +1,89 @@
<!--META|doc_type=politica_fornitori|title=Politica e Procedura di Gestione dei Fornitori e dei Servizi Cloud|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>Definire principi, regole e passi operativi con cui <strong>Nuova Agile Technology srl</strong> seleziona, qualifica, contrattualizza, sorveglia e dismette i propri fornitori, con particolare attenzione a quelli rilevanti per la sicurezza delle informazioni: infrastruttura cloud (<strong>Aruba</strong> IT, <strong>Hetzner</strong> DE), servizi di <strong>intelligenza artificiale</strong> via API (es. LLM Anthropic), sviluppo e manutenzione software. Lo scopo è mantenere il livello di sicurezza richiesto dal SGSI anche quando attività o dati sono affidati a terze parti, in modo ripetibile e tracciabile, e propagare lungo la supply chain gli obblighi di sicurezza previsti dall'<strong>art. 24 del D.Lgs. 138/2024</strong> (NIS2).</p>
<h2>2. Ambito</h2>
<p>Si applica a tutti i fornitori, sub-fornitori e prestatori di servizi, nuovi ed esistenti, che: (a) trattano, ospitano o accedono a informazioni aziendali o dei clienti; (b) erogano infrastruttura cloud (Aruba – Italia; Hetzner – Germania, UE); (c) forniscono servizi AI tramite API; (d) contribuiscono allo sviluppo, manutenzione o assistenza dei prodotti, sia in licenza on-premise sia SaaS multi-tenant. Coinvolge tutto il personale che richiede, valuta e gestisce i fornitori (9 dipendenti, 2 collaboratori esterni a P.IVA).</p>
<h2>3. Riferimenti</h2>
<ul>
<li>ISO/IEC 27001:2022 – Annex A: A.5.19, A.5.20, A.5.21, A.5.22, A.5.23.</li>
<li>ISO/IEC 27017:2015 (CLD.6.3, CLD.8.1; modello di responsabilità condivisa) e ISO/IEC 27018:2019 (tutela delle PII nel cloud).</li>
<li>D.Lgs. 138/2024, art. 24 (sicurezza della supply chain) e art. 25 (notifica incidenti).</li>
<li>Regolamento (UE) 2016/679 (GDPR), art. 28 (responsabili del trattamento).</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<table>
<tr><th>Ruolo</th><th>Responsabilità</th></tr>
<tr><td>Presidente (Silvia Garretto)</td><td>Approva il documento, autorizza l'ingaggio dei fornitori critici e accetta i rischi residui.</td></tr>
<tr><td>RSGSI (Massimo Tagliavini)</td><td>Mantiene il documento, classifica i fornitori, gestisce il registro, coordina valutazioni e riesami periodici.</td></tr>
<tr><td>Resp. IT/Sicurezza (Simon Fattori)</td><td>Valuta tecnicamente i fornitori, verifica certificazioni e misure, definisce la matrice di responsabilità condivisa, monitora SLA e incidenti.</td></tr>
<tr><td>DPO (esterno)</td><td>Valida gli aspetti privacy, i DPA e i trasferimenti di dati personali.</td></tr>
</table>
<h2>5. Principi</h2>
<ul>
<li><strong>Classificazione per criticità</strong>: ogni fornitore è classificato in funzione del dato e del servizio — <strong>critico</strong> (cloud, AI, accesso a PII di clienti), <strong>rilevante</strong> (sviluppo/manutenzione), <strong>ordinario</strong> (servizi non legati alle informazioni). La classe determina la profondità della due diligence.</li>
<li><strong>Dati nell'UE</strong>: si privilegiano fornitori con certificazioni riconosciute e data center nell'UE/SEE (Aruba in Italia, Hetzner in Germania); per trasferimenti extra-UE si verificano garanzie adeguate.</li>
<li><strong>Propagazione lungo la supply chain</strong>: essendo l'azienda fornitore di clienti soggetti a NIS2, i requisiti di sicurezza ricevuti dai clienti vengono recepiti e ribaltati sui propri sub-fornitori, così che le misure scendano coerentemente lungo l'intera catena (art. 24 D.Lgs. 138/2024).</li>
</ul>
<h2>6. Processo</h2>
<h3>6.1 Richiesta e classificazione</h3>
<ul>
<li>Il richiedente apre una richiesta indicando servizio, dati coinvolti e finalità.</li>
<li>Il RSGSI assegna la classe di criticità (critico / rilevante / ordinario).</li>
</ul>
<h3>6.2 Due diligence e valutazione di sicurezza</h3>
<ul>
<li>Per i fornitori critici/rilevanti il Resp. IT raccoglie evidenze: certificazioni (ISO 27001/27017/27018, SOC 2), localizzazione dei data center, misure tecniche/organizzative, gestione incidenti.</li>
<li>Si compila una scheda di valutazione con esito (idoneo / idoneo con prescrizioni / non idoneo).</li>
<li>Per i servizi cloud si definisce la <strong>matrice di responsabilità condivisa</strong> (cosa fa il fornitore, cosa fa l'azienda).</li>
</ul>
<h3>6.3 Contrattualizzazione (clausole e DPA)</h3>
<ul>
<li>Il contratto include clausole di sicurezza: riservatezza, SLA, obbligo di notifica incidenti, diritto a evidenze/audit, gestione del fine rapporto e restituzione/cancellazione dei dati.</li>
<li>Quando sono trattati dati personali si stipula un <strong>DPA ex art. 28 GDPR</strong>, verificando i sub-responsabili e le clausole 27018.</li>
<li>Si richiede al fornitore la notifica tempestiva degli incidenti, coerente con i tempi NIS2 (pre-allarme 24h, notifica 72h, relazione finale 1 mese) quando l'azienda è soggetto obbligato.</li>
<li>L'attivazione dei fornitori critici richiede l'autorizzazione della Presidente.</li>
</ul>
<h3>6.4 Attivazione e configurazione sicura</h3>
<ul>
<li>Accessi nominali con MFA e minimo privilegio, cifratura e logging.</li>
<li>Il fornitore è inserito nel <strong>registro fornitori</strong> con classificazione, scadenze contrattuali e referenti.</li>
</ul>
<h3>6.5 Monitoraggio e riesame periodico</h3>
<ul>
<li>Almeno annualmente per i fornitori critici: verifica SLA, rinnovo evidenze e certificazioni, revisione accessi, analisi di eventuali incidenti.</li>
<li>Valutazione degli avvisi di sicurezza dei fornitori cloud/AI e del loro impatto; gli esiti sono registrati.</li>
<li>Le non conformità generano azioni correttive tracciate; in caso di non conformità grave o incidente, si valuta la sostituzione del fornitore.</li>
</ul>
<h3>6.6 Gestione incidenti del fornitore</h3>
<p>In caso di incidente comunicato dal fornitore o rilevato dall'azienda si attiva il processo di gestione incidenti del SGSI; se l'evento è un incidente NIS2 significativo e l'azienda è soggetto obbligato, si rispettano i tempi di notifica al CSIRT Italia (pre-allarme 24h, notifica 72h, relazione finale 1 mese; art. 25 D.Lgs. 138/2024). Gli incidenti che coinvolgono PII sono comunicati al DPO.</p>
<h3>6.7 Dismissione e fine rapporto</h3>
<ul>
<li>Revoca degli accessi, recupero/esportazione dei dati e verifica della cancellazione sicura presso il fornitore (CLD.8.1).</li>
<li>Aggiornamento del registro fornitori e valutazione dell'impatto sulla continuità.</li>
</ul>
<h2>7. Controlli ISO collegati e riferimenti NIS2</h2>
<ul>
<li><strong>A.5.19 / A.5.20</strong> – Sicurezza nei rapporti e negli accordi con i fornitori.</li>
<li><strong>A.5.21</strong> – Sicurezza nella catena di fornitura ICT.</li>
<li><strong>A.5.22</strong> – Monitoraggio, riesame e gestione dei cambiamenti dei servizi dei fornitori.</li>
<li><strong>A.5.23</strong> – Sicurezza nell'uso di servizi cloud; <strong>CLD.6.3 / CLD.8.1</strong> (ISO 27017); ISO 27018 per le PII.</li>
<li><strong>NIS2 – D.Lgs. 138/2024</strong>: art. 24 (sicurezza della supply chain); art. 25 (notifica incidenti).</li>
</ul>
<h2>8. Registrazioni ed evidenze</h2>
<ul>
<li>Registro dei fornitori (classificazione di criticità, scadenze, referenti, stato di qualifica).</li>
<li>Schede di valutazione di sicurezza e matrici di responsabilità condivisa.</li>
<li>Contratti, DPA e clausole di sicurezza archiviati.</li>
<li>Verbali dei riesami periodici, registro azioni correttive e registro incidenti dei fornitori.</li>
</ul>
<h2>9. Riesame e versionamento</h2>
<p>Il documento è riesaminato almeno annualmente o a fronte di cambiamenti significativi (nuovi fornitori critici, incidenti rilevanti, evoluzioni normative). Approvato dalla Presidente. Le revisioni sono tracciate nel sistema documentale del SGSI con numero di versione, data e responsabile dell'aggiornamento (RSGSI).</p>
+48
View File
@@ -0,0 +1,48 @@
<!--META|doc_type=procedura_gestione_rischio|title=Procedura di Gestione del Rischio (valutazione e trattamento)|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>Definire le modalità con cui <strong>Nuova Agile Technology srl</strong> identifica, analizza, valuta e tratta i rischi per la sicurezza delle informazioni, in modo sistematico e ripetibile. Attua i requisiti ISO/IEC 27001:2022 cl. 6.1.2 (valutazione), 6.1.3 (trattamento), 8.2 e 8.3 (esecuzione) e supporta la determinazione delle misure ex art. 24 D.Lgs. 138/2024 (NIS2) per i soggetti rientranti.</p>
<h2>2. Ambito</h2>
<p>Si applica a tutte le informazioni e agli asset aziendali: codice sorgente e prodotti on-premise, piattaforma SaaS in cloud, dati personali dei clienti, infrastruttura cloud (Aruba IT, Hetzner DE, piattaforme AI) e PC portatili. Non essendoci server in sede, l'analisi considera i rischi di un modello <em>cloud-only</em> (responsabilità condivisa; controlli ISO/IEC 27017 e 27018 per le PII).</p>
<h2>3. Riferimenti</h2>
<ul>
<li>ISO/IEC 27001:2022 cl. 6.1.2, 6.1.3, 8.2, 8.3; controlli A.5.7, A.5.9, A.8.8.</li>
<li>ISO/IEC 27005 (stima del rischio) e ISO 31000.</li>
<li>ISO/IEC 27017 §CLD.6.3 e 27018 (rischi cloud e PII).</li>
<li>D.Lgs. 138/2024 art. 24; Determinazione ACN 164179/2025 [DA VERIFICARE riferimento applicabile].</li>
<li>SoA, Politica del SGSI, Procedura NC/Azioni Correttive.</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<ul>
<li><strong>Direzione (Silvia Garretto)</strong>: approva criteri e propensione al rischio (risk appetite) e il piano di trattamento; accetta formalmente i rischi residui.</li>
<li><strong>RSGSI (Massimo Tagliavini)</strong>: conduce e coordina la valutazione, mantiene il registro dei rischi, propone il piano di trattamento, monitora le scadenze.</li>
<li><strong>Resp. IT/Sicurezza (Simon Fattori)</strong>: fornisce l'inventario asset e le informazioni su minacce/vulnerabilità, implementa i controlli tecnici.</li>
<li><strong>DPO esterno</strong>: consultato per i rischi sui dati personali (PII nel SaaS).</li>
</ul>
<h2>5. Flusso passo-passo</h2>
<ol>
<li><strong>Contesto e criteri</strong> (input: SoA, inventario asset). RSGSI e Direzione fissano scala di probabilità (1–5) e impatto (1–5), soglia di accettabilità e criteri di significatività.</li>
<li><strong>Identificazione</strong> (input: asset, minacce, vulnerabilità). Per ciascun asset si individuano le minacce plausibili (es. compromissione credenziali cloud, data breach SaaS, perdita di un portatile, indisponibilità del provider) e si registra ogni rischio nel <em>modulo "Rischi"</em>.</li>
<li><strong>Analisi e ponderazione</strong>. Rischio = Probabilità × Impatto secondo la matrice 5×5 (coerente con ISO/IEC 27005); il punteggio determina la classe (basso/medio/alto/critico).</li>
<li><strong>Valutazione</strong>: confronto con la soglia. I rischi sopra soglia richiedono trattamento; quelli sotto soglia sono candidati all'accettazione.</li>
<li><strong>Trattamento</strong>. Per ogni rischio sopra soglia si sceglie l'opzione: <em>mitigazione</em> (controlli Annex A), <em>trasferimento</em> (clausole contrattuali col provider, assicurazione), <em>evitamento</em> o <em>accettazione</em>. I controlli scelti sono registrati come trattamenti e riconciliati con la SoA.</li>
<li><strong>Approvazione e accettazione del rischio residuo</strong>: la Direzione approva il piano e accetta formalmente i rischi residui (cl. 6.1.3 e).</li>
<li><strong>Attuazione e monitoraggio</strong>: il Resp. IT implementa i controlli; il RSGSI traccia stato e scadenze. Le carenze rilevate diventano Non Conformità.</li>
</ol>
<h2>6. Controlli ISO/clausole collegati</h2>
<p>cl. 6.1.2/6.1.3 (processo e piano), cl. 8.2/8.3 (esecuzione e SoA aggiornata); A.5.7 (threat intelligence), A.5.9 (inventario asset), A.8.8 (gestione vulnerabilità tecniche); per il cloud A.5.19–A.5.23 e i controlli estesi ISO/IEC 27017 e 27018 sulle PII.</p>
<h2>7. Registrazioni ed evidenze</h2>
<ul>
<li><strong>Registro dei rischi e trattamenti</strong>: modulo "Rischi" (rischio inerente, controlli, rischio residuo, owner, scadenze).</li>
<li><strong>Piano di trattamento e accettazione rischi residui</strong>: verbale di approvazione della Direzione, archiviato come informazione documentata.</li>
<li><strong>SoA aggiornata</strong> (modulo SGSI/SoA).</li>
</ul>
<h2>8. Riesame e versionamento</h2>
<p>La valutazione è riesaminata <strong>almeno una volta l'anno</strong> e a ogni cambiamento significativo (nuovo prodotto/servizio, nuovo provider, incidente rilevante, modifica normativa). Gli esiti alimentano il Riesame della Direzione. La procedura è versionata secondo la Procedura di Controllo dei Documenti.</p>
+56
View File
@@ -0,0 +1,56 @@
<!--META|doc_type=procedura_incident|title=Procedura di Gestione degli Incidenti e Notifica NIS2|status=approved|version=2.0-->
<h2>1. Scopo</h2>
<p>Definire le modalità con cui <strong>Nuova Agile Technology srl</strong> (l'"Azienda") rileva, classifica, gestisce e — quando dovuto — notifica gli incidenti di sicurezza delle informazioni, assicurando risposta tempestiva, riduzione degli impatti e rispetto degli obblighi di notifica NIS2. Disciplina anche la <strong>comunicazione ai clienti impattati</strong> nel ruolo dell'Azienda quale fornitore di soggetti NIS2.</p>
<h2>2. Ambito</h2>
<p>Si applica a tutti gli incidenti che riguardano riservatezza, integrità o disponibilità di informazioni e servizi: ambienti <strong>cloud</strong> (Aruba IT, Hetzner DE), <strong>SaaS</strong> multi-tenant, <strong>endpoint</strong> (PC portatili cifrati), <strong>piattaforme AI</strong> via API e i prodotti in licenza on-premise per la parte di responsabilità dell'Azienda. Non riguarda sale server in sede, <strong>assenti</strong> per l'architettura cloud-only.</p>
<h2>3. Riferimenti</h2>
<ul>
<li><strong>ISO/IEC 27001:2022</strong> – A.5.24, A.5.25, A.5.26, A.5.27, A.5.28 (gestione degli incidenti) e A.5.7 (threat intelligence).</li>
<li><strong>ISO/IEC 27017:2015</strong> e <strong>27018:2019</strong> – gestione degli incidenti nei servizi cloud e sui dati personali.</li>
<li><strong>D.Lgs. 4 settembre 2024, n. 138</strong> (recepimento Direttiva (UE) 2022/2555 – NIS2): <strong>art. 23 (governance)</strong>, <strong>art. 24 (misure di gestione del rischio)</strong>, <strong>art. 25 (obblighi di notifica degli incidenti)</strong>.</li>
<li><strong>Determinazione ACN n. 164179/2025</strong> e Determinazioni vigenti per criteri di significatività, tassonomia e modalità di notifica al CSIRT Italia tramite la piattaforma ACN.</li>
</ul>
<h2>4. Ruoli e responsabilità</h2>
<table>
<tr><th>Ruolo</th><th>Persona</th><th>Responsabilità</th></tr>
<tr><td>Direzione / Presidente</td><td><strong>Silvia Garretto</strong></td><td>Decide la notifica alle Autorità e la comunicazione esterna; informa gli organi di gestione (art. 23).</td></tr>
<tr><td>Responsabile SGSI</td><td><strong>Massimo Tagliavini</strong></td><td>Coordina la gestione dell'incidente, cura le registrazioni e la relazione finale.</td></tr>
<tr><td>Responsabile IT/Sicurezza</td><td><strong>Simon Fattori</strong></td><td>Contiene, eradica e ripristina; raccoglie le evidenze tecniche.</td></tr>
<tr><td>DPO esterno</td><td><em>Consulente esterno</em></td><td>Valuta se vi è violazione di dati personali e gli obblighi GDPR verso il Garante.</td></tr>
</table>
<h2>5. Flusso passo-passo</h2>
<ol>
<li><strong>Rilevazione e segnalazione.</strong> Chiunque rilevi un evento sospetto lo segnala immediatamente a Simon Fattori. L'evento è registrato nel <strong>modulo "Incidenti"</strong> con data e ora di conoscenza.</li>
<li><strong>Triage e classificazione.</strong> Simon Fattori, con Massimo Tagliavini, valuta natura, origine e impatto (riservatezza/integrità/disponibilità) e assegna una severità. Si verifica se l'incidente è <strong>"significativo"</strong> secondo i criteri di legge e delle Determinazioni ACN (impatto operativo grave, numero di utenti coinvolti, durata, danno economico/reputazionale, effetti transfrontalieri). In caso di dubbio: <strong>[DA VERIFICARE]</strong> con la Direzione e il supporto consulenziale.</li>
<li><strong>Contenimento, eradicazione, ripristino.</strong> Simon Fattori isola sistemi/account compromessi, rimuove la causa e ripristina il servizio anche tramite backup, tracciando i tempi delle fasi.</li>
<li><strong>Notifica al CSIRT Italia (ACN)</strong> — se l'incidente è significativo, secondo le tempistiche dell'<strong>art. 25 del D.Lgs. 138/2024</strong>:
<ul>
<li><strong>Pre-allarme (early warning) entro 24 ore</strong> dalla conoscenza dell'incidente significativo;</li>
<li><strong>Notifica completa entro 72 ore</strong> dalla conoscenza;</li>
<li><strong>Relazione finale entro 1 mese</strong> dalla notifica completa (e relazioni intermedie se richieste).</li>
</ul>
La notifica avviene tramite la piattaforma ACN; decide e autorizza la Direzione.</li>
<li><strong>Valutazione dati personali.</strong> In caso di violazione di dati personali, il DPO valuta gli obblighi GDPR (eventuale notifica al Garante entro 72 ore e comunicazione agli interessati).</li>
<li><strong>Comunicazione ai clienti impattati.</strong> Quale <strong>fornitore di clienti NIS2</strong>, l'Azienda informa <strong>tempestivamente</strong> i clienti i cui servizi/dati sono coinvolti, secondo gli <strong>obblighi contrattuali di supply chain</strong>, fornendo gli elementi utili ai loro adempimenti di notifica.</li>
<li><strong>Chiusura e lezioni apprese.</strong> A risoluzione si redige la relazione finale, si aprono eventuali <strong>non conformità</strong> e azioni correttive e si aggiorna il <strong>modulo "Rischi"</strong> se emergono nuovi rischi.</li>
</ol>
<h2>6. Controlli ISO e riferimenti NIS2 (tempistiche)</h2>
<p>La procedura attua i controlli <strong>A.5.24–A.5.28</strong> e <strong>A.5.7</strong> di ISO/IEC 27001:2022, integrati dai controlli cloud di ISO/IEC 27017/27018, e dà attuazione agli <strong>artt. 23, 24 e 25 del D.Lgs. 138/2024</strong>. Le <strong>tempistiche esatte di notifica</strong> al CSIRT Italia sono: <strong>pre-allarme (early warning) 24 ore</strong>, <strong>notifica completa 72 ore</strong>, <strong>relazione finale 1 mese</strong>. I criteri di significatività seguono la <strong>Determinazione ACN n. 164179/2025</strong> e le Determinazioni vigenti.</p>
<h2>7. Registrazioni ed evidenze</h2>
<ul>
<li>Scheda incidente nel modulo "Incidenti" (cronologia, severità, classificazione);</li>
<li>Evidenze tecniche raccolte (log, immagini, comunicazioni), preservate ai sensi di A.5.28;</li>
<li>Ricevute di notifica al CSIRT/ACN e relazione finale;</li>
<li>Comunicazioni ai clienti e, se del caso, al DPO/Garante;</li>
<li>Non conformità e azioni correttive collegate.</li>
</ul>
<h2>8. Riesame e versionamento</h2>
<p>Procedura approvata dalla Presidente. Revisione almeno annuale, dopo ogni incidente significativo o a fronte di aggiornamenti delle Determinazioni ACN. Versionata secondo la Procedura di Controllo dei Documenti.</p>