Modelli e registrazioni · ISO 20000 · Punto 8.5.1

Modello di richiesta di modifica (RFC) secondo la ISO 20000-1

Ogni modifica di un servizio o di un elemento sotto controllo: che cosa si cambia, perché, quale rischio comporta, chi la approva, come si torna indietro se va male e se ha funzionato.

In una frase

Una richiesta di modifica registra la descrizione e il motivo della modifica, la sua classificazione, la valutazione di rischi, benefici, fattibilità e impatto economico, l’approvazione di chi ne ha l’autorità, la data pianificata comunicata, il piano di rollback, l’esito delle prove e il riesame della sua efficacia, perché il punto 8.5.1 della ISO/IEC 20000-1 impone di registrare e classificare ogni richiesta e di prendere le decisioni con le parti coinvolte secondo la politica di gestione delle modifiche.

Contenuto revisionato il 17 ottobre 2026

Dove lo richiede la norma: ISO 20000 · Punto 8.5.1 I punti sono citati con la numerazione della ISO/IEC 20000-1:2018, l’edizione in vigore e la stessa usata dall’Academy.
Tipo di informazione: Registrazione obbligatoria Registrazione e classificazione delle richieste di modifica (8.5.1.2), con la politica documentata (8.5.1.1)
Chi lo compila: Gestore delle modifiche Approva chi stabilisce la politica; le modifiche importanti passano da un comitato con le parti coinvolte
Quando: Prima di qualsiasi modifica controllata Quelle di emergenza possono essere approvate con una procedura rapida, ma si registrano comunque
Per quanto tempo si conserva: Lo stabilisce l’organizzazione La norma chiede di controllare la conservazione e l’eliminazione delle informazioni documentate (7.5.3) senza fissare termini. La prassi è coprire almeno il ciclo di certificazione triennale, o la durata del contratto con il cliente se maggiore.

Che cosa richiede la norma

Che cosa impone la norma ISO 20000 e che cosa lascia alla sua discrezione

La norma chiede una politica di gestione delle modifiche che definisca quali elementi di configurazione sono sotto il suo controllo, i criteri per individuare le modifiche con potenziale impatto grave —che si gestiscono con la progettazione e la transizione dei servizi dell’8.5.2— e come si trattano le modifiche di emergenza.

Ogni richiesta si registra e si classifica. La decisione si prende con le parti coinvolte, valutando rischi, benefici, fattibilità e impatto economico. Le date pianificate si comunicano, le attività di rollback si preparano e, se possibile, si provano, e se la modifica fallisce si applicano.

Dopo l’attuazione si riesamina l’efficacia della modifica, e le registrazioni delle richieste si analizzano periodicamente per individuare le tendenze.

Lo legga nel contesto: Progettazione e transizione dei servizi, nell’Academy ISO 20000

Struttura

Campi che il modello deve contenere

Numero, data e richiedente
Descrizione e motivo
Servizi ed elementi di configurazione coinvolti
Classificazione: standard, normale, di emergenza o con impatto grave
Valutazione di rischi, benefici, fattibilità e impatto economico
Approvazione e chi decide
Finestra pianificata e comunicazione
Piano di rollback e se è stato provato
Esito delle prove e attuazione
Riesame dell’efficacia e chiusura

Esempio

Esempio: inventario dei certificati con avviso

Azienda, persone e cifre inventate: l’esempio mostra soltanto come si presenta una registrazione compilata correttamente.

Campo	Contenuto
Modifica	CHG-26-077 · 22 aprile 2026 · origine: problema PRB-26-021
Descrizione	Inserimento dei 46 certificati server come elementi di configurazione e avviso automatico a 30 giorni
Riguarda	Database della configurazione e strumento di monitoraggio
Classificazione	Normale · rischio basso
Valutazione	Nessuna interruzione del servizio · costo interno di 3 giornate · evita interruzioni come quella di aprile
Approvazione	Comitato modifiche del 24 aprile
Finestra	28 aprile, 19-21 · comunicata al cliente il 24
Rollback	Disattivare la regola di avviso · provato in preproduzione
Efficacia	Primo avviso ricevuto il 12 giugno, 30 giorni prima della scadenza · efficace

In audit

Errori che gli auditor rilevano più spesso

Modifiche applicate in produzione senza richiesta registrata.
Modifiche di emergenza che non vengono mai registrate a posteriori.
Piani di rollback che non esistono o non sono stati provati.
Nessun riesame successivo del funzionamento della modifica.
La politica non definisce quali elementi siano sotto il controllo delle modifiche.

In Kimobox

Come si gestisce questa registrazione in Kimobox

1Le richieste di modifica si gestiscono come flusso di approvazione.
2Ogni modifica resta con la sua approvazione, le prove e l’esito documentati nello stesso flusso.
3Gli elementi di configurazione si registrano come asset versionati.

Domande frequenti

Cosa ci chiedono prima di iniziare

Che cos’è una modifica standard?

Una modifica a basso rischio, frequente e con procedura nota, che si pre-approva e non passa ogni volta dal comitato. La ISO/IEC 20000-1 non usa questo termine, ma consente di definire nella politica quali modifiche si trattano così.

Che cosa si fa con una modifica di emergenza?

La politica di gestione delle modifiche deve definire come si gestiscono. La prassi è un’approvazione rapida da parte di una persona autorizzata e la registrazione completa successiva, con il relativo riesame.

Gestisca le registrazioni ISO 20000 senza modelli sparsi

Le mostriamo il modulo in funzione con dati simili ai suoi.

Richiedi una demo

Continua a esplorare