1. Scopo
La presente procedura definisce le modalità con cui Nuova Agile Technology srl (di seguito "l'Azienda") richiede, valuta, autorizza, attua e verifica i cambiamenti che possono influire sulla sicurezza, la disponibilità e l'integrità dei propri sistemi, servizi e configurazioni, in modo controllato e tracciabile, riducendo il rischio di indisponibilità o di introduzione di vulnerabilità.
2. Ambito
Si applica ai cambiamenti su: ambienti cloud (Aruba IT, Hetzner DE), configurazioni di rete e di sicurezza, servizi SaaS multi-tenant, rilasci di nuove versioni dei prodotti software (SaaS e on-premise presso i clienti), integrazioni con piattaforme AI via API, configurazioni degli endpoint (PC portatili cifrati) e modifiche alle policy/strumenti di sicurezza. Sono esclusi i cambiamenti puramente di contenuto privi di impatto su sicurezza o servizio.
3. Riferimenti
- ISO/IEC 27001:2022 – A.8.32 (Gestione dei cambiamenti), A.8.31 (Separazione degli ambienti di sviluppo, test ed esercizio), A.8.28 (Codifica sicura), A.8.25 (Ciclo di vita di sviluppo sicuro), A.8.29 (Test di sicurezza nello sviluppo e nell'accettazione).
- ISO/IEC 27017:2015 e 27018:2019 – gestione dei cambiamenti nei servizi cloud.
- D.Lgs. 4 settembre 2024, n. 138 (NIS2): art. 24 (misure di gestione del rischio, incluse sicurezza nello sviluppo e gestione delle modifiche).
- Procedura di Gestione delle Vulnerabilità e delle Patch dell'Azienda.
4. Ruoli e responsabilità
| Ruolo | Persona | Responsabilità |
|---|
| Direzione / Presidente | Silvia Garretto | Autorizza i cambiamenti ad alto impatto e le finestre di rilascio critiche |
| Responsabile SGSI | Massimo Tagliavini | Verifica che i cambiamenti rilevanti siano valutati nel rischio e documentati |
| Responsabile IT/Sicurezza | Simon Fattori | Valuta tecnicamente, attua il cambiamento, esegue i test e il piano di rollback |
| Richiedente | variabile | Apre la richiesta di cambiamento descrivendo finalità e impatto atteso |
5. Flusso/attività passo-passo
- Richiesta (RFC). Il richiedente apre una richiesta di cambiamento descrivendo obiettivo, sistemi coinvolti, impatto atteso e urgenza.
- Valutazione di impatto e rischio. 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 modulo "Rischi" ove pertinente.
- Autorizzazione. 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 piano di rollback.
- Test in ambiente separato. 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.
- Attuazione. 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.
- Verifica post-cambiamento. Si verifica il corretto funzionamento e l'assenza di effetti collaterali; in caso di esito negativo si attiva il rollback.
- Chiusura. Esito e documentazione sono registrati; eventuali anomalie alimentano non conformità e azioni correttive.
5.1 Cambiamenti di emergenza
Per cambiamenti urgenti (es. mitigazione di una vulnerabilità critica), l'attuazione può precedere l'autorizzazione formale, ma deve essere documentata a posteriori entro il giorno lavorativo successivo e ratificata dalla Direzione.
6. Controlli ISO + riferimenti NIS2
La procedura attua i controlli A.8.32, A.8.31, A.8.25, A.8.28, A.8.29 di ISO/IEC 27001:2022 e i controlli cloud di ISO/IEC 27017/27018. Soddisfa le misure di gestione del rischio dell'art. 24 del D.Lgs. 138/2024 in tema di sicurezza dello sviluppo e gestione delle modifiche, contribuendo a prevenire incidenti che ricadrebbero negli obblighi di notifica (art. 25).
7. Registrazioni/evidenze
- Richieste di cambiamento (RFC) e relative autorizzazioni;
- Esiti dei test e dei rilasci; note di rilascio per i clienti on-premise;
- Documentazione dei cambiamenti di emergenza e relativa ratifica;
- Non conformità collegate a cambiamenti falliti.
8. Riesame e versionamento
Procedura approvata dalla Presidente. Revisione almeno annuale o a fronte di modifiche del processo di rilascio. Versione 1.0.