Saltar al contenido principal
Responsable del SOP: TI / Operaciones — Última revisión: [Fecha] — ID: SOP-IT-002

Descripción general

El proceso de Gestión de Cambios asegura que los cambios en sistemas, procesos e infraestructura se introduzcan de manera controlada y coordinada para minimizar la interrupción y el riesgo. Todos los cambios significativos requieren revisión y aprobación formal antes de la implementación. Por qué esto importa: Los cambios no controlados son una de las causas más comunes de interrupciones del sistema e incidentes de seguridad. Un proceso estructurado de gestión de cambios reduce el riesgo, mejora la previsibilidad y crea un registro de auditoría. Partes interesadas clave:
RolResponsabilidad
Solicitante del cambioEnvía la Solicitud de Cambio; es responsable del cambio
Seguridad de TIRevisa las implicaciones de seguridad; requerido para todos los cambios de alto riesgo
Comité Asesor de Cambios (CAB)Revisa y aprueba cambios de alto riesgo
Director de departamentoAprueba cambios de bajo y mediano riesgo para su área
OperacionesMantiene el registro de cambios; coordina la programación

Qué requiere una Solicitud de Cambio

Una Solicitud de Cambio (CR) formal es requerida para cualquier cambio que pueda afectar la disponibilidad, seguridad o integridad de los sistemas de producción o los procesos de negocio principales. Ejemplos incluyen:
  • Desplegar nuevo software o infraestructura en producción
  • Modificar controles de acceso o sistemas de autenticación
  • Cambios en la configuración de red, reglas de firewall o configuración de VPN
  • Migrar datos entre sistemas
  • Actualizar integraciones o APIs que afectan flujos de trabajo críticos para el negocio
  • Retirar o reemplazar un sistema usado por empleados o clientes
Qué no requiere una CR:
  • Mantenimiento rutinario dentro de una ventana de mantenimiento pre-aprobada
  • Cambios de emergencia para restaurar el servicio (estos se documentan retroactivamente — ver Cambios de emergencia)
  • Cambios menores de contenido o configuración sin impacto a nivel de sistema (ej., actualizar un documento)
En caso de duda, presente una CR. El proceso de revisión es ligero para cambios de bajo riesgo.

Categorías de cambios

Los cambios se categorizan por nivel de riesgo:
CategoríaDescripciónAprobación requerida
EstándarCambios pre-aprobados, rutinarios con pasos bien entendidos y bajo riesgoDirector de departamento (plantillas pre-aprobadas)
BajoCambios menores con alcance limitado, reversibles, impacto mínimo si fallanDirector de departamento
MedioAlcance e impacto moderados; el riesgo es manejable pero amerita revisión de TILíder de TI + Director de departamento
AltoImpacto amplio, difícil de revertir o alto riesgo si algo sale malComité Asesor de Cambios (CAB)
EmergenciaCambio no planificado requerido inmediatamente para restaurar el servicioRevisión post-implementación requerida

Pasos del proceso

1

Enviar una Solicitud de Cambio

Quién: Solicitante del cambioTodos los cambios comienzan con una Solicitud de Cambio (CR) formal enviada a través de [sistema de gestión de cambios — enlace por agregar]. La CR debe incluir:
  • Descripción del cambio — Qué está cambiando y por qué
  • Justificación del negocio — El propósito y el resultado esperado
  • Alcance — Sistemas, servicios o datos afectados
  • Fecha y hora de implementación propuestas — Incluyendo zona horaria
  • Plan de reversión — Pasos específicos para revertir el cambio si falla
  • Enfoque de pruebas — Cómo se validará el cambio antes y después
  • Aprobadores designados — Según la categoría de riesgo
Los cambios no deben implementarse antes de recibir las aprobaciones requeridas. Los cambios no autorizados son una violación de la política y pueden resultar en acción disciplinaria.
2

Categorización de riesgo

