Cambios y operaciones de TI

Un cambio a un sistema en producción pasa por una cadena: solicitud (qué y por qué), aprobación del dueño del sistema, prueba de aceptación en un entorno separado, pase a producción hecho por alguien que no lo desarrolló, y a veces una revisión posterior para confirmar que hizo lo esperado. Cada eslabón responde a un riesgo: sin aprobación, cambia cualquiera; sin prueba, se rompe producción; sin separación entre quien desarrolla y quien pasa, un programador puede cambiar un cálculo a su favor sin que nadie lo vea. El control 8.32 del Anexo A de ISO/IEC 27001:2022 trata la gestión de cambios.

Se prueba sobre la población de cambios del periodo, que se obtiene del registro de la herramienta de cambios y se concilia con lo que realmente pasó (los pases en producción deben cuadrar con los tickets). Si la población es pequeña, como aquí, se prueban todos.

El criterio es siempre el procedimiento de la propia organización: no auditas contra tu manera ideal de hacer los cambios, sino contra lo que ella escribió.

El procedimiento de Alba Verde exige, para un cambio normal, la aprobación del dueño del sistema y una prueba de aceptación antes del pase. Con la población de seis cambios del semestre delante, la prueba de aprobación es una lectura de columnas: quién aprobó cada uno y si consta.

Una columna sin aprobador en un cambio normal es un incumplimiento. Un cambio de emergencia es otra cosa: el mismo procedimiento permite pasarlo sin aprobación previa si el dueño lo aprueba después, dentro de un plazo. Antes de levantar un hallazgo, mira de qué tipo es cada cambio.

La separación entre desarrollo y producción se prueba comparando dos columnas que ya tienes en el registro: quién desarrolló el cambio y quién lo pasó a producción. No necesitas más evidencia que la del propio registro de la herramienta, siempre que lo hayas extraído tú y no te lo hayan entregado ya filtrado.

Cuando coinciden, el hallazgo es de diseño y de operación a la vez: el sistema, o el proceso, deja que una sola persona haga el cambio de punta a punta. Importa también qué cambió: un parámetro de comisiones, de intereses o de precios toca directamente el dinero.

El cambio CHG-2047 corrigió el cierre diario un lunes de abril sin aprobación previa y sin prueba de aceptación. Si lo lees contra la regla de los cambios normales, falla en todo. Pero no es un cambio normal: el procedimiento de Alba Verde admite los pases de emergencia sin aprobación previa si el dueño aprueba en un máximo de tres días hábiles.

Ese es el criterio contra el que se compara. La columna de la aprobación posterior dice cuándo aprobó el dueño. Si cumple, no es un incumplimiento; a lo sumo una observación de mejora sobre la ausencia de prueba, si el procedimiento no la exige para emergencias. Levantar un hallazgo de aprobación sobre un cambio que cumple su propia regla destruye la credibilidad del resto.

En operaciones, el control típico es el respaldo: se copia la información y se puede recuperar. Se prueba con la bitácora de respaldos (cada ejecución, su resultado y qué se hizo si falló) y con una prueba de restauración, porque un respaldo «ok» solo demuestra que el trabajo terminó, no que la copia se pueda usar para recuperar nada.

Aquí se mira la bitácora. La política de Alba Verde pide reintentar el mismo día cuando un respaldo falla. En la semana de junio que tienes delante hay dos días con fallo; uno se reintentó y terminó bien, el otro no. El que no se reintentó es la excepción, porque esa noche no hubo copia recuperable de la cartera.