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.
¿Qué es flujo de gestión de cambios de ti (soc 2 cc8.1)?
La gestión de cambios casi siempre se documenta como el camino largo: solicitud, evaluación, comité de cambios, aprobación, pruebas y despliegue. Y después la mayoría de los cambios reales circula por otra vía, porque el camino largo tarda cuatro días. El problema no es el proceso, es que solo tiene un camino.
Un diagrama que aguanta un walkthrough tiene por tanto tres vías: los cambios estándar, preaprobados, que se ejecutan sin aprobación adicional; los cambios normales, que pasan por evaluación y aprobación; y los cambios urgentes, que pueden desplegarse primero y aprobarse después, dentro de un plazo y con una justificación documentada. La clasificación es la primera decisión del recorrido, no una nota en el procedimiento.
Lo segundo que prueba el auditor es la segregación de funciones: ¿puede quien ha desarrollado el cambio liberarlo por su cuenta a producción? Esa pregunta solo la responde un diagrama en el que la aprobación y el despliegue vivan en carriles distintos, con responsables distintos.
Qué cubre este diagrama de flujo
En esta plantilla
- La solicitud de cambio: quién puede solicitar, qué hay que describir (objetivo, sistemas afectados y plan de reversión) y cómo se registra la solicitud
- Clasificación en cambio estándar, cambio normal y cambio urgente: la bifurcación que decide qué vía de aprobación sigue el cambio
- Evaluación de impacto y de riesgo: sistemas y datos afectados, indisponibilidad prevista, dependencias e impacto en seguridad
- Aprobación por el responsable de cambios o por el comité de cambios (CAB), con una rama para los cambios rechazados y aplazados
- Pruebas y validación en el entorno de pruebas, incluida la exigencia de un plan de reversión documentado antes de liberar el cambio
- Despliegue con segregación de funciones entre quien desarrolla y quien libera, verificación posterior, reversión en caso de fallo y revisión final de los cambios urgentes
Cuándo usar esta plantilla
- Vais a pasar una auditoría SOC 2 y el walkthrough de CC8.1 plantea la pregunta: ¿cómo llega un cambio a producción?
- Los cambios urgentes se usan como vía normal porque el proceso formal es demasiado lento, y queréis ver por qué
- Los desarrolladores liberan sus propios cambios y hay que documentar o implantar la segregación de funciones
- Usáis Jira o ServiceNow para los tickets individuales, pero no tenéis una descripción controlada del proceso en sí
- Hay que cubrir SOC 2 CC8.1 e ISO 27001 A.8.32 y queréis un único proceso en lugar de dos descripciones que dicen cosas distintas
Controles documentados
- CC8.1
- ISO 27001 A.8.32
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.