Quién: TI / OperacionesTI u Operaciones revisa la CR y asigna una categoría de riesgo (Estándar, Bajo, Medio, Alto). Se notifica al solicitante la categoría asignada y cualquier información adicional necesaria antes de que la revisión pueda proceder.Si el solicitante no está de acuerdo con la categorización de riesgo, puede escalar al Líder de TI o al Director de Operaciones para una determinación final.
3

Revisión y aprobación

Quién: Aprobadores según la categoría de riesgoLos aprobadores revisan la CR y pueden:
  • Aprobar — El cambio procede según el cronograma propuesto
  • Aprobar con condiciones — El cambio puede proceder sujeto a requisitos específicos (ej., pruebas adicionales, ventana restringida)
  • Diferir — El cambio debe reprogramarse (ej., conflicto con un período crítico para el negocio)
  • Rechazar — El cambio no puede proceder como fue enviado; el solicitante debe revisar y reenviar
Los cambios de alto riesgo revisados por el CAB se evalúan en una reunión programada del CAB. El CAB se reúne [semanal / bajo demanda — por definir]. La composición del CAB incluye Seguridad de TI, Operaciones y directores de departamento relevantes.
4

Programar y comunicar

Quién: Solicitante del cambio + OperacionesUna vez aprobado, Operaciones programa el cambio y comunica a las partes interesadas afectadas:
  • Ventana de mantenimiento — Cuándo ocurrirá el cambio
  • Impacto esperado — Cualquier tiempo de inactividad o servicio degradado
  • Punto de contacto — A quién notificar si algo sale mal
  • Disparador de reversión — Bajo qué condiciones se revertirá el cambio
Los cambios de alto impacto requieren notificación con al menos 48 horas de anticipación. Los cambios rutinarios de bajo riesgo pueden comunicarse el mismo día.
5

Implementar

Quién: Solicitante del cambio (con soporte de TI según sea necesario)El cambio se implementa según la CR aprobada. Durante la implementación:
  • Siga los pasos documentados exactamente
  • Monitoree comportamientos inesperados en tiempo real
  • Mantenga el plan de reversión listo para ejecutar
  • Registre cualquier desviación del plan en la CR
Si ocurre algo inesperado, escale inmediatamente a TI y considere ejecutar el plan de reversión.
6

Revisión post-implementación

Quién: Solicitante del cambio + TIDentro de los 5 días hábiles posteriores a la implementación, el solicitante documenta el resultado en la CR:
  • ¿El cambio logró su resultado previsto?
  • ¿Hubo efectos secundarios inesperados?
  • ¿Fue necesario ejecutar el plan de reversión? Si es así, ¿por qué?
  • ¿Qué se haría diferente la próxima vez?
Operaciones marca la CR como Cerrada (exitosa), Cerrada (revertida) o Escalada si quedan problemas sin resolver.

Cambios de emergencia

Un cambio de emergencia es un cambio no planificado requerido inmediatamente para restaurar un servicio degradado o caído. Los cambios de emergencia omiten las puertas de aprobación normales pero deben documentarse retroactivamente. Procedimiento para cambios de emergencia:
  1. Notifique al Líder de TI y al contacto de guardia antes de realizar cualquier cambio
  2. Documente qué se está cambiando y por qué (verbalmente o por escrito)
  3. Implemente el cambio mínimo requerido para restaurar el servicio
  4. Envíe una CR retroactiva dentro de las 24 horas del cambio
  5. Programe una revisión post-incidente dentro de 5 días hábiles
Los cambios de emergencia se revisan en la próxima reunión del CAB para determinar si se necesita una acción de seguimiento.

Comité Asesor de Cambios (CAB)

El CAB revisa los cambios de alto riesgo y proporciona un foro estructurado para evaluar el riesgo, coordinar la programación y compartir aprendizajes. Los miembros del CAB incluyen:
  • Director de TI / CTO (presidente)
  • Líder de Seguridad de TI
  • Director de Operaciones
  • Representantes de las unidades de negocio afectadas (según sea necesario)
Las decisiones del CAB se documentan en el registro de cambios. El calendario y las actas de las reuniones del CAB son mantenidos por Operaciones en [enlace — por agregar].
Responsable del SOP: TI / Operaciones