Modelos y registros · ISO 20000 · Apartado 8.5.1
Modelo de solicitud de cambio (RFC) según ISO 20000-1
Cada modificación de un servicio o de un elemento bajo control: qué se cambia, por qué, qué riesgo tiene, quién lo aprueba, cómo se vuelve atrás si sale mal y si funcionó.
En una frase
Una solicitud de cambio registra la descripción y el motivo del cambio, su clasificación, la evaluación de riesgos, beneficios, viabilidad e impacto económico, la aprobación de quien tiene autoridad, la fecha planificada comunicada, el plan de vuelta atrás, el resultado de las pruebas y la revisión de su eficacia, porque el apartado 8.5.1 de ISO/IEC 20000-1 exige registrar y clasificar cada solicitud y tomar las decisiones con las partes implicadas según la política de gestión del cambio.
- Dónde lo pide la norma
- ISO 20000 · Apartado 8.5.1 Los apartados se citan con la numeración de ISO/IEC 20000-1:2018, la edición vigente y la misma que usa la Academia.
- Tipo de información
- Registro obligatorio Registro y clasificación de las solicitudes de cambio (8.5.1.2), con la política documentada (8.5.1.1)
- Quién lo rellena
- Gestor del cambio Aprueba quien fije la política; los cambios importantes pasan por un comité con las partes implicadas
- Cuándo
- Antes de cualquier cambio controlado Los de emergencia pueden aprobarse por vía rápida, pero se registran igual
- Cuánto se conserva
- Lo fija la organización La norma pide controlar la conservación y la eliminación de la información documentada (7.5.3) sin fijar plazos. Lo habitual es cubrir al menos el ciclo de certificación de tres años, o el plazo del contrato con el cliente si es mayor.
Qué pide la norma
Lo que exige ISO 20000 y lo que deja a tu criterio
La norma pide una política de gestión del cambio que defina qué elementos de configuración están bajo su control, los criterios para identificar los cambios con impacto potencial grave —que se gestionan con el diseño y la transición de servicios de 8.5.2— y cómo se tratan los cambios de emergencia.
Cada solicitud se registra y se clasifica. La decisión se toma con las partes implicadas, valorando riesgos, beneficios, viabilidad e impacto económico. Las fechas planificadas se comunican, se preparan y, si es posible, se prueban las actividades de vuelta atrás, y si el cambio falla se aplican.
Tras su implantación se revisa la eficacia del cambio, y los registros de solicitudes se analizan periódicamente para detectar tendencias.
Estructura
Campos que debe tener el modelo
- Número, fecha y solicitante
- Descripción y motivo
- Servicios y elementos de configuración afectados
- Clasificación: estándar, normal, emergencia o de impacto grave
- Evaluación de riesgos, beneficios, viabilidad e impacto económico
- Aprobación y quién decide
- Ventana planificada y comunicación
- Plan de vuelta atrás y si se ha probado
- Resultado de las pruebas e implantación
- Revisión de la eficacia y cierre
Ejemplo
Ejemplo: inventario de certificados con aviso
Empresa, personas y cifras inventadas: el ejemplo solo enseña cómo queda un registro bien cumplimentado.
| Campo | Contenido |
|---|---|
| Cambio | CHG-26-077 · 22 de abril de 2026 · origen: problema PRB-26-021 |
| Descripción | Alta de los 46 certificados de servidor como elementos de configuración y aviso automático a 30 días |
| Afecta a | Base de datos de configuración y herramienta de monitorización |
| Clasificación | Normal · riesgo bajo |
| Evaluación | Sin interrupción del servicio · coste interno de 3 jornadas · evita caídas como la de abril |
| Aprobación | Comité de cambios del 24 de abril |
| Ventana | 28 de abril, 19-21 h · comunicada al cliente el 24 |
| Vuelta atrás | Desactivar la regla de aviso · probada en preproducción |
| Eficacia | Primer aviso recibido el 12 de junio, 30 días antes de la caducidad · eficaz |
En la auditoría
Errores que suelen señalar los auditores
- Cambios aplicados en producción sin solicitud registrada.
- Cambios de emergencia que nunca se registran después.
- Planes de vuelta atrás que no existen o no se han probado.
- Sin revisión posterior de si el cambio funcionó.
- La política no define qué elementos están bajo control del cambio.
En Kimobox
Cómo se lleva este registro en Kimobox
- 1Las solicitudes de cambio se gestionan como flujo de aprobación.
- 2Cada cambio queda con su aprobación, sus pruebas y su resultado documentados en el mismo flujo.
- 3Los elementos de configuración se registran como activos versionados.
Preguntas frecuentes
Lo que nos preguntan antes de empezar
¿Qué es un cambio estándar?
Un cambio de bajo riesgo, frecuente y con procedimiento conocido, que se preaprueba y no pasa por el comité cada vez. ISO/IEC 20000-1 no usa ese término, pero permite definir en la política qué cambios se tratan así.
¿Qué se hace con un cambio de emergencia?
La política de gestión del cambio debe definir cómo se gestionan. Lo habitual es una aprobación rápida por una persona autorizada y el registro completo después, con su revisión.
Lleva los registros de ISO 20000 sin plantillas sueltas
Te enseñamos el módulo funcionando con datos parecidos a los tuyos.
Sigue explorando
Páginas relacionadas
Diseño y transición de servicios
Todo cambio en un servicio TI debe planificarse y probarse antes de pasar a producción para minimizar el…
Modelo de catálogo de servicios TI según ISO 20000-1
Qué debe incluir el catálogo de servicios que pide ISO/IEC 20000-1: descripción, resultados previstos…
Modelo de acuerdo de nivel de servicio (SLA) ISO 20000-1
Qué debe recoger un SLA según ISO/IEC 20000-1 (8.3.3): servicios, objetivos de nivel, límites de carga…
Modelo de informe de nivel de servicio ISO 20000-1
Qué debe contener el informe de servicio que pide ISO/IEC 20000-1: cumplimiento de SLA, carga, incidencias…
Fuentes
De dónde sale cada dato
Referencias al texto oficial vigente. Si una norma se revisa, esta página se actualiza y la fecha de revisión lo refleja.
- ISO/IEC 20000-1:2018 — Gestión del servicio. Requisitos del sistema de gestión del servicio ISO/IEC · Septiembre de 2018