Flujo de gestión de cambios de TI (SOC 2 CC8.1)
Flujo de gestión de cambios de TI listo para SOC 2: solicitud de cambio, evaluación de impacto, aprobación, pruebas, despliegue y revisión posterior a la implantación, con firma en cada puerta.
Cómo funciona
Empieza por la clasificación
Define cambio estándar, normal y urgente con ejemplos concretos de vuestros propios sistemas. Una clasificación que nadie puede aplicar sin preguntar acaba convirtiendo todo en "normal".
Preaprueba los cambios estándar
Haz una lista de los cambios repetitivos y de bajo riesgo y deja que se ejecuten sin aprobación individual. Es la única forma de que la vía formal se use para lo que está pensada.
Separa la aprobación del despliegue
Los dos pasos deben vivir en carriles distintos, con responsables distintos. Es lo primero que prueba un walkthrough de SOC 2 y es muy difícil de documentar a posteriori.
Dibuja la vía urgente con su plazo
Un cambio urgente puede desplegarse antes de la aprobación, pero la aprobación y la revisión posteriores necesitan un plazo escrito en el nodo. Sin plazo, la vía urgente es simplemente un atajo.
Termina en la revisión posterior a la implantación
Añade el paso en el que se repasan los cambios fallidos y revertidos. Ahí es donde se ven los patrones de los despliegues que salen mal, y es el paso que más veces falta.
Preguntas frecuentes
¿Qué exige SOC 2 CC8.1 en gestión de cambios?
CC8.1 (cambios que afectan al sistema) exige procedimientos documentados para evaluar, aprobar, probar y desplegar cambios, además de evidencia de que el procedimiento se siguió en los cambios seleccionados como muestra durante el periodo auditado.
¿En qué se diferencia QueryChart de un sistema de tickets como Jira para la gestión de cambios?
Los sistemas de tickets siguen los cambios uno a uno; no documentan la versión vigente y controlada del propio proceso de gestión de cambios. QueryChart documenta el proceso (el documento controlado) para que el auditor vea el diseño antes de muestrear la operación en Jira o ServiceNow.
¿Cuál es la diferencia entre cambio estándar, normal y urgente?
Un cambio estándar es repetitivo, de bajo riesgo y está preaprobado, por ejemplo la renovación rutinaria de un certificado. Un cambio normal pasa por evaluación de impacto y aprobación antes de poder desplegarse. Un cambio urgente resuelve una incidencia crítica y puede desplegarse primero, a cambio de que la aprobación y la revisión se hagan después dentro de un plazo fijado. Las tres vías deben verse en el diagrama; si no, no describe el proceso que realmente se ejecuta.
¿Todos los cambios tienen que pasar por un comité de cambios (CAB)?
No, y un comité que lo revisa todo se convierte en un cuello de botella que la organización empieza a esquivar. Deja para el comité los cambios transversales, los que afectan al cliente o los que requieren indisponibilidad, y que el resto los apruebe un responsable de cambios con nombre. Lo decisivo para el auditor es que el criterio de qué va al comité esté en el proceso controlado, no que el comité lo haya visto todo.