> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blevinsholdings.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SOP de Gestión de Cambios
> Proceso para solicitar, evaluar, aprobar e implementar cambios en sistemas e infraestructura en Blevins Holdings.
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:**
| Rol | Responsabilidad |
| ------------------------------ | -------------------------------------------------------------------------------------- |
| Solicitante del cambio | Envía la Solicitud de Cambio; es responsable del cambio |
| Seguridad de TI | Revisa 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 departamento | Aprueba cambios de bajo y mediano riesgo para su área |
| Operaciones | Mantiene 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](#emergency-changes))
* 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ía | Descripción | Aprobación requerida |
| -------------- | ------------------------------------------------------------------------------- | --------------------------------------------------- |
| **Estándar** | Cambios pre-aprobados, rutinarios con pasos bien entendidos y bajo riesgo | Director de departamento (plantillas pre-aprobadas) |
| **Bajo** | Cambios menores con alcance limitado, reversibles, impacto mínimo si fallan | Director de departamento |
| **Medio** | Alcance e impacto moderados; el riesgo es manejable pero amerita revisión de TI | Líder de TI + Director de departamento |
| **Alto** | Impacto amplio, difícil de revertir o alto riesgo si algo sale mal | Comité Asesor de Cambios (CAB) |
| **Emergencia** | Cambio no planificado requerido inmediatamente para restaurar el servicio | Revisión post-implementación requerida |
***
## Pasos del proceso
**Quién:** Solicitante del cambio
Todos 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.
**Quién:** TI / Operaciones
TI 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.
**Quién:** Aprobadores según la categoría de riesgo
Los 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.
**Quién:** Solicitante del cambio + Operaciones
Una 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.
**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.
**Quién:** Solicitante del cambio + TI
Dentro 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*