GUÍA DE AUDITORÍA DE TECNOLOGÍA GLOBAL

Controles de gestión
de parches y cambios:
cruciales para el éxito
de la organización
 Instituto de Auditores Internos
Guía de Auditoría de Tecnología Global
Controles de gestión de parches y cambios: cruciales para el éxito de
la organización

Autores:

Jay R. Taylor, General Motors Corp.

Julia H. Allen, Universidad Carnegie Mellon, Instituto de Ingeniería de Software
Glenn L. Hyatt, General Motors Acceptance Corp.
Gene H. Kim, Tripwire Inc.

Copyright © 2005 del Instituto de Auditores Internos, 247 Maitland Avenue, Altamonte Springs, Florida 32701-4201.
Todods los derechos reservados. Impreso en Estados Unidos. Ninguna parte de esta publicación puede ser reproducida,
guardada en un sistema de recuperación o transmitida en forma alguna ni por ningún medio, sea electrónico, mecánico,
fotocopia, grabación, o cualquier otor, sin obtener previamente el permiso por escrito del editor.

El IIA publica este documento con fines de informativos y educativos. Este documento tiene como propósito bindar
información, pero no sustituye el asesoramiento legal o contable. El IIA no ofrece ese tipo de asesoramiento y no
garantiza ningún resultado legal ni contable por medio de la publicación de este documento. Cuando surgen cuestiones
legales o contables, se debe recurrir y obtener asistencia profesional.

i
 GTAG — Índice

Parte 1
Resumen ejecutivo .............................................................................................................................................................. 1

Parte 2
Introducción.......................................................................................................................................................................... 4

Parte 3
¿Por qué debo interesarme en cómo la organización gestiona el cambio?.......................................................................... 9

Parte 4
Definir la gestión de cambio de TI.................................................................................................................................... 13

Parte 5
¿Qué preguntas debo hacer sobre la gestión de parches y cambios? ................................................................................ 21

Parte 6
Tres meses más tarde: finaliza la historia de Silvia............................................................................................................ 25

Parte 9
¿Por dónde deben comenzar los auditores internos? ........................................................................................................ 28

Parte 8
¿Dónde puedo obtener más información?.......................................................................................................................... 31

Parte 9
Apéndice A: Programa de auditoría de gestión del cambio de TI.................................................................................... 32

Parte 10
Apéndice B: Metodología de Operaciones Visibles .......................................................................................................... 39

Parte 11
Apéndice C: Ejemplo Práctico de Negocio para la Gestión del Cambio ........................................................................ 39

Parte 12
Apéndice D: Herramientas de la Gestión del Cambio y Proveedores.............................................................................. 42

Parte 13
Referencias ........................................................................................................................................................................ 43

Parte 14
Acerca de los autores ........................................................................................................................................................ 44

ii
GTAG — Lista de figuras y cuadros

Lista de figuras
Figura 1: Modelo COSO ERM para la gestión del cambio .............................................................................................. 12
Figura 2: Trabajo no planificado como indicador de procesos eficaces de gestión del cambio ........................................ 18
Figura 3: Variables clave que influyen sobre los procesos de gestión del cambio ............................................................ 18
Figura 4: Niveles de capacidad de gestión del cambio ...................................................................................................... 23

Lista de cuadros
Cuadro 1: Mediciones de la gestión del cambio .............................................................................................................. 16
Cuadro 2: Preguntas a realizar sobre la gestión del cambio agrupadas por arquetipo ...................................................... 21
Cuadro 3: Programa de auditoría de gestión del cambio de TI ........................................................................................ 33
Cuadro 4: Roles típicos...................................................................................................................................................... 38
Cuadro 5: Separación de funciones .................................................................................................................................. 38
Cuadro 6: Problemas e indicadores de gestión ineficaz del cambio.................................................................................. 40
Cuadro 7: Beneficios de una transformación eficaz .......................................................................................................... 40

iii

1.1 ¿Por qué el Director Ejecutivo de
Auditoría debe involucrarse en el control
de la gestión de parches y cambios?
Probablemente, usted se esté preguntando porqué debe leer
una guía sobre la gestión de parches y cambios de la tecnolo-
gía informática (TI). Al fin y al cabo, ¿no es este un asunto
que puede delegar por completo en su personal técnico de
auditoría de TI? Además, ¿no hay guías lo suficientemente
minuciosas sobre este asunto que retoma la gestión del entor-
no de computadora central? La respuesta breve a estas dos pre-
guntas es “no”.
Si bien el rol principal de los directores ejecutivos de
auditoría no incluye el requisito de ser experto en tecnología,
existen riesgos significativos asociados a los usos de la tecno-
logía en prácticamente todas las actividades empresariales. Es
importante comprender que no es necesario que usted sea un
experto para ayudar a las personas a gestionar la tecnología y
sus riesgos asociados. El objetivo de esta guía es ayudar a los
directores ejecutivos de auditoría, a los ejecutivos del mismo
nivel, y al personal en general, a que mejoren sus conocimien-
tos sobre gestión de tecnología, a la vez que sirve para ayudar-
les a aconsejar a la dirección cómo dirigir estos procesos de
manera eficaz.
Respecto al público para quien se diseñó esta guía, los
temas relativos a control de cambio de TI raramente han cobra-
do tanta importancia como en la actualidad. Los directores eje-
cutivos de auditoría son responsables ante los comités de
auditoría y se espera que cumplan con las diversas regulaciones,
como la Ley Sarbanes-Oxley de EE. UU. de 2002, Artículo 404.
Por lo tanto, tener los conocimientos necesarios para cuestionar
la gestión de TI no sólo es útil sino también esencial.
Después de leer esta guía, usted podrá:
• Disponer de un conocimiento activo de los procesos de
gestión del cambio.
• Diferenciar rápidamente los procesos de gestión del
cambio excelentes de los ineficaces.
• Reconocer rápidamente los indicadores y las señales de
alarma indicativas de la existencia de problemas de con-
trol en los entornos de TI relacionados con la gestión
del cambio.
• Comprender que la gestión del cambio eficaz depende de
la implementación de controles preventivos, de detec-
ción y corrección para fortalecer la separación de funcio-
nes y asegurar una supervisión de gestión adecuada.
• Estar en condiciones de recomendar las mejores prácti-
cas conocidas para tratar estos problemas, tanto para
proporcionar un grado de seguridad respecto a riesgos
(incluidas las certificaciones de controles), como tam-
bién para aumentar el nivel de eficacia y eficiencia.
• Vender sus recomendaciones más eficazmente a los
Directores de TI , a los Máximos Ejecutivos y a los
Directores Financieros.
Dado que cualquier “riesgo de TI” genera cierto grado de ries-
go de negocio, es importante que el Director Ejecutivo de
Auditoría comprenda en profundidad los problemas de gestión
del cambio.
La gestión de parches y cambios se define en este documento
como el conjunto de procesos ejecutados dentro del departamen-
to de TI de la organización diseñado para gestionar mejoras, actua-
lizaciones, correcciones progresivas y parches en los sistemas de
1
GTAG — Resumen ejecutivo — 1
producción, entre ellos:
• Revisiones al código de aplicación.
• Actualizaciones de sistemas (aplicaciones, sistemas ope-
rativos, bases de datos).
• Cambios de infraestructura (servidores, cables, rutea-
dores, filtros de seguridad, etc.).
En conjunto, nos referimos a ellos como "cambios de
TI". Todas las organizaciones tienen que afrontar los cambios
de TI con eficacia porque prácticamente cualquier decisión
de negocio exige uno o más cambios en los activos. Cuando
los cambios fallan o se controlan de manera deficiente, el
impacto en el negocio puede ir desde inconvenientes meno-
res hasta eventos que impidan el logro de los objetivos del
negocio, incluida la capacidad de cumplir con un conjunto
de regulaciones cada vez más grande.
1.2 Una gestión del cambio deficiente se
puede identificar rápidamente
Esta guía fue desarrollada para ayudar a los directores ejecu-
tivos de auditoría a plantear las preguntas acertadas a la orga-
nización de TI a fin de evaluar la capacidad de gestión del
cambio. Con el propósito de ayudarlo a evaluar rápidamente
el nivel general de riesgo del proceso y a determinar si es
necesaria una revisión más detallada de ese proceso, esta guía
también proporciona las respuestas que se esperan de tales
preguntas.
Los primeros cinco indicadores de riesgo de una gestión
de cambio deficiente:
• Cambios no autorizados (un valor por encima de cero no
es aceptable).
• Interrupciones no planificadas.
• Baja tasa de éxito del cambio.
• Gran cantidad de cambios de emergencia.
• Demoras en las implementaciones de proyecto.
Esta guía incluye mediciones probadas en campo para ayu-
darle a evaluar la salud del proceso de gestión del cambio
cuantitativamente, como así también sugerirle mediciones
de gestión para guiar a su organización a lograr y mantener
niveles de control y rendimiento cada vez más altos. De esta
manera, los auditores internos pueden ayudar a la Dirección
identificando las fuentes de riesgo para la organización y eva-
luar la eficacia de los procesos de gestión de riesgo, control y
gobierno.
Entre los síntomas e indicadores fácilmente reconoci-
bles de fallos de control a causa de cambios de TI controla-
dos deficientemente se incluyen:
• Falta de disponibilidad de servicios y funciones críti-
cas, incluso durante breves períodos de tiempo.
• Inactividad imprevista del sistema o de la red que a su
vez detiene los procesos críticos del negocio, como la
coordinación de calendarios con proveedores y la res-
puesta a los pedidos del cliente.
• Inactividad de una aplicación crítica, base de datos o
servidores Web, que impide a los usuarios realizar sus
tareas críticas.
• Publicidad negativa y atraer la atención indeseada del
Consejo de Administración.
GTAG — Resumen ejecutivo — 1
A un determinado nivel organizacional, los indicadores de
que las organizaciones de TI tal vez presenten problemas sis-
témicos de control de gestión del cambio son, entre otros:
• La mayor parte del tiempo de TI de la organización se
emplea en operaciones y mantenimiento (>70%), en
lugar de ayudar al negocio a implementar nuevas
capacidades.
• Imposibilidad de completar proyectos y trabajos plani-
ficados (a causa de la necesidad de combatir numero-
sas situaciones de emergencia y trabajos no planeados).
• Se despierta a la Dirección de TI en el medio de la
noche por diversos problemas.
• Alta rotación del personal de TI.
• Relaciones de confrontación entre el personal de asis-
tencia técnica de TI, los desarrolladores y los clientes
del negocio (internos o externos), generalmente a raíz
de la mala calidad del servicio o por demoras en la
entrega de funcionalidad.
• La gestión de TI invierte una excesiva cantidad de
tiempo en prepararse para las auditorías de TI y solu-
cionar los problemas detectados.
Lo que separa a muchas organizaciones de tener un desem-
peño deficiente es sólo un cambio nada más.
1.3 Reflexiones para comprender cómo se
gestiona el cambio de TI con eficacia
La gestión del cambio frecuentemente es un tema de difícil
dominio para las organizaciones dado que hay muchas partes
interesadas involucradas (por ejemplo, gerentes de negocio,
desarrolladores de sistemas de aplicación, personal de opera-
ciones de TI, auditores, etc.). No obstante, esta no es una
razón para que las organizaciones sean complacientes con los
controles inadecuados o con desempeños deficientes.
Los entornos de producción estables y bien administra-
dos exigen que la implementación de cambios sea predecible
y repetible, que obedezca a un proceso controlado que se
pueda definir, supervisar e implementar. Los controles de TI
necesarios para alcanzar esto son análogos a los controles uti-
lizados en los procesos financieros para reducir el riesgo de
fraude y errores: separación de controles de funciones (que
son de naturaleza preventiva) y de controles de supervisión
(que son de naturaleza preventiva y de detección).
[Chambers 03]
Los directores ejecutivos de auditoría deben estar bastan-
te familiarizados con estos controles: Únicamente el personal
mínimo necesario para implementar los cambios de TI en pro-
ducción debe tener acceso a dicho entorno (preventivo). Los
procesos de autorización deben involucrar a las partes intere-
sadas para evaluar y mitigar los riesgos asociados a los cambios
propuestos (preventivo). Los procesos de supervisión deben
impulsar a la gerencia de TI y al personal relacionado a asumir
sus funciones responsablemente (preventivo) y a ser capaces
de detectar un desempeño errático (de detección).
Donna Scott, Vicepresidenta y Directora de
Investigación de Gartner, destaca que “el 80% del tiempo de
inactividad de [TI] no planificado se debe a problemas del
proceso o provocados por las personas, incluidas las prácticas
de gestión del cambio". Estos problemas surgen a partir de la
2
ausencia de controles automáticos preventivos, de detección
y corrección que posibilitan buenas decisiones basadas en el
riesgo con respecto al cambio, monitorización eficaz y apli-
cación del proceso de gestión del cambio.
Las organizaciones de alto rendimiento de TI también
han llegado a esta conclusión, que a su vez está respaldada
por un trabajo bastante amplio realizado por el Instituto de
Ingeniería de Software (en inglés, SEI) y el Instituto de
Procesos de TI (en inglés, ITPI).
¿Qué tienen en común las organizaciones de alto rendi-
miento de TI? Poseen una cultura de gestión del cambio que
impide y evita cambios sin la correspondiente autorización.
Además, "confían, pero siempre verifican" mediante el uso
de controles de detección independientes para conciliar los
cambios en la producción contra los cambios autorizados y,
en el caso de interrupciones de servicio, excluyen la opción
de "cambiar primero" en el ciclo de reparaciones. Por último,
también cuentan con el tiempo promedio de reparación más
bajo (en inglés, MTTR).
Los auditores observarán que en estas organizaciones de
alto rendimiento de TI, la gestión del cambio no se ve como
algo burocrático, sino por el contrario, como la única red de
seguridad que evita que se conviertan en una organización de
bajo rendimiento. En otras palabras, la gestión de TI posee
los controles para alcanzar sus propios objetivos de negocio
de manera eficiente y eficaz.
El logro de una tasa de éxito del cambio de más de 70% sólo
es posible con controles preventivos y de detección.
Loa auditores internos, junto con la dirección, desean asegu-
rar que los riesgos relacionados con la gestión del cambio se
hayan identificado, medido y gestionado correctamente. El
punto clave a recordar es que la gestión de cambio exige con-
centrarse en el proceso con un enfoque administrador y huma-
no que está respaldado por controles técnicos y automáticos.
1.3.1 Consideraciones regulatorias
Los procesos de gestión de cambio eficaz sirven para que la
organización pueda cumplir permanentemente con las nue-
vas y aún más amplias regulaciones. Se debe prestar especial
atención cuando se implementan cambios de tecnología que
respaldan el proceso de preparación de informes financieros.
Esos cambios pueden afectar al cumplimiento organizacional
con la Ley Sarbanes-Oxley, las directivas de privacidad de la
Unión Europea y los requisitos del Proyecto de ley del
Senado (SB) 1386 del Estado de California. Los cambios sin
control en producción pueden conducir a errores, que si son
universales o críticos, se considerarán como deficiencias
importantes. Cuando determinados controles financieros
clave se ven afectados o bien cuando la organización no
pudo corregir deficiencias importantes de control general de
TI, que fueron identificadas el año anterior (como, por ejem-
plo, en gestión del cambio), la gestión probablemente
enfrente la posibilidad de tener que resolver debilidades
materiales.
Cuando el fallo no es una opción
Al gestionar los cambios, usted controla gran parte del riesgo
potencial que los cambios pueden introducir.
 GTAG — Resumen
Introduction
ejecutivo —
–13

1.4 Los primeros cinco pasos para minimizar ellos se busca detectar las áreas que necesitan fortalecimien-
los riesgos del cambio de TI to. A esos fines, la importancia de un proceso de gestión del
En esta guía, hemos encuadrado las mejores prácticas que se cambio eficaz no se debe subestimar y los auditores internos
observaron en cuanto a procesos de gestión del cambio que deben considerar la posibilidad de efectuar revisiones regu-
reducen el riesgo del negocio y aumentan el grado de eficien- larmente.
cia y eficacia de TI. En resumen, los cinco pasos prescripti-
vos que la mayoría de las organizaciones pueden adoptar de
inmediato para mejorar sus procesos de gestión del cambio
son los siguientes:
• Crear un ambiente en la alta dirección que motive la
necesidad de una cultura de gestión del cambio en
toda la empresa, que a su vez esté respaldada por una
declaración de la gerencia de TI de que la única canti-
dad de cambios no autorizados aceptable es cero.
Entonces, se pueden poner en práctica controles pre-
ventivos y de detección para ayudar y sostener este
objetivo a fin de asegurarse de que todos los cambios
de producción sean conciliados con órdenes de traba-
jo autorizadas.
• Monitorizar continuamente la cantidad de interrup-
ciones no planeadas, lo cual es un excelente indicador
de cambios no autorizados y fallos en el control de
cambios.
• Reducir la cantidad de cambios que implican riesgos al
establecer de manera específica períodos para congela-
ción de cambios y mantenimiento bien definidos y de
estricto cumplimiento. De esta manera se maximiza el
grado de estabilidad y productividad durante las horas
de producción. Las interrupciones no planificadas sir-
ven como indicadores eficaces de que este proceso de
cambio está siendo soslayado.
• Utilice la tasa de éxito del cambio como un indicador
clave del desempeño de la gestión de TI. En los entor-
nos donde los cambios no son gestionados, monitoriza-
dos y controlados, las tasas de éxito de cambio por lo
general están por debajo del 70%. Cada cambio fallido
genera tiempo improductivo potencial, trabajos de
emergencia y no planeados, discrepancias con los pla-
nes y riesgo de negocio. Para aumentar la tasa de éxito
del cambio se necesitan controles eficaces preventivos,
de detección y corrección.
• Utilice el trabajo no planificado como indicador de
eficacia de los procesos y controles de gestión de TI.
Las organizaciones de TI con alto rendimiento dedican
menos del 5% de su tiempo a trabajos no planificados,
en tanto que las organizaciones promedio más frecuen-
temente emplean del 45% al 55% de su tiempo en
actividades no planeadas (y urgentes).

1.5 El rol del auditor interno

El Comité de Auditoría desea asegurarse de que la gerencia
haya identificado y evaluado los riesgos que podrían impedir
alcanzar los objetivos del negocio. Se deben adoptar proce-
sos robustos para mitigar, gestionar, aceptar o transferir los
riesgos eficazmente. Los auditores internos son los ojos y
oídos de la gerencia y del comité de auditoría, a través de

3
GTAG — Introducción — 2
Esta guía aborda la gestión de parches y cambios de TI como
herramienta de gestión y trata los siguientes temas:ón y trata
los siguientes temas:
• ¿Por qué la gestión de parches y cambios de TI es
importante?
• ¿De qué manera la gestión de parches y cambios de TI
ayuda a controlar los riesgos y los costos de TI?
• ¿Qué estrategias funcionan y cuáles no?
• ¿Cómo saber si la gestión de parches y cambios de TI
funciona eficazmente?
• ¿Qué debe hacer la auditoría interna?
Los apéndices de la guía proporcionan herramientas a la
gerencia y a los auditores para entender y abordar los riesgos
inherentes a la gestión de parches y cambios de TI.
2.1 ¿Por qué la gestión de parches y cambios de
TI es importante?
Las recientes investigaciones han demostrado que una ges-
tión deficiente de parches y cambios de TI aumenta el tiem-
po improductivo y los costos. Hay ejemplos destacados que
ilustran este problema. CNET News informó que en 2001,
un “error de configuración del ruteador” de Microsoft inte-
rrumpió el servicio a Microsoft.com, MSN.com,
Expedia.com y a otros más. No se pudo reanudar el servicio
por completo sino hasta después de transcurridas 22 horas.1
En el año 2004, el diario Globe and Mail informó sobre un
cambio de software relativamente menor en el banco Royal
Bank de Canadá que ocasionó que “de repente, 10 millones
de clientes del banco no pudieran saber con seguridad los sal-
dos de sus cuentas durante varios días y una cantidad no
especificada de personas se quedó esperando para realizar
depósitos y otras transferencias”2 ¿De qué forma se puede
siquiera comenzar a calcular los costos de tales problemas?
Considere que las organizaciones que tienen mejor gestión
de parches y cambios ostentan las siguientes características:
• Gastan menos dinero y energía de TI en trabajo no
planificado.
• Destinan más cantidad de dinero y energía de TI a
nuevos trabajos y a alcanzar las metas del negocio.
• Tienen menos tiempo improductivo.
• Instalan parches con interrupciones mínimas.
• Se concentran más en las mejoras y menos en “apagar
incendios”.
Si las organizaciones necesitan más incentivos que estos, la
Ley Sarbanes-Oxley (para aquellos a quienes compete) los
proporciona al exigirle a la dirección ejecutiva que compren-
da y apruebe formalmente los controles sobre la preparación
de informes financieros, incluidos los controles de TI. Sin una
gestión del cambio de TI eficaz, es difícil ver cómo la direc-
ción puede cumplir con los requisitos de la Ley y garantizar la
integridad de los estados financieros.
2.2 ¿De qué manera la gestión de parches y
cambios de TI ayuda a controlar los riesgos
y los costos de TI?
Los riesgos de TI de cualquier tipo se pueden ver exacerba-
dos por una gestión del cambio de TI ineficaz. En oposición,
1
“Microsoft responsabiliza a los técnicos por la interrupción masiva del servicio”, CNET News, 24 de enero de 2001
4
2
“RBC adjudica la culpa a errores humanos”, GLOBEANDMAIL.com, 10 de junio de 2004.
los riesgos se pueden controlar mediante procesos de gestión
de parches y cambios prudentes y bien diseñados. Tal vez sea
menos evidente que una buena gestión de parches y cambios
de TI puede reducir costos.
Sin control y visibilidad adecuados, una organización
puede gastar dinero y esfuerzo en cambios innecesarios y
menos prioritarios, a la vez que se descuidan iniciativas
más importantes. Los cambios de diseño deficiente o sin
la ponderación adecuada pueden ocasionar interrupcio-
nes que luego, después del hecho, deberán ser resueltas, o
bien puede ocurrir que se deban “retirar” los cambios rea-
lizados. Los cambios de TI en un componente pueden
interrumpir la operación de otros componentes. Estas
interrupciones cuestan tiempo y dinero, sin embargo, se
pueden mitigar mediante un buen proceso de gestión de
parches y cambios de TI.
Por último, la gestión del cambio de TI ineficiente
e ineficaz puede costarle a la organización las siguientes con-
secuencias:
• Desgaste del personal de TI altamente calificado debi-
do a la frustración producida por los resultados de baja
calidad.
• Sistemas de baja calidad que impiden a los empleados
ser eficaces y eficientes, o que hacen perder clientes.
• Pérdida de oportunidades para proporcionar a los
clientes servicios y productos innovadores o más efi-
cientes.
Los procesos de gestión del cambio de TI bien diseñados y
rigurosamente implementados pueden producir los resulta-
dos opuestos. Los esfuerzos de TI se pueden centrar en las
prioridades del negocio. Se pueden minimizar las situaciones
de emergencias al respecto. Se puede retener al personal de
TI y motivarlo para alcanzar la excelencia. Se puede propor-
cionar a los empleados herramientas que ampliarán su pro-
ductividad. Los clientes se sentirán satisfechos con sistemas
que responden a sus necesidades.
2.3 ¿Qué estrategias funcionan y cuáles no?
Para ser eficaz, la gestión del cambio de TI debe proporcio-
nar a la dirección de la organización un grado de visibilidad
en los siguientes puntos:
• Qué es lo que se cambia, por qué y cuándo.
• Cómo se implementan los cambios eficiente y
eficazmente.
• Cuáles son los problemas ocasionados por los cambios
y qué grado de severidad tienen.
• Cuánto cuestan los cambios.
• Cuáles son los beneficios que brindarán los cambios.
Esa visibilidad se proporciona a través de mediciones e indi-
cadores que se informan de manera regular y objetiva. Esos son
los instrumentos del tablero de mando que otorgan a la direc-
ción la visibilidad necesaria.
La gestión del cambio de TI proporciona el acelerador, el
pedal de freno y el volante (y una marcha atrás para volver a
las configuraciones anteriores) para controlar el vehículo de
TI a través de:

• La participación temprana y frecuente por parte de la
dirección y de los usuarios finales para alinear los cam-
bios de TI con las necesidades del negocio.
• Un proceso definido, predecible y repetible con resul-
tados definidos, predecibles y repetibles.
• Coordinación y comunicación con los participantes
afectados por los cambios.
2.4 ¿Cómo saber si la gestión de parches y
cambios de TI funciona eficazmente?
Como guía general, la dirección (incluida la gestión de TI)
puede verificar si la gestión de parches y cambios está dando
resultados mediante la formulación de una serie de preguntas
simples y el análisis de las respuestas:
• ¿Tenemos un proceso de gestión del cambio eficaz?
¿La respuesta es una negación de la importancia de la ges-
tión del cambio de TI o una afirmación de su importancia
y reconocimiento de las mejoras en curso?
• ¿Qué controles se han adoptado en nuestro proceso
de gestión del cambio?
¿Los controles se han puesto en práctica y se mejoran día
a día o simplemente están en evaluación y se aplaza su
incorporación hasta que la situación de emergencia pase?
• ¿Hemos visto los beneficios del proceso de gestión del
cambio?
¿Hay beneficios medibles o el énfasis está centrado en los
costos del proceso de gestión del cambio de TI?
• ¿Recuerda la interrupción que afectó a todo el sitio
durante la semana pasada como consecuencia de un
cambio? ¿Qué pasó?
¿Cuánto sabe la dirección acerca de las causas de las inte-
rrupciones? ¿Cuál es el grado de control que tiene la
dirección respecto a la recurrencia del problema?
• ¿Qué proceso se utilizó para determinar la causa de la
interrupción?
¿Fue de tipo ad hoc o metódico? ¿El diagnóstico del pro-
blema determinó rápidamente si la interrupción fue causa-
da por un cambio, y de ser así, qué cambio provocó el
problema?
• ¿De qué manera TI controla el estado de salud del
proceso?
¿Los indicadores y medidas son elementos indicativos obje-
tivos y verdaderos o son subjetivos y sospechosos?
• ¿Cuál es la meta de nuestro proceso de gestión del
cambio?
¿Se centra en factores de fiabilidad, disponibilidad y efi-
ciencia, o en otras metas menos cruciales? ¿En ese aspec-
to, está realmente centrado en algo?
• ¿Nuestro proceso de parches qué grado de interrupcio-
nes ocasiona?
¿La gestión de parches es parte de un proceso de lanza-
mientos y cambios definido y repetible, o es del tipo ad
hoc, informal y basado en emergencias?
Las investigaciones recientes sugieren que las organizaciones
que tienen mejores procesos de gestión de parches y cambios
de TI necesitan menos administradores de sistemas. Cuando
la gestión de parches y cambios de TI funciona bien, el per-
sonal de TI es más eficaz y productivo.
5
3
Adaptado del libro de Auditoría de Montgomery: 12ª edición, Capítulo 1: “Resumen de Auditoría” [O'Reilly 98]
GTAG — Introducción — 2
Se deben informar las medidas más rigurosas y formales
para proporcionar la máxima visibilidad sobre la eficacia de
la gestión de parches y cambios de TI, entre ellos:
• Cambios autorizados por semana.
• Cambios implementados por semana.
• Cantidad de cambios no autorizados que soslayan el
proceso del cambio.
• Tasa de éxito del cambio (porcentaje de los cambios
reales efectuados que no ocasionaron interrupciones,
deterioro de servicios o un episodio de trabajo no pla-
nificado).
• Cantidad de cambios de emergencia (incluidos los par-
ches).
• Porcentaje de parches implementados en las versiones
de software planificadas.
• Porcentaje de tiempo empleado en trabajo no planifi-
cado.
• Porcentaje de proyectos entregados más tarde de lo
planificado.
2.5 ¿Qué debería hacer auditoría interna?
Esta Guía de Auditoría de Tecnología Global (GTAG) trata
sobre la gestión de los riesgos que son una preocupación cre-
ciente de aquellas personas implicadas en el control y goberna-
bilidad del proceso. Al igual que la seguridad de la información,
la gestión de los cambios de TI es un proceso fundamental que,
de no efectuarse correctamente, puede ocasionar daños a toda
la empresa. Este impacto a nivel de toda la empresa hace que
el tema sea de interés para la mayoría de los comités de audito-
ría y, en consecuencia, para la alta dirección.
Esta guía proporciona herramientas para ayudar a los
auditores internos a obtener y evaluar las evidencias de que las
aseveraciones de la gestión de TI (desempeño, eficacia, efi-
ciencia) son correctas. Al igual que en el proceso de una audi-
toría3 financiera, los auditores de TI deben obtener los datos
subyacentes de autorización (por ejemplo, informes del cam-
bio autorizado) y la infor--mación que sirve de respaldo y evi-
dencia los hechos (por ejemplo, informe de los cambios de
producción a partir de los controles de detección, cotejo de los
cambios de producción con los cambios autorizados, las inte-
rrupciones de sistema, etc.). Al hacer esto, los auditores pue-
den expresar de manera competente una opinión sobre las
aseveraciones de la gestión de TI respecto a sus procesos de
gestión del cambio y su capacidad de mitigar el riesgo en los
estados financieros.
La auditoría interna puede ayudar a la dirección y al con-
sejo de administración implementando las siguientes accio-
nes:
• Comprender los objetivos de la organización relaciona-
dos con la confidencialidad, integridad y disponibilidad
del procesamiento de TI.
• Ayudar a identificar los riesgos que pueden surgir a par-
tir de los cambios y determinar si tales riesgos son cohe-
rentes con el grado de apetito de riesgo y tolerancia de
la organización.
• Ayudar en la toma de decisión en cuanto a elegir una
cartera apropiada que responda a la gestión de riesgos.
• Buscar e impulsar una cultura de gestión de cambio dis-
GTAG — Introducción — 2
ciplinada, incluida la promoción de los beneficios de
una buena gestión de cambio.
• Comprender los controles que son cruciales para un
enfoque sólido de la gestión del cambio de TI.
– Preventivos.
• Autorizaciones apropiadas.
• Separación de funciones.
• Supervisión.
– De detección.
• Detección de cambios no autorizados.
• Monitorización de las mediciones de la gestión
del cambio objetivo y válido..
– De corrección.
• Revisiones posteriores a la implementación.
• Alimentación de información del cambio durante
los primeros pasos de diagnóstico del problema.
• Mantener actualizados los procesos de gestión de par-
ches y cambios de TI y recomendar su adopción a la
organización.
• Demostrar de qué manera la dirección puede cosechar
los beneficios provenientes de una mejor gestión del
riesgo, del mayor grado de eficacia y de los menores cos-
tos.
• Ayudar a la dirección a identificar enfoques prácticos y
eficaces en relación con la gestión del cambio de TI.
2.6 Un diálogo esclarecedor entre un Director
de TI (DTI) y un Director Ejecutivo de
Auditoría (DEA)
Uno de los desafíos para un gobierno y auditoría de TI efica-
ces es realizar buenas preguntas que revelen de qué manera
los gerentes de TI piensan y verifican que las estrategias y las
tácticas de TI respondan a los objetivos del negocio. Con
frecuencia, las conversaciones se centran en las tecnologías
más que en los procesos de control y gestión para implemen-
tar y sostener esa tecnología, y operarla de manera eficiente.
Muchos ven la gestión del cambio como una burocracia
innecesaria, y no como una herramienta que posibilita el logro
de las metas del negocio. Además, muchas organizaciones de
TI confunden a las tecnologías del tipo de los sistemas de soft-
ware de gestión de parches como si fueran el sustituto de un
proceso de gestión saludable. Si bien el software de gestión de
cambio puede automatizar los controles para ayudar a asegurar
la aplicación del proceso de gestión del cambio, el sólo hecho
de tener el software no proporciona los resultados necesarios.
Los ejecutivos de auditoría de rango superior pueden
proporcionar orientación y asesoramiento a los gerentes de
TI sin profundizar en detalles técnicos que desvían la aten-
ción de la pregunta real: ¿Nuestros procesos de gestión del cam-
bio son eficaces y estamos llevando a cabo las actividades
correctas de TI basadas en el cambio?
Para mostrar con qué rapidez el director ejecutivo de
auditoría puede determinar la salud de los procesos de ges-
tión del cambio de TI, incluimos un diálogo ficticio entre
Silvia, quien recientemente tomó su nuevo puesto de traba-
jo como DTI de una de las empresas Fortune 500 (DTI), y
Fernando, el DEA. El diálogo ilustra cómo las suposiciones
erróneas se evidencian incluso en los gerentes de TI de rango
superior y cómo estas suposiciones se pueden cuestionar con
eficacia para provocar cambios drásticos en sus sistemas de
6
creencias y enfoques.
¿Por qué un diálogo? El Dr. Eliyahu Goldratt adquirió pro-
tagonismo en 1980 por su trabajo sobre la teoría de las restric-
ciones, que es uno de los tres movimientos de gestión clave de
esta década. (Los otros dos sistemas de gestión y de resolución
de problemas son la Gestión de Calidad Total del Dr. W.
Edward Deming y las metodologías de fabricación, como Justo
a Tiempo). Probablemente el Dr. Goldratt sea más famoso por
su libro The Goal: A Process of Ongoing Improvement [Goldratt
92], donde el protagonista es un gerente de planta que inten-
ta aumentar la calidad y disminuir el costo antes del cierre de
la planta en 60 días. Su libro ha vendido millones de copias y
se utiliza en cientos de cursos universitarios de todo el mundo.
Este diálogo está inspirado en The Goal.
2.6.1 La convicción de Silvia en su plan de gestión
de parches se hace añicos
Hace una semana, a Silvia la ascendieron de Directora de
Operaciones a Directora de TI (DTI). Debe afrontar los
desafíos de abordar no sólo todos los problemas de disponibi-
lidad y competitividad de costos de TI, sino también los
molestos problemas de seguridad. Hay abundantes rumores
de que toda su división será externalizada.
Silvia está esperando para entrar a la reunión de comité
de auditoría. Fernando, DEA, también está esperando junto
a ella. Fernando se unió a la empresa hace seis meses y pro-
viene de una conocida firma de telecomunicaciones global.
Silvia se pregunta si debería aprovechar esta oportunidad
para conocer más a Fernando. Desarrollar una relación de
trabajo de respeto mutuo podría mejorar su función DTI.
Silvia abrió el diálogo diciendo “Fernando, estoy poco
nerviosa por la reunión. Esta es mi primera actualización
sobre el estado del programa de seguridad de la información
de la empresa”. Fernando es un veterano en el tema dadas sus
numerosas interacciones con el comité de auditoria y de
inmediato siente simpatía por Silvia y su preocupación.
“No te preocupes. Si puedes definir tus metas con clari-
dad y describir lo que necesitas para alcanzarlas, estoy seguro
de que no habrá ningún problema. No te dejes intimidar por
la reputación del comité de auditoría. He estado en ambos
lados de la mesa y me parece que estas personas son muy pro-
fesionales, competentes y agradables”.
“¿De veras? Entiendo que te incorporaste a la empresa a
principios de año y que provienes de ABC Telecom. ¿Estabas
a cargo de la auditoría interna allá?”, pregunta Silvia.
“No, mi experiencia en realidad incluye algunos perío-
dos en TI y en auditoría financiera e investigación de frau-
des”, responde Fernando. “Considérame como una persona
de negocios que trabaja en auditoría interna”.
Al escuchar esto, Silvia se siente de inmediato más tran-
quila. ¡Tenemos antecedentes similares! “Entonces, conoces
los temas que debo afrontar. ¡Eso es un verdadero alivio!
Sabes por lo que estoy pasando. Ya hemos logrado salir del
apuro de cerrar los baches existentes en la seguridad de la
información Mi idea es contarles lo que hemos estado
haciendo para aplicar los parches con más rapidez y reducir
las vulnerabilidades ante gusanos y virus. Antes de ser desig-
nada DTI tuve a mi cargo la tarea de desarrollar nuestro
nuevo sistema de gestión de parches”.
Fernando duda. “¿Te pareció que era necesario un siste-

ma totalmente nuevo para ayudarte a administrar los par-
ches?”
“Sí”, contesta Silvia. “Hemos estado trabajando en esto
durante seis meses para solucionar un problema detectado en
una auditoría y reducir nuestra carga de trabajo”.
Verdaderamente se logró mejorar la eficiencia y la seguridad.
Nunca más se nos pasará un parche importante”.
Fernando frunce el ceño. “Ah, la verdad es que no
muchas veces escucho algo así. Permíteme preguntarte esto:
¿cuándo es aceptable no implementar un parche?”
Ahora es Silvia la que comienza a fruncir el ceño.
Fernando parecía una persona muy inteligente, pero sus pre-
guntas son bastantes extrañas. Silvia responde, “Bueno, en
realidad, ¡nunca! Justamente, la omisión de parches es exac-
tamente lo que nos valió la observación de auditoría en pri-
mera instancia. Mi meta es asegurarnos de que siempre
implementemos los parches tan pronto como sea posible. ¡Al
fin y al cabo, nuestra tarea es asegurarnos de que estos servi-
dores son seguros! No solamente vamos a tener más seguri-
dad, sino que además seremos más eficientes”.
Fernando parece algo exasperado. “¿De veras? ¿Estás
implementando tecnología de gestión de parches y obtienes
realmente un grado mayor de eficiencia?”
“Rotundamente. Ya hemos obtenido excelentes resulta-
dos. En realidad, recientemente hemos alcanzado el hito de
cobertura de servidores del 60%”.
“¿Y pudieron aumentar la eficiencia… en qué grado?”,
pregunta Fernando.
“Bueno, no tengo todos los detalles, pero sé que el retor-
no de la inversión es importante”. Silvia busca en su maletín
y con orgullo le muestra a Fernando el informe de una pul-
gada de espesor. “Aquí está. Al automatizar el proceso de
parches, estaremos ahorrando entre 300 y 600 horas del per-
sonal por mes”.
Fernando mira el informe, pero no lo toma. “¡Increíble,
600 horas de personal por mes! Ese ahorro equivale a más de
tres empleados a tiempo completo. ¿Entonces, estás redu-
ciendo el número de trabajadores en tres personas gracias a
todo ese ahorro de mano de obra?”
“¡Ojalá fuera así! Siempre tenemos un cúmulo de traba-
jo atrasado porque no tenemos personal suficiente.
Permanentemente hay nuevos proyectos, y ni siquiera men-
cionemos las constantes emergencias por roturas y correccio-
nes que nos exigen dejar lo que estemos haciendo para correr
a reparar la catástrofe del día. Esa es justamente la razón por
la que necesitamos automatizar todo”.
Fernando se reclina y se sonríe como si hubiera confir-
mado una sospecha. Silvia se siente algo insegura. Fernando
pregunta, “¿Qué están haciendo exactamente en este instan-
te esas dos personas que completaron la implementación?”
“Bueno, como dije, se están ocupando de diversos proble-
mas que varían de emergencias operacionales a desafíos impre-
vistos relacionados con el sistema nuevo. Con frecuencia, nos
topamos con parches que no se aplican correctamente la pri-
mera vez y siempre hay algunas cuestiones residuales que debe-
mos corregir manualmente. Estos problemas se resolverán una
vez que logremos establecer el proceso”.
“¿Entonces, estás diciendo que la tasa de éxito inicial del
sistema es relativamente baja?”, pregunta Fernando.
7
GTAG — Introducción — 2
“Bueno, tal vez, pero estoy segura de que con el tiempo,
podremos resolverlo”, responde Silvia, un poco a la defensiva.
“¿Todo este trabajo no planeado tiene un impacto sobre
tu disponibilidad, verdad?”, continúa Fernando.
Ajá. Fernando mencionó el asunto de la disponibilidad.
Ese es un punto definitivamente sensible. Silvia recuerda las
reuniones de confrontación con distintos gerentes de unida-
des de negocio a quienes les impactó el tema del fallo de
algunos parches. “Bueno, cierto que sí, en algún grado. Pero,
¿hacia adónde apuntas con todo esto?”
Fernando hace caso omiso de su pregunta. En cambio,
pregunta, “¿Y este sistema de gestión de parches resolvió las
observaciones realizadas por auditoría? Mi informe para el
comité de auditoría de hoy señala que la fecha de finaliza-
ción del objetivo en tu plan de acción se sigue postergando
cada día”.
Transcurren unos instantes durante los cuales Silvia
trata de pensar una respuesta. En una voz tan confidente
como le es posible, responde “Bueno, no, esas observaciones
de auditoría no se han resuelto todavía, pero nos hemos
comprometido a hacer que el sistema funcione”.
2.6.2 Fernando saca conclusiones según los hechos
“Silvia, imagino que si no has aumentado la disponibilidad ni la
seguridad, no has disminuido el gasto operacional, y en realidad
estás generando más trabajo no planeado, entonces no me pue-
des decir que estás incrementando el grado de eficiencia”
“Es más, es muy probable que estés acelerando la tasa de
cambio al implementar parches sin aumentar la tasa de
éxito, por lo tanto, tu cantidad de trabajo no planeado se
debe estar incrementando sideralmente. Adivino que los
gerentes de unidades de negocio estarán tan molestos que
piden a gritos la desconexión del sistema completo”.
Anonadada, Silvia se pregunta para qué inició esta con-
versación con Fernando. Iba a presentar con orgullo su plan
de gestión de parches y ahora ni siquiera está segura de que
eso sea una buena idea.
“Fernando, ¿cómo sabes esas cosas? Ojalá pudiéramos
tener más tiempo porque pareciera que has puesto tu dedo en
uno de mis mayores problemas”.
“Opino lo mismo. Si tuviéramos un poco más de tiem-
po, me parece que podría ayudarte a mantener el trabajo de
TI dentro de la empresa y salvar tu nuevo puesto”.
“¡Un momento! Mi organización no está en apuros. Con
un software tan deficiente como el que tenemos hoy, es nece-
sario automatizar el proceso de parches para mantener la
infraestructura segura. El negocio sigue imponiéndonos
demandas totalmente insanas sin comprender los temas de
TI o seguridad".
“Silvia, para mí, es evidente que no estás ejecutando
una operación de TI segura y eficiente. En realidad, proba-
blemente estés gestionando una operación ineficiente e inse-
gura. Si el comité de auditoría comienza a realizar preguntas,
esto se hará evidente y tal vez perciba que no estás adminis-
trando los riesgos correctamente. Según esta breve conversa-
ción, creo que hay determinados problemas sistémicos de
control del cambio de TI. Mi parecer es que no tienes los
controles preventivos, de detección y corrección que necesi-
tas para aplicar la separación de roles adecuada y los contro-
les de supervisión eficaz.”
GTAG — Introducción — 2

“¿Me estás diciendo que mi gente me miente?”

“En general, la gente rara vez miente acerca de estas
cosas. Sin embargo, tus mediciones ciertamente sí. Cuando
hablas de eficiencia, me parece que no has comprendido
bien el punto central del tema. Es necesario que pienses
acerca de este asunto un poco más. Las próximas dos sema-
nas, estaré afuera de viaje, pero, si lo deseas, puedes llamar a
mi asistente y concertar una cita para que hablemos de esto”.
Luego, Fernando se levanta e ingresa a la sala de conferen-
cias.
Más tarde, llaman a Silvia para que ingrese a la reunión
y con éxito presenta el plan de seguridad de la información
y los logros ante el comité de auditoría. En 15 minutos, fina-
liza y regresa a su oficina.
“¿Qué fue lo que pasó?, se pregunta Silvia. Antes de su
conversación con Fernando, la gestión de parches era el cen-
tro de su plan y anhelaba utilizar el éxito de esta para demos-
trarles a todos cuán competente era. Pero después de su
conversación con Fernando, su confianza se había desmoro-
nado de tal manera que en su presentación ante el comité de
auditoría sólo mencionó la gestión de parches muy breve-
mente. Y lo peor de todo era que no podía ver qué era lo que
estaba mal.
Silvia admite para sí misma que su implementación del
sistema de gestión de parches no está funcionando según lo
planeado. La fecha de finalización del proyecto se demora
cada día más. Se pregunta cómo Fernando pudo saber que el
proyecto estaba comenzando a desviarse de la meta ¿Qué
quiso significar Fernando cuando dijo que ella no había
entendido bien y que no estaba gestionando el asunto
correctamente?
El resultado de este diálogo se encuentra en la Parte 5,
página 25.

8
 GTAG — ¿Por qué debo interesarme en cómo
la organización gestiona el cambio? — 3
Los auditores internos y los profesionales de TI tienen
amplia información sobre las disciplinas informáticas opera-
tivas de gestión del cambio y control del cambio. Estos pro-
cesos ha sido bien definidos en publicaciones que se
remontan a Computer Control and Audit de Mair, Wood &
Davis [Mair 73] y otras. El Instituto de Auditores Internos y
su publicación, Systems Auditability and Control, de 1977
marcaron un hito. Esta fue actualizada en 1994 y refleja ade-
cuadamente la importancia de este tema para la direción de
las organizaciones y los auditores internos.
La gestión del cambio y del problema es crítica para
alcanzar una operación estable, confiable y bien con-
trolada. Implica rastreo del problema, procedimientos
de escalamiento, revisión de los problemas y cambios
de la gestión, establecimiento de un orden de priori-
dad de recursos, movimiento controlado de programas
en producción, y control del cambio de software de
sistemas.
Sin embargo, sólo recientemente se han realizado esfuerzos
para entender cuáles son las prácticas y condiciones de
entornos de TI que impulsan resultados comerciales. La
nueva investigación publicada por el Instituto de Ingeniería
de Software y el Instituto de Procesos de TI en 2004 muestra
que una de las diferencias clave que definen el alto o el bajo
rendimiento de las organizaciones de seguridad y TI es la pre-
sencia de una cultura eficaz de la gestión del cambio. En
otras palabras, la gestión del cambio no sólo es un control
básico clave, sino que también ofrece potenciales beneficios
para el negocio.
El informe titulado Best in Class Security and Operations
Round Table Report (BIC SORT) [Allen 04], reproduce algu-
nas de las diferencias que hay entre los departamentos de
seguridad y de TI de alto y bajo rendimiento. El informe des-
cribe los problemas y las inquietudes principales, los procesos
y procedimientos resultantes utilizados para responder a
ellos, así como los sistemas de creencias y la cultura que sos-
tiene a tales procesos y procedimientos. Con esta visión, los
autores descubrieron cómo se comportaban las organizacio-
nes de alto y bajo rendimiento, tanto cuantitativa como cua-
litativamente.
En las organizaciones de bajo rendimiento, la gerencia
no puede confiar en la gestión del cambio de TI para respal-
dar su negocio adecuadamente. Exacerbando este punto, las
organizaciones que carecen de una disciplina de gestión del
cambio, tampoco tienen mediciones rigurosas y visibilidad.
La gerencia y la auditoría interna, respecto a eso, no tiene
ninguna manera confiable de evaluar con exactitud la efica-
cia y eficiencia del proceso de gestión del cambio. Cuando el
aseguramiento de los controles del cambio que respaldan un
proceso de negocios se ve suficientemente socavado, el
mismo proceso del negocio también se ve socavado. En con-
traste, las organizaciones de gestión del cambio de IT de alto
rendimiento pueden proporcionar información centrada y
exacta para ajustar su propio desempeño, y para permitir a la
gerencia y a los auditores evaluar el proceso de gestión del
cambio junto con la capacidad de respaldar los procesos del
negocio afectados.
Como auditores internos, debemos familiarizarnos con
este tipo de información y aplicarla en las revisiones de audi-
9
4
CERT® es marca registrada en la Oficina de Patentes y Marcas Registradas de EE. UU. por la Universidad Carnegie Mellon.
toría para ayudar a nuestras organizaciones a administrar las
inversiones de TI con mayor grado de eficiencia y eficacia.
3.1 El cambio genera riesgos: por qué los
parches deben ser tratados simplemente
como otro cambio
Los auditores saben que existe una relación estrecha entre el
cambio y el riesgo. Los activos de TI parecen estar en un
estado de cambio constante. La gestión de TI debe tratar con
lo siguiente:
• Cambios regulares (por lo general, aplicaciones, soft-
ware intermedio, sistema operativo, software de la red
y actualizaciones de hardware programadas para la
implementación).
• Parches (cambios para reparar códigos defectuosos u
otras vulnerabilidades detectadas en producción).
• Cambios de emergencia necesarios para corregir pro-
blemas inmediatos que provocan la interrupción del
servicio.
La gestión del cambio de TI eficaz permite que la organiza-
ción se pueda mover con seguridad de un estado conocido y
definido a otro, independientemente de la razón que motive
un cambio.
Los activos de TI son más fáciles de administrar y con-
trolar cuando no existe la presión de implementar o entregar
el cambio. Por ejemplo, considere las características positi-
vas asociadas con los períodos de congelación del cambio: los
niveles de servicio y disponibilidad son los más altos, y el
departamento de TI emplea la mayor parte de su tiempo en
trabajos planeados.
Sin embargo, ¿qué ocurre cuando se detectan vulnerabi-
lidades críticas y se incrementa el nivel de urgencia del cam-
bio? ¿Qué sucede cuando los numerosos proveedores con
quienes usted trabaja lanzan parches regularmente para repa-
rar fallos críticos? Según PricewaterhouseCoopers [PWC 04],
el volumen puro de cambios está en aumento, lo cual puede
tener un impacto significativo en la estrategia de la gestión
de TI para administrarlos:
La aplicación y el software de sistema operativo contienen
un gran número de errores y vulnerabilidades que quedan
por descubrirse más allá de las fechas de lanzamiento ori-
ginales. En 1999 se informó sobre 417 vulnerabilidades
de software, según el Centro de Coordinación 4 CERT®
de la Universidad Carnegie Mellon. Para 2003, la canti-
dad de vulnerabilidades reportadas había ascendido a
3.784 o a aproximadamente 73 [nuevas] vulnerabilida-
des por semana.
En el taller de BIC SORT, muchos participantes identifica-
ron como problema crítico el volumen de parches urgentes a
ser aplicados en la infraestructura operativa y la ausencia de
un proceso de gestión eficaz para administrarlos. Sin embar-
go, el contraste entre cómo las organizaciones de alto y bajo
rendimiento percibieron y respondieron a este problema fue
notable. Las organizaciones de alto rendimiento implemen-
taron parches en su infraestructura con una frecuencia
mucho menor que las de bajo rendimiento. Más esclarecedo-
ra aún resultó la comparación de los sistemas de creencias
que guiaron a la gestión de TI cuando se tomaron las decisio-
nes respecto a parches.
GTAG — ¿Por qué debo interesarme en cómo
la organización gestiona el cambio? — 3
En las organizaciones de bajo rendimiento la implemen-
tación de parches se caracteriza como de tipo ad hoc, caótica
y urgente. La disponibilidad de un parche para solucionar una
vulnerabilidad de seguridad crítica puede ocasionar interrup-
ciones y a menudo da como resultado cantidades significativas
de recursos que se redireccionan desde trabajos planeados para
solucionar el parche no planeado. Y lo que es peor aún, inclu-
so la implementación exitosa del parche puede provocar pro-
blemas no deseados, como el caso de servidores que se tornan
no funcionales y, por lo tanto, no disponibles para entregar
servicios críticos. Una investigación de directores de seguridad
de la información (en inglés, CISO) pertenecientes al gobier-
no federal de EE.UU., realizada por Intelligent Decisions e
informada por InformationWeek [Hulme 04] calificó la inquie-
tud de sostener la gestión de parches en el máximo nivel como
el problema más grande a afrontar.
La gestión de parches se ubicó en tan alta jerarquía porque
afecta a todas las partes de la infraestructura y hay tantos
parches que se lanzan habitualmente que a todos les preo-
cupa poder seguirles el ritmo.
En contraste, las organizaciones de alto rendimiento conside-
ran al nuevo parche como un cambio planeado y predecible
en el proceso normal de gestión del cambio. El parche se agre-
ga a la cola de “candidatos a la ingeniería de liberación”,
donde se evalúa, se prueba y se integra a una implementación
de liberación ya programada. Al seguir un proceso bien defini-
do para integrar los cambios, se alcanza una tasa de éxito del
cambio mucho más alta. Resulta interesante observar que gran
parte de las organizaciones de alto rendimiento aplican par-
ches mucho menos frecuentemente que las de bajo rendimien-
to, a veces en una proporción de una o dos órdenes de
magnitud. Las de alto rendimiento ven al riesgo de la exposi-
ción de vulnerabilidad menor que el riesgo de disponibilidad
debido a impactos no anticipados de un cambio erróneo o
fuera de ciclo. En oposición, las organizaciones de alto rendi-
miento que optan por implementar un parche como un cam-
bio de alta prioridad tienen la capacidad de hacerlo de una
manera predecible y repetible a través del uso de un proceso
de gestión del cambio eficaz.
Las organizaciones de alto rendimiento aplican parches
mucho menos frecuentemente que las de bajo rendimiento, a
veces en una proporción de una o dos órdenes de magnitud.
Dada esta visión y durante la duración de esta guía, tratamos
los parches como una categoría o clase de cambio que está
sujeta al proceso normal de gestión del cambio. Así emergen
dos inferencias clave: la gestión de parches es una función
subordinada a la gestión del cambio y a menudo, un proceso
de gestión del cambio eficaz puede ayudar a asegurar que las
tecnologías utilizadas para solucionar el problema de tipo
“implemente el parche y cruce sus dedos” no creen proble-
mas adicionales.
3.2 Ya tenemos un proceso de gestión del
cambio ¿Cuál es la diferencia aquí?
Un aspecto clave de la gestión eficaz es que la organización
tiene controles amplios, bien definidos, preventivos, de
5
En el Apéndice A, Cuadro 4 (página 38) se describen algunos roles a modo de ejemplo. Además, una organización debe asegurarse de que las funciones
de los participantes del proceso estén separadas correctamente (Cuadro 5, página 38).
10
detección y corrección, así como una clara definición y sepa-
ración de los roles. Los controles de gestión del cambio permi-
ten a la gerencia afrontar nuevos requerimientos (como
nuevos proyectos de desarrollo y nuevas regulaciones guberna-
mentales) sin tener que aumentar los recursos. Por lo general,
la gestión del cambio eficaz mitiga el riesgo, disminuye el costo
y proporciona recursos para servicios adicionales.
En oposición, la gestión del cambio ineficaz genera un ries-
go alto. En la mayoría de las organizaciones no se trata de si exis-
te o no un proceso de gestión del cambio, se trata de si el proceso
es tan eficaz y eficiente como es posible y si se utiliza para todos
los cambios de TI. Al implementar los cambios de emergencia es
extremadamente difícil evitar errores, irregularidades e interrup-
ciones no buscadas. Las interrupciones en cuanto a disponibili-
dad de TI (que a su vez da como resultado un servicio de baja
calidad y la insatisfacción del cliente) a menudo impulsa a las
organizaciones a considerar e implementar procesos de gestión
de cambio y controles. Las investigaciones señalan que los depar-
tamentos de TI de alto rendimiento están continuamente bus-
cando formas de mejorar sus procesos operativos, incluida la
gestión del cambio. Al mejorar el control y la predecibilidad de
los cambios en los sistemas y las redes, su departamento de TI
estará encaminado a convertirse en una organización de primer
nivel. Los auditores internos están en la posición ideal para ayu-
dar a la gerencia a mejorar estos procesos y controles.
Si el departamento de TI no puede describir todos los cambios
y sus estados actuales, tampoco podrá describir lo que está
administrando o si los cambios están funcionando según lo
planeado.
Aunque resulta fácil hablar de la gestión del cambio, esta es
una de las disciplinas más difíciles de implementar. Requiere
de la colaboración entre un equipo interfuncional de progra-
madores de aplicaciones, el personal de operaciones, los
auditores y las personas del negocio cuyo enfoque sea los ser-
vicios punto a punto. Es importante destacar que cada grupo
tiene un rol específico a desempeñar y que estos roles deben
estar definidos en los procedimientos de gestión del cambio.5
Los auditores internos son expertos en dibujar diagramas
de flujo de los procesos del negocio y en evaluar los contro-
les. Están en la mejor posición para ayudar a sus organizacio-
nes a ver los beneficios de mirar los procesos clave desde una
perspectiva global.
El departamento de TI debe tener la capacidad de eva-
luar e informar el estado de todos los cambios en todo
momento. Los procesos de gestión del cambio eficaz propor-
cionan la información y el aseguramiento necesarios para
realizar el seguimiento de todos los cambios en sus diversos
estados de consumación.
Por último, las metas para administrar mejor los cambios
de TI de una organización son reducir el riesgo (aquel prima-
riamente asociado a la incapacidad de ejecutar las funciones
del negocio a causa de la inactividad por una falla), reducir el
trabajo no planeado (en consecuencia, se liberan recursos res-
tringidos), eliminar resultados no deseados (ocasionados por
errores u omisiones) y mejorar la calidad del servicio para
todos los clientes internos y externos.
 GTAG — ¿Por qué debo interesarme en cómo
la organización gestiona el cambio? — 3
3.3 ¿Cómo puede ayudar un proceso robusto
de gestión del cambio?
Las solicitudes del cambio surgen como respuesta a un deseo
de obtener beneficios para el negocio, como reducir costos o
mejorar los servicios, o a partir de la necesidad de corregir
problemas. La meta del proceso de gestión del cambio es sos-
tener y mejorar las operaciones organizacionales. Esto se logra
asegurando que se utilicen métodos y procedimientos estan-
darizados para el manejo eficaz y eficiente de todos los cam-
bios y minimizando el impacto de los incidentes relacionados
con el cambio sobre la calidad y la disponibilidad.
Para proteger el entorno de producción, los cambios se
deben administrar de manera repetible, definida y predecible.
Se debe prestar especial atención para asegurarse de que los
cambios realizados para corregir una aplicación, servidor o dis-
positivo de red no introduzcan problemas no deseados. Esto es
particularmente importante en el caso de los activos de TI
(software, hardware, información) que respaldan los procesos y
los repositorios de datos críticos del negocio de la empresa.
Los procesos de gestión del cambio sólidos ayudan tam-
bién a que la organización pueda sostener el cumplimiento
permanente con las nuevas y amplias regulaciones. Las acti-
vidades que abordan el impacto potencial de los cambios en
el cumplimiento regulatorio deben incluirse dentro de los
pasos de aprobación del proceso de cambio para la unidad de
negocios y la gestión del riesgo. Por ejemplo, se debe prestar
atención cuando se implementan cambios en la tecnología
que respalda el proceso de preparación de reportes financie-
ros para asegurar el cumplimiento constante con la Ley
Sarbanes-Oxley. De la misma manera, puede ocurrir que los
cambios en el manejo de la información de identificación
personal en Europa hagan que se incumplan las directivas de
privacidad de la Unión Europea.
Los procesos de gestión del cambio eficaz se deben docu-
mentar para reducir el esfuerzo constante necesario para tra-
zar el mapa, validar y certificar los cambios en el proceso de
preparación de reportes para respaldar el cumplimiento con la
Ley Sarbanes-Oxley. En el Artículo 404 de la Ley, se exige
que la gerencia valide y evalúe los controles sobre los proce-
sos de preparación de reportes, incluidos los controles de TI.
Los cambios sin control en el entorno de producción pueden
conducir a errores que, si son generalizados o críticos, se
podrán considerar como deficiencias importantes que se
deben reportar al comité de auditoría. Se requiere que las
deficiencias más serias denominadas “debilidades materiales”
en el mundo del contador público, sean divulgadas pública-
mente por las empresas a través de presentaciones ante la
Comisión de Valores de EE. UU. (SEC). Las revelaciones
públicas de las deficiencias pueden afectar la reputación, el
precio de las acciones y la capacidad de la organización para
permanecer en el negocio.
El Artículo 404 de la Ley Sarbanes-Oxley requiere que la
gerencia valide los controles de TI. Los cambios sin control
en el entorno de producción pueden conducir a deficiencias y
debilidades materiales serias.
6
Extraído de “Enterprise Risk Management-Integrated Framework” de COSO, septiembre 2004. El resumen ejecutivo está disponible en
http://www.coso.org/publications/erm/coso_erm_executivesummary.pdf.
11
En el documento guía, Enfoque para evaluar excepciones y
deficiencias de control [BDO 04], las deficiencias observadas
en los controles informáticos en general, como la gestión del
cambio, se deben evaluar en relación con su efecto sobre los
controles de aplicación. En particular, la debilidad del control
general de TI (en inglés, ITGC) se clasifica como una “debi-
lidad material” si ocurre uno o más de los siguientes:
• Una debilidad de control de aplicación causada por una
debilidad de ITGC, o relacionada con esta, se clasifica
como una debilidad material.
• La generalización y la importancia de una debilidad de
ITGC conduce a la conclusión de que hay una debili-
dad material en el entorno de control de la organiza-
ción.
• Una debilidad ITGC clasificada como deficiencia sig-
nificativa permanece sin corregirse después de un perí-
odo razonable de tiempo.
El año pasado, muchas organizaciones observaron serias defi-
ciencias asociadas con la gestión del cambio de los controles
generales de TI que rodean un sector del entorno de prepara-
ción de reportes financieros. Si esto sigue sin corregirse en el
presente año, estas organizaciones estarán en riesgo. Los audi-
tores internos pueden ayudar a la gerencia identificando estos
problemas y colaborando para que ella se asegure de que estos
sean corregidos de manera oportuna.
Un modelo de aceptación general para evaluar los con-
troles internos es el titulado Control interno - Marco integrado,
publicado por el Comité de Organizaciones Patrocinadoras de
la Comisión Treadway - (COSO) en el año 1992. En 2004,
este modelo fue mejorado para proporcionar un marco de ges-
tión de riesgo empresarial aceptado, que incluya principios
clave, conceptos, un lenguaje común respecto a riesgos y una
guía clara para la implementación. Esta nueva orientación
titulada Gestión de Riesgo Empresarial - Marco Integrado
[COSO 04], proporciona cuatro categorías de objetivos orga-
nizacionales y ocho componentes interrelacionados de ges-
tión de riesgo eficaz. En la Figura 16 (página 12) se incluye
una ilustración de cómo se puede aplicar el modelo COSO a
la gestión del cambio.
La organizaciones de alto rendimiento generalmente tie-
nen una visión positiva de los controles. El caso concreto es
que los procesos eficaces de gestión del cambio reducen el
riesgo de convertirse en una organización de bajo rendimien-
to y provocan menos problemas que, a su turno, deban ser
resaltados por el contador público externo (auditor de cuen-
tas), el organismo de control equivalente o la autoridad revi-
sora. Como resultado, la empresa tiene un Comité de
Auditoría más satisfecho y se reduce la presión sobre la geren-
cia del departamento de TI. Por lo general, un Comité de
Auditoría satisfecho trae aparejado que todos estén más feli-
ces, el máximo ejecutivo (CEO), el director financiero
(CFO), el DTI y el DEA. Por último, las organizaciones que
tratan los controles de gestión del cambio como posibilitado-
res de conducta comercial eficaz son más exitosas. El punto
clave a recordar es que la gestión del cambio se centra en el
proceso con un enfoque administrador y humano que está res-
paldado por controles técnicos y automáticos.
GTAG — ¿Por qué debo interesarme en cómo
la organización gestiona el cambio? — 3
Figura 1: Modelo COSO ERM para la gestión del cambio
MONITORIZACIÓN
INFORMACIÓN Y COMUNICACIÓN
ACTIVIDADES DE CONTROL
RESPUESTA AL RIESGO
EVALUACIÓN DE RIESGO
IDENTIFICACIÓN DEL EVENTO
DETERMINACIÓN DE OBJETIVOS
ENTORNO INTERNO
Monitorización
• Mediciones de desempeño y análisis de cambio
mensuales proporcionados al Director de TI
(CIO).
• Auditorías del proceso de gestión del cambio rea-
lizadas por la auditoría interna.
• Autoevaluación de control anual (en inglés,
CSA) realizada por las unidades de negocio y el
Departamento de TI.
• Informes periódicos de la dirección de gestión del
cambio proporcionados a la alta dirección.
Información y comunicación
• Mensajes periódicos de la alta dirección con res-
pecto a que el control del cambio es importante.
• Se comunican los problemas con la mesa de ser-
vicio para su resolución y análisis de tendencias.
• Se comunican los cambios en la política a todo el
personal que se ve afectado por ellos.
• Comunicación regular de los cambios próximos a
realizarse.
Actividades de control
• Proceso ordinario implementado y documentado.
• Estructura del comité de control del cambio eficaz
• Se utilizan registros de control del cambio.
• Se mantiene una separación de las funciones de
los programadores y del personal técnico.
• Controles automáticos para hacer cumplir el pro-
ceso de promover los cambios en la producción.
• Proceso automático para volver el entorno de
producción a su estado anterior al cambio.
• Se documentan las configuraciones aprobadas.
• Se documenta la clara delegación de autoridad.
• Se documentan las aprobaciones de los cambios.
• Sistema automático y copias de seguridad de
datos junto a la capacidad de restaurar desde el
entorno aprobado.
Evaluación de riego
• Las evaluaciones del riesgo a nivel de proceso y
estrategia de la empresa tienen en consideración
los riesgos asociados con los cambios fuera de
12
proceso (no deseados o no autorizados).
• El personal de TI comprende cabalmente los ries-
gos provocados por el cambio.
• Se realiza una evaluación completa del riesgo de
todos los cambios propuestos.
• Planificación de la continuidad de negocio
implementada.
• Se realiza la evaluación de auditoría interna.
• El seguro del negocio necesita que se realice una
evaluación.
• Se evalúan los factores de riesgo para determinar
la clasificación del cambio y el nivel de pruebas y
aprobación.
Determinación de objetivos e identificación del
evento
• La gerencia establece los objetivos y estrategias
del negocio.
• La gerencia establece los objetivos para la gestión
del cambio, identifica qué eventos pueden impe-
dir el logro de los objetivos del negocio y la debi-
da observación del proceso de cambio.
Entorno interno
• La alta dirección demuestra que la gestión del
cambio es importante.
• Presencia de una cultura de gestión del cambio
eficaz.
• No hay ninguna tolerancia para los cambios fuera
de proceso, está implementado el proceso de
renuncia.
• Existe la documentación pertinente (políticas, pro-
cedimientos, proceso de gestión de cambios para
aplicaciones, bases de datos, sistemas operativos y
cualquier otro activo de TI).
• Se proporciona capacitación sobre el proceso a
todo el personal afectado por el cambio.
• Se aplican las responsabilidades y los roles definidos.
• Están implementados los acuerdos de niveles de
servicio (en inglés, SLA) y contratos con provee-
dores donde se definen los estándares de proceso
y rendimiento.
• Están implementados los estándares y pautas a
nivel de la empresa para el proceso del cambio.
 GTAG — Definir la gestión de cambio de TI — 4
En la mayoría de las empresas, el departamento de TI tiene
dos roles principales: 1) operar y mantener los servicios y
compromisos existentes y 2) entregar los nuevos productos
y/o servicios para ayudar a alcanzar los objetivos del negocio.
Esta parte describe el alcance de la gestión del cambio en res-
paldo a estos dos roles, las características de gestión del cam-
bio eficaz e ineficaz, el rol de la auditoría en la gestión del
cambio y las mediciones que pueden contribuir para admi-
nistrar el cambio con eficacia..
4.1 ¿Cuál es el alcance de la gestión del cambio?
Esta guía se centra en la gestión del cambio operacional de
TI que se inicia cuando se identifican actualizaciones o
mejoras en los activos de TI (infraestructura, aplicaciones)
para su pase a producción (por ejemplo, desde un equipo de
desarrollo de aplicaciones o desde un equipo de investiga-
ción y desarrollo) y finaliza cuando tales activos se retiran
del entorno de producción. Esto incluye los controles de
mantenimiento de la aplicación y del cambio de emergencia.
Se excluyen específicamente los cambios que se presentan
durante el diseño y desarrollo del software.
El término gestión del cambio, tal como se utiliza en la
guía, excluye el proceso de gestión de configuración. La ges-
tión de configuración tiene que ver con identificar, contro-
lar, mantener y verificar las versiones de todos los
componentes de TI (hardware, software, documentación
relacionada) [ITIL 00]. Sin embargo, el proceso de gestión
del cambio debe interactuar con el proceso de gestión de
configuración (y controles relacionados) cuando se efectúan
cambios en las configuraciones.
4.1.1 Fuentes de cambio
Prácticamente, todas las decisiones comerciales requieren
cambios de TI. Los siguientes factores sirven como fuentes
de cambio que se deben abordar y administrar con eficacia
en el entorno de TI:
• Entorno externo (mercado competitivo, partes intere-
sadas/accionistas, riesgos cambiantes).
• Entorno regulatorio.
• Objetivos del negocio, metas, estrategias, requerimien-
tos, procesos y cambios de prioridades.
• Proveedores (nuevos productos, actualizaciones, par-
ches y vulnerabilidades).
• Socios y proveedores.
• Resultados de una auditoría, evaluación de riesgo y
otros tipos de evaluación y valoración.
• Problemas operacionales.
• Cambios en requerimientos de rendimiento o
capacidad.
4.1.2 Alcance de los cambios
Un proceso de gestión de cambio eficaz abarca dentro de su
alcance todas y cada una de las modificaciones que se reali-
cen a los activos basados en TI de los que dependen los ser-
vicios del negocio. Entre los activos sujetos a la gestión del
cambio se incluyen:
• Hardware: computadoras centrales, servidores, estacio-
nes de trabajo, ruteadores, conmutadores y dispositivos
móviles.
13
• Software: sistemas operativos y aplicaciones.
• Información, datos y estructuras de datos: archivos y
bases de datos.
• Controles de seguridad: software antivirus, filtros de
seguridad y sistemas de detección/protección contra
intrusiones.
• Procesos, políticas y procedimientos.
• Roles/responsabilidades: autorización, autoridad para
actuar y controles de acceso.
4.1.3 Proceso de gestión del cambio
Habitualmente, un proceso de gestión del cambio incluye las
siguientes actividades:
• Identificar la necesidad del cambio.
• Prepararse para el cambio.
– Documentar en detalle la solicitud del cambio.
– Documentar el plan de prueba del cambio.
– Documentar el plan para deshacer el cambio en
caso de fallo del cambio.
– Escribir un procedimiento paso a paso que incorpore
el cambio, el plan de prueba y el plan para deshacer
el cambio.
– Presentar el procedimiento del cambio en forma de
solicitud de cambio.
• Desarrollar la justificación comercial y obtener las
aprobaciones.
– Evaluar el impacto, el costo y los beneficios
relacionados con la solicitud del cambio.
– Revisar y evaluar los riesgos e impactos de la
solicitud del cambio, incluidos impactos regulatorios.
• Autorizar la solicitud del cambio.
– Autorizar, rechazar o solicitar información adicional
acerca de la solicitud del cambio.
– Priorizar la solicitud del cambio con respecto a otras
que estén pendientes.
• Programar, coordinar e implementar el cambio.
– Programar y asignar un implementador del cambio.
– Programar y asignar un evaluador del cambio.
– Probar el cambio en un entorno de preproducción.
– Comunicar el cambio a las partes interesadas que
probablemente se vean afectadas.
– Aprobar el cambio para la implementación.
– Implementar el cambio según se solicitó.
• Verificar y revisar el cambio implementado (un paso
crítico que con frecuencia se omite).
– ¿Fue el cambio exitoso?
– ¿Se realizo un seguimiento sobre el proceso del
cambio?
– ¿Cuál fue la variación entre el cambio que se planeó
y el que se implementó?
– ¿Se mantuvieron los requerimientos de control
interno, operaciones y cumplimiento regulatorio?
– ¿Cuáles fueron las lecciones aprendidas que se
pueden utilizar para mejorar el proceso?
• Retirar el cambio si no tuvo éxito.
• Cerrar la solicitud del cambio y comunicarlo a las par-
tes afectadas.
• Efectúe los cambios acordados en el proceso de gestión
del cambio.
GTAG — Definir la gestión de cambio de TI — 4
Los auditores de inmediato reconocerán que la gestión del
cambio eficaz exige controles preventivos, de detección y
corrección, y que la necesidad de controles independientes
aumenta a medida que el entorno de producción de TI se
torna más dinámico y complejo. Entre los controles preven-
tivos necesarios se incluyen la separación de roles, la autori-
zación del cambio, su supervisión y aplicación. Si embargo,
para monitorear y aplicar el proceso con eficacia, se deben
adoptar controles de detección para supervisar el entorno de
producción en relación a los cambios, conciliar estos cam-
bios como cambios aprobados e informar las variaciones no
autorizadas. La gestión del cambio eficaz también cumple un
rol correctivo para la gestión de TI durante las interrupcio-
nes y restricciones de servicio, lo cual permite que se descar-
te el cambio en primer lugar en el ciclo de reparaciones, y
por consiguiente se reduzca el tiempo de reparación.
4.2 ¿Cuál es el aspecto de la gestión del cambio
ineficaz?
¿Cómo sabe usted si una organización tiene un proceso de ges-
tión del cambio eficaz o ineficaz? ¿Qué conductas y qué otras
señales sirven como indicadores útiles de la capacidad de la
organización o bien de su falta de capacidad al respecto?
Los indicadores de una gestión del cambio ausente o ine-
ficaz aparecen como disfunciones en una variedad de dimen-
siones organizacionales.
A nivel de mercado:
• Oportunidades perdidas. La empresa no puede imple-
mentar los nuevos servicios y productos planeados de
manera consistente. Esto ocurre cuando se tienen que
comprometer recursos para afrontar trabajos no planea-
dos, como consecuencia de cambios no administrados.
El trabajo no planeado se puede manifestar como tiem-
po perdido/no presupuestado, recursos perdidos/no pre-
supuestados (personal, capital) y como trabajo no
presupuestado.
• Los proyectos de desarrollo se retrasan y a menudo se
exceden del presupuesto establecido, esto da como
resultado productos y servicios con demoras y más cos-
tosos en comparación con la competencia.
A nivel de clientes/partes interesadas:
• Los productos y servicios no funcionan como se anun-
cia o se espera, o bien, operan con fallos. Esto condu-
ce a un producto o servicio no confiable de baja
calidad. Si los clientes pueden cambiar de proveedor
fácilmente, lo harán.
A nivel de la organización:
• Los cambios no autorizados, no rastreados, crean una
potencial exposición al fraude.
• Los requerimientos del negocio se pueden malinterpre-
tar en relación con los cambios de TI que se requieren
e implementarse de manera deficiente e inadecuada.
• La organización tiene muy poca capacidad, o directa-
mente ninguna, para pronosticar el impacto de un cam-
bio sobre los procesos comerciales existentes.
• Dado que es poco probable que los cambios sean eva-
luados en relación unos con otros, no se fijan priorida-
des de cambio, lo que da como resultado que se trabaje
sobre los elementos equivocados o se trabaje sobre algo
que es menos importante. Es probable que se realice el
14
trabajo fuera de la secuencia pensada con el riesgo de
reprocesos y duplicación de esfuerzos.
• Es evidente un alto grado de problemas, reflejado en
una actitud de tipo “siempre nos pasa todo a nosotros”
o “se pierde mucha energía en el sistema”, además no
hay capacidad para controlar el entorno operacional.
• Los sistema de parches ocasionan importantes inte-
rrupciones ocasionadas por fallos de los cambios que a
su vez dan como resultado cortes, deterioro del servi-
cio, reprocesos o trabajos no planeados. Esto a menu-
do exacerba una relación de trabajo negativa o adversa
entre el sector de seguridad de la información y el de
operaciones de TI.
• Grandes cantidades de los ciclos de tiempo, recursos y
capital, se emplean para corregir actividades o infraes-
tructuras no autorizadas del proyecto y se quita a los
ciclos de las actividades planeadas y autorizadas.
• Los recursos regularmente se desvían a reprocesos,
como resultado de la necesidad de afrontar las conse-
cuencias no deseadas de cambios no administrados.
• Se observa una alta rotación del personal técnico y
evidencias claras de “desgaste” en el personal clave.
A nivel de infraestructura de TI:
• El comportamiento ad hoc, caótico y urgente requiere
de la intervención de los expertos/héroes técnicos; un
alto porcentaje del tiempo se emplea en modo de
“situación de emergencia” en tareas reactivas.
• Incapacidad para rastrear cambios, informar sobre el
estado y los costos del cambio y presencia de cambios
no autorizados.
• Aumento de los recursos que se emplean para afrontar
trabajos no planeados, a expensas del trabajo planea-
do. Esto se puede describir como un bajo porcentaje de
éxito del cambio. La tasa de éxito del cambio es una
medida de la cantidad de trabajo nuevo que se intro-
duce cuando se implementa un cambio. Una tasa de
éxito del cambio alta significa que el cambio se ha
implementado según lo planeado y que no se ha intro-
ducido trabajo adicional como resultado del cambio.
En oposición, una tasa de éxito del cambio baja impli-
ca que un cambio inesperadamente introduce trabajo
no planeado adicional, a veces, por encima del trabajo
requerido para implementar el cambio original. Una
tasa de éxito del cambio baja puede producir una espi-
ral descendente que consume recursos excesiva y con-
tinuamente.
• Una TI ineficaz interactúa con sus iguales
(Investigación y Desarrollo, programadores de aplica-
ciones, auditorías, seguridad, operaciones) que gene-
ran barreras e introducen demoras innecesarias.
• Una cantidad numerosa de cambios no documentados
que se suceden a través del tiempo aumenta la varia-
ción de producción de configuración dando como
resultado tasas de éxito del cambio bajas y aumentan-
do la dificultad de implementar parches sin que ocu-
rran fallos de cambios ni trabajo no planeado.
 GTAG — Definir la gestión de cambio de TI — 4
4.3 ¿Cuál es el aspecto de la gestión del cambio
eficaz?
¿De qué manera puede reconocer una gestión de cambio efi-
caz al verla? ¿Puede entrar a una organización y determinar
en 15 minutos si el proceso de gestión de cambio es eficaz?
Los indicadores de una gestión de cambio eficaz apare-
cen como una capacidad madura (predecible, repetible,
administrada, mensurable, medida) en una variedad de
dimensiones organizacionales.
A nivel de mercado:
• La empresa está en posición de actuar en nuevas opor-
tunidades de negocios que requieren una capacidad de
TI adicional o actualizada. Cada oportunidad se planea
y administra de una manera predecible. Los recursos
adecuados se pueden comprometer con la seguridad de
que son suficientes, y de que están basados en un ren-
dimiento histórico rastreado.
• Los productos y servicios respaldados por la TI se lan-
zan al mercado según lo planeado y esperado.
A nivel de clientes/partes interesadas:
• Los productos y servicios funcionan tal como se anun-
ció y muestran un nivel de calidad de servicio y pro-
ducto confiable y uniforme. Los problemas y reclamos
de los clientes se tratan de manera oportuna. Los clien-
tes por lo general se sienten satisfechos y son leales a la
organización.
• Hay una disminución de la demanda de recursos que
ofrecen los centros de asistencia/mesa ayuda al cliente.
• Las partes interesadas apropiadas están involucradas
en la evaluación de los riesgos asociados a los cambios
propuestos y priorizan su implementación.
• Los participantes del proceso de cambio comprenden
las categorías y prioridades relevantes de los cambios y
los niveles de rigor y formalidad requeridos para imple-
mentar cada uno de ellos.
• Hay una postura de cumplimiento debido a la naturale-
za básica de la administración del cambio.
Prácticamente, toda regulación tiene requerimientos de
TI y como resultado, puede crear un nuevo proyecto
para los equipos de cumplimiento y seguridad. Cuando
los controles están bien documentados, el cumplimien-
to con una nueva regulación no es un proyecto nuevo,
sino simplemente una actividad de mapeo.
A nivel de empresa:
• La cultura de la gestión del cambio se hace evidente en
el entendimiento, la conciencia, el patrocinio visible y
la acción.
• Regularmente, se realizan compensaciones eficaces
que equilibran el riesgo y el costo del cambio en rela-
ción a la oportunidad. Los cambios se programan y
priorizan en consecuencia. Existe una capacidad para
predecir el impacto del cambio en el negocio. Según
BITS [BITS 04]:
Con frecuencia, determinar el grado de aceptación de
riesgo de una empresa es el paso más difícil en la imple-
mentación de una estrategia de gestión del cambio. Las
personas que tienen a su cargo la responsabilidad del
proceso de gestión del cambio deben entender el grado de
tolerancia al riesgo de su organización con respecto a la
instalación de parches, a la vez que deben ayudar a
15
identificar dichos parches y distribuirlos en la organiza-
ción utilizando la calificación de severidad de la organi-
zación como guía.
• Los recursos (tiempo, esfuerzos, dólares, capital) se
aplican para implementar los cambios seleccionados
con poco esfuerzo desperdiciado o casi ninguno (alta
tasa de éxito del cambio); los recursos raramente se
desvían al trabajo no planeado.
• La organización puede responder con seguridad a las
preguntas: “¿Estoy haciendo las cosas correctas?”
(capacidad para seleccionar y dar prioridades) y
“¿Estoy haciendo las cosas correctamente?” (con una
calidad y un desempeño aceptables).
• Un proceso de gestión del cambio eficaz se evidencia
por la aplicación/adherencia y disciplina de un proce-
so riguroso, en la capacidad de tomar decisiones de
manera centralizada y en la colaboración y comunica-
ción entre los departamentos.
• Se trazan mapas de los proyectos autorizados según las
órdenes de trabajo y viceversa.
• Las inversiones para cumplimiento y seguridad se sos-
tienen porque las configuraciones de producción no se
desvían a estados no seguros y de incumplimiento. En
consecuencia, el costo de seguridad y cumplimiento es
mucho más bajo.
• Progresivamente, se destinan más tiempo y más recur-
sos a problemas de TI estratégicos dado que la organi-
zación ya tiene bajo control sus inquietudes tácticas
(operacionales del día a día).
• La gestión del cambio eficaz sirve como control esen-
cial del gobierno de TI.
A nivel de infraestructura de TI:
• Los controles de gestión del cambio (incorporados en los
procesos operacionales de TI bien definidos) se utilizan
para ayudar a garantizar la uniformidad y predecibilidad
necesarias para lograr las metas del negocio que a su turno
confían en estos procesos. En otras palabras, el personal
de TI entiende cómo la gestión del cambio eficaz respal-
da la tarea de cumplir con los objetivos comerciales.
• Una cultura de gestión del cambio se perpetúa a través
de una combinación de matices en los niveles más altos
y de controles preventivos, de detección y corrección,
que sirven para impedir futuros cambios no autorizados.
La gerencia explícitamente establece que el único
número aceptable de cambios no autorizados es “cero”.
• Presenta una tasa de éxito del cambio alta, lo que da
como resultado la ausencia de trabajo no planeado o si
existe, en una cantidad al menos mínima. La ausencia
de urgencias y la existencia de un proceso bien defini-
do para integrar los cambios conduce a una tasa de
éxito del cambio mucho más alta.
• Los controles del cambio eficaz se han implementado,
se informan con regularidad y se auditan con facilidad.
Los controles preventivos están bien documentados y
se ejecutan de manera consistente, los controles de
detección se utilizan para supervisar, vigilar y conciliar
los cambios según las órdenes de cambio autorizado.
Los controles son favorables para el muestreo sustanti-
vo de los auditores y se requiere poca o casi ninguna
información adicional de la gerencia de TI.
GTAG — Definir la gestión de cambio de TI — 4
• La variaciones en las configuraciones de producción se
detectan con anticipación de manera de incurrir en el
mínimo costo posible y provocar el mínimo impacto.
• La empresa regularmente demuestra la excelencia ope-
racional con respecto a la gestión del cambio.
• Los niveles altos de servicio (alto grado de disponibili-
dad,tiempo productivo y tiempo medio entre fallos;
bajo grado de tiempo medio para detectar problemas e
incidentes y para las reparaciones) tienen lugar en pre-
sencia de procesos bien definidos que introducen cam-
bios planeados y predecibles.
• Cuando surgen problemas con un nuevo cambio o
configuración, TI tiene la capacidad de restablecer
rápidamente los sistemas al estado operacional confia-
ble y conocido.
• TI ostenta estructuras de costo inusualmente eficientes
(una proporción de servidores con respecto a adminis-
tradores de sistema de 100:1, o incluso un valor más
alto, en comparación con el correspondiente a las
organizaciones de bajo rendimiento, con una cifra,
como mínimo, inferior en una orden de magnitud).
• Resolución e identificación oportuna de los problemas
operacionales, incluidos los incidentes de seguridad.
• La organizaciones que poseen procesos de gestión del
cambio eficaz y controles al respecto afrontan los par-
ches de una manera predecible y planeada, que está
sujeta a los mismos procesos y análisis que cualquier
otro cambio. Los parches se agregan a la cola “candi-
dato de ingeniería de liberación”, donde se evalúan,
se prueban y se integran a una implementación de
liberación ya programada.
• Los controles preventivos y de detección son automá-
ticos y permiten la preparación de informes más
exactos y sencillos para los auditores, requieren menor
Cuadro 1: Mediciones de la gestión del cambio7
Mediciones e indicadores
Cantidad de cambios autorizados por semana según
medición del registro de la gestión de cambio de los cambios
autorizados.
Cantidad de cambios reales efectuados por semana según
medición por parte de los controles de detección, como
monitorización de software.
Cantidad de cambios no autorizados.
Estos son cambios que soslayan el proceso del cambio. Se
miden tomando la cantidad de cambios reales efectuados
menos la cantidad de cambios autorizados.
Si no se tienen controles de detección, no se puede realizar
ninguna medición confiable de los cambios reales. En tal caso,
la cantidad de interrupciones no planeadas se puede utilizar
como medición sustituta.
7
En el Apéndice A, página 32, se incluyen más definiciones sobre estas mediciones e indicadores.
8
Comparación (benchmarking) realizada por el Instituto de Procesos de TI (IPTI).
16
cantidad de inspecciones manuales y muestreos sustan-
tivos que se asemejan a los de “arqueología”.
• Las organizaciones más eficaces aplican parches con
menor frecuencia que la norma, tal vez en una propor-
ción de un orden de magnitud, aceptan que el riesgo de
la exposición a la vulnerabilidad puede ser menor que
el riesgo a la disponibilidad debido a los impactos no
anticipados ocasionados por un cambio erróneo fuera
de ciclo. Sin embargo, en el caso de una actualización
crítica, las organizaciones capaces pueden implemen-
tar un parche fuera de ciclo con un riesgo mínimo.
Para tener un proceso eficaz, las partes interesadas no parti-
cipan únicamente en la evaluación de los riesgos relaciona-
dos con los cambios propuestos y en el establecimiento de
prioridades para la implementación del cambio. Una de las
barreras que con frecuencia deben afrontar los departamen-
tos de TI cuando tratan de desarrollar un proceso de gestión
del cambio robusto es la falta de interés, compromiso y
patrocinio de sus contrapartes del negocio. Los gerentes de
unidades de negocio deben involucrarse activamente en
todo el proceso, desde la identificación inicial de sus necesi-
dades hasta la realización de la mayoría de las pruebas de
aceptación por parte del usuario, e incluso la aprobación de
los cambios que se incorporarán en producción. Estos puntos
de contacto críticos tienen más probabilidades de ocurrir
cuando el rol del gerente de negocio está incluido en las polí-
ticas y procedimientos relevantes, y los gerentes de rango
superior ponen el énfasis apropiado en el hecho de ser copro-
pietarios del proceso antes que meros observadores. La
comunicación y colaboración entre TI y las unidades de
negocio son críticas para lograr un proceso eficaz.
Pautas
En general, una mayor cantidad de cambios indica más cam-
bios de productividad, siempre que la tasa de éxito del cam-
bio sea alta. La tendencia (ascendente, descendente o
estable) debe tener sentido en el contexto del negocio.
Las organizaciones de alto rendimiento pueden sostener hasta
más de 1.000 cambios exitosos por semana.8
La cantidad de cambios realmente implementados en la
semana no debe exceder la cantidad de cambios autorizados.
Cuanto más bajo su valor, mejor, pero por lo general, el único
número aceptable de cambios no autorizados es “cero”, un
cambio aislado puede destruir una operación completa o
crear un riesgo material.
Una gran cantidad de cambios no autorizados indica que “la
verdadera forma de hacer cambios” es mediante la omisión
del proceso de gestión de cambios.
Las organizaciones de alto rendimiento tienen una cultura de
gestión del cambio y, por consiguiente, declaran que no tole-
ran ningún cambio no autorizado [Kim 03].
 GTAG — Definir la gestión de cambio de TI — 4
Cuadro 1: Mediciones de la Gestión del Cambio (continuación)
La tasa de éxito del cambio, definida como los cambios
implementados con éxito (esos que no ocasionaron interrup-
ciones, deterioros de servicios o un episodio de trabajo no
planeado), como porcentaje de los cambios reales realizados.
Cantidad de cambios de emergencia (incluidos parches) deter-
minada por la cantidad de cambios que requirieron de la apro-
bación urgente en la semana mediante el uso de la comisión
de revisión del cambio o el proceso de cambio de emergencia.
Porcentaje de parches implementados en las versiones de
software planeadas. Cuando los parches se implementan en
versiones de software planeadas, no provocan interrupcio-
nes en producción y tienen tasas de éxito del cambio mucho
más altas.
Porcentaje de tiempo empleado en trabajo no planeado. El
trabajo planeado es tiempo que se emplea en proyectos y
tareas autorizadas. El trabajo no planeado incluye ciclos de
cortes/correcciones, reprocesos y cambios de emergencia..
Porcentaje de proyectos entregados más tarde de lo
planeado.
17
Cuanto más alta, mejor. Cuando los cambios no se adminis-
tran ni se realizan las pruebas adecuadas sobre ellos, las tasas
de éxito del cambio, por lo general, están en un valor del
70%.
Las organizaciones de TI de alto rendimiento no sólo alcanzan
tasas de éxito del orden del 99% con regularidad, sino que los
cambios fallidos rara vez provocan interrupciones del servicio
o trabajos no planeados.
Cuanto más bajo, por lo general, es mejor. La presencia de
muchos cambios de emergencia indica que la “verdadera
forma de hacer cambios” es mediante el uso del proceso de
cambios de emergencia, sea por comodidad o rapidez.
Los cambios de emergencia, generalmente, tienen un porcen-
taje de fallos más alto y generan trabajos no planeados o
reprocesos. Un aumento en los cambios de emergencia pro-
bablemente indique que hay otros problemas de gestión de
cambios que está ocasionando tal incremento.
Las comparaciones del IPTI detectaron que cuando los
cambios de emergencia representan más del 10% del total
de cambios, la organización, casi con certeza, es de bajo ren-
dimiento. Concretamente, dos organizaciones que tuvieron
fallos de TI que ocuparon la primera plana de las noticias
estaban efectuando de urgencia más del 25% de sus solicitu-
des de cambios.
Cuanto más alta, por lo general, mejor.
Paradójicamente, la organizaciones de TI de alto rendimiento
con frecuencia tienen una tasa de implementación de parches
muy baja. Durante las sesiones de BIC SORT, dos de las organi-
zaciones de alto rendimiento afirmaron que ellos optaban por
implementar parches con una frecuencia anual, a pesar de efec-
tuar miles de cambios por semana. Con frecuencia, mitigan los
riesgos de vulnerabilidad sin requerir cambios en los sistemas
de producción (por ejemplo, eliminando la vulnerabilidad en un
filtro de seguridad).
Cuanto menos mejor.
De acuerdo a las 11 organizaciones de IT de alto rendimiento
que estudió el IPTI todas empleaban menos del 5% de su
tiempo en trabajos no planeados. Por el contrario, centenares
de organizaciones empleaban del 30% al 40% de su tiempo
en trabajos no planeados.
Cuanto más bajo, por lo general, es mejor. Cuando las organi-
zaciones emplean todo su tiempo en trabajos no planeados,
a menudo no disponen del tiempo suficiente para trabajar en
los trabajos planeados, como por ejemplo, en los nuevos
proyectos y servicios. Por consiguiente, eso hace que los pro-
yectos se entreguen con retrasos.
 GTAG — Definir la gestión de cambio de TI — 4

=
Figura 2: Trabajo no planeado como indicador de proceso de gestión del cambio eficaz

X X
Porcentaje de cambios Tiempo medio Porcentaje del tiempo
Cantidad de
fallidos o cambios no para empleado en trabajos no
cambios en producción
autorizados reparaciones planeados

Organizaciones de alto >1000 cambs/sem < 1% Minutes < 5% del tiempo

rendimiento

Organización No se conoce, ~30 - 50% Horas, Días 35 - 45% del

promedio centenares (Promedio) tiempo

ORGANIZACIÓN PROMEDIO: 35 - 45% del tiempo (y los gastos operacionales) se emplean en trabajos no planeados.
IMPACTO: proyectos demorados, reprocesos, problemas de cumplimiento, variaciones no controladas, etc.

X X =
Figura 3: Variables clave que influyen sobre los procesos de gestión del cambio

Cantidad de Porcentaje de cambios Tiempo medio Porcentaje del tiempo

cambios en fallidos o cambios no para empleado en trabajos
producción autorizados reparaciones no planeados
COMPORTAMIENTOS QUE AUMENTAN LA TASA DE ÉXITO DEL CAMBIO: COMPORTAMIENTOS QUE DISMINUYEN EL
• Pruebas eficaces de los cambios. TIEMPO PROMEDIO DE REPARACIÓN:
• Revisión de riesgo eficaz al aprobar los cambios. • Cultura de contingencias: se desea descartar el cambio
• Identificación eficaz de los participantes del cambio. en primer lugar en el ciclo de reparaciones.
• Programación eficaz de cambios. • Proceso de gestión del cambio eficaz que puede
COMPORTAMIENTOS QUE REDUCEN LOS CAMBIOS NO AUTORIZADOS: informar sobre cambios autorizados y programados.
• Cultura de gestión del cambio. • Capacidad de distinguir entre eventos de interrupción
• Sentido de propiedad del proceso del cambio por parte de la gerencia. planeados y no planeados.
• Monitorización eficaz de la infraestructura con controles de detección para poner en • Comunicaciones eficaces acerca de los cambios
práctica el proceso del cambio. programados.
• Uso de acciones correctivas por parte de la gerencia cuando no se siguen los procesos de cambio. • Monitorización eficaz de la infraestructura para
• Separación eficaz de las funciones mediante la adopción de restricciones respecto a quién puede los cambios de producción.
implementar cambios.

4.4 Mediciones e indicadores de la gestión del encuentra en un período de congelación de cambios, la

cambio
Los auditores internos deben determinar si estas mediciones
clave de gestión del cambio se están utilizando para vigilar la
eficacia del proceso e impulsar el valor de negocio. Las medi-
ciones enumeradas en el Cuadro 1 de las páginas 16 y 17 son
indicadores útiles de un proceso de gestión del cambio eficaz.
La Figuras 2 y 3 muestran los indicadores clave de la ges-
tión del cambio eficaz y los controles dominantes que los
incrementan o los disminuyen. Los indicadores clave9 son:
• Cantidad de cambios de producción.
• Porcentaje de esos cambios que fallan o no están auto-
rizados.
• Intervalo de tiempo requerido para recuperar el cam-
bio fallido.
Cuando estas tres variables se multiplican en conjunto, el
resultado es trabajo no planeado.
Este es un modelo extremadamente simple y no preten-
de ser matemáticamente correcto. Su objetivo es mostrar las
variables dominantes y los indicadores líderes para la gestión
del cambio de TI eficaz y, en consecuencia, una TI eficaz:
• Cuando una organización de TI no realiza cambios o se
disponibilidad está en su punto más alto y el trabajo no
planeado en su punto más bajo.
• Cuando una organización de TI no aplica las políticas de
gestión del cambio (por ejemplo, cuando los controles
preventivos y de detección son inadecuados), los cambios
fallidos y no autorizados ocasionan interrupciones pro-
longadas que, a su vez, generan trabajos no planeados.
• Cuando las organizaciones de TI tienen una propor-
ción alta de trabajo no planeado con respecto a traba-
jo planeado, disponen de menos tiempo para realizar el
trabajo específico de su tarea, como por ejemplo,
entregar nuevos productos y servicios.
Las organizaciones de TI de alto rendimiento se desempe-
ñarán incluso mejor que lo que sugiere este modelo. Cuando
los cambios se administran correctamente, incluso los cambios
planeados fallidos raramente ocasionan una interrupción del
servicio y, en consecuencia, el tiempo medio para reparaciones
es “cero”. Por el contrario, las organizaciones de bajo rendi-
miento a menudo no pueden medir más que las interrupciones
obvias y los trabajos no planeados.

9
Sobre la base de las comparaciones del IPTI que analizó 11 organizaciones de TI de alto rendimiento y encuestó a centenares de distintas organizaciones.

18
 GTAG — Definir la gestión de cambio de TI — 4
4.5 Integración de la Gestión de parches a la
Gestión de de cambios
A pesar de la urgencia que conlleva la aplicación de parches
de software, la implementación de parches idealmente debe
pertenecer a los procesos de preproducción, donde los par-
ches se pueden probar adecuadamente en un entorno de
puesta en escena. Estos parches se implementan como parte
de una versión de software programada.
La implementación de parches es una operación riesgo-
sa por diversas razones. Los parches tienden a afectar a
muchas bibliotecas de sistemas críticos y a otros software uti-
lizados por diversos programas de aplicación. Tienden a
introducir grandes cambios, con frecuencia, con poca docu-
mentación que describa específicamente qué es lo que dichos
parches modificarán. Además, suelen ser operaciones com-
plejas y de gran tamaño. Incluso, hasta las variaciones peque-
ñas de configuración pueden provocar resultados
drásticamente diferentes. Estos factores hacen que la tasa de
éxito del cambio para los parches sea mucho más baja que
para los cambios típicos, y por lo tanto requieren la realiza-
ción de pruebas más amplias. Cuando no se realizan las sufi-
cientes pruebas y planificación, invariablemente aparece el
dilema de “implemente el parche y cruce los dedos”.
Este fenómeno está bien documentado, se refiere al
hecho de que ni la implementación del parche ni su no
implementación parecen lograr el objetivo de crear una pla-
taforma informática segura y disponible. Tal como se descri-
bió anteriormente, las organizaciones de TI de alto
rendimiento implementan parches con mucha menor fre-
cuencia que las organizaciones de TI típicas, y aun así logran
la postura de seguridad deseada. Es incorrecto suponer que
adoptan esa decisión a costa de la seguridad. Más bien, admi-
nistran con eficacia el riesgo residual y utilizan controles
compensadores en lugar de implementar parches.
Los ejemplos de cómo se deben evaluar las solicitudes de
implementar parches en los sistemas de producción incluyen
las siguiente preguntas [ITPI 04]:
• ¿Constituye una amenaza material para nuestra capaci-
dad de entregar un servicio seguro y confiable para el
negocio?
• ¿Podemos mitigar esta amenaza sin aplicar el parche o
la actualización?
• ¿Podemos realizar una prueba del impacto de la actua-
lización y sentirnos seguros de que nuestras pruebas
servirán para predecir el resultado en nuestros sistemas
de producción?
• ¿Cuándo es el próximo ciclo de versiones? ¿Podemos
poner en el mismo paquete esta actualización con otras
actualizaciones probadas?
• Si necesariamente tenemos que hacer esto ahora,
¿cómo podemos minimizar el riesgo de consecuencias
inesperadas?
• Si no podemos reducir el riesgo de exposición median-
te pruebas y no podemos empaquetar esto con otras
versiones, ¿podemos lograr que las partes interesadas y
la gerencia de TI aprueben formalmente el riesgo?
Genere un programa de versiones que logre los objetivos
10
La información sobre este esfuerzo está disponible en http://reform.house.gov/TIPRC/News/DocumentSingle.aspx?DocumentID=3030. El informe del
Grupo del mes de noviembre de 2004 se puede consultar en http://www.educause.edu/LibraryDetailPage/666&ID=CSD3661.
19
anteriores, intente empaquetar los parches y actualizaciones
dentro de una misma versión, en lugar de aplicar parches
individuales en los sistemas individuales.
Muchas de estas mediciones también están identificadas
en el trabajo finalizado en Noviembre de 2004 y realizado por
Corporate Information Security Working Group's, Best
Practices and Metrics Team (Equipo de mediciones y mejores
prácticas del Grupo de trabajo de seguridad de la información
corporativa). Este trabajo fue contratado por el Comité de
Reformas Gubernamentales de la Cámara de Representantes
de EE. UU., Subcomité de Tecnología, Política de la informa-
ción y Relaciones Intergubernamentales y Censo.10
Por último, los riesgos relacionados con el cambio no se
restringen a la mera aplicación de los parches, sino que se pue-
den generalizar a cualquier tecnología de implementación de
cambios automática. John Gall concisamente escribió acerca
del desafío de la automatización: “El advenimiento de la revo-
lución informática simplemente proporciona nuevas oportu-
nidades de errores a niveles de complejidad y grandiosidad que
anteriormente no eran posibles”. [Gall 86]
El uso de la gestión de parches y de las tecnologías de
implementación de cambios a la vez hace que el entorno de
producción sea más complejo y dinámico: el número de vec-
tores de cambios aumenta así como el número de cambios
que se pueden realizar. Estos entornos requieren: 1) contro-
les preventivos adicionales para reducir la posibilidad de
cambios no autorizados y 2) controles de detección indepen-
dientes para simplificar las funciones de monitorización,
conciliación y preparación de informes.
4.6 Principios de guía: cómo decidir si se deben
implementar los cambios, cuándo y cómo
Los principios de guía sobre cómo tomar buenas decisiones
de gestión del cambio implican plantearse las siguientes pre-
guntas:
• ¿El cambio es realmente necesario? Las organizaciones
de TI tienen la menor cantidad de trabajos no planea-
dos y de situaciones de emergencias en los períodos de
congelación de cambios. Por consiguiente, cualquier
cambio debe garantizar no sólo los esfuerzos de prepa-
ración e implementación del cambio, sino también las
consecuencias (a menudo, imprevistas) de realizarlo.
• Cuando no hay cambios permitidos, ¿los períodos de
congelación de cambios y mantenimiento programado
están igualmente definidos? Los períodos de estado
estático no sólo son los más estables, sino también los
más productivos y, por consiguiente, se deben definir y
aplicar.
• Si necesariamente se deben efectuar cambios, ¿cómo se
asegura de que sean exitosos? Los cambios no probados
rara vez tienen una tasa de éxito superior al 70%. Las
organizaciones comprometidas con la implementación
exitosa de cambios deben invertir tiempo y recursos
para realizar las pruebas adecuadas.
• Cuando se deben implementar cambios, ¿se programan
en grandes lotes? La variación crea riesgo y este se
puede reducir mediante el empaque de varios cambios
GTAG — Definir la gestión de cambio de TI — 4

juntos que se pueden probar e implementar simultáne-

amente. Esto da como resultado períodos más prolon-
gados de estado operacional estático de preservación y
a la vez tiempos de implementación de cambios más
breves y más productivos.
• ¿Las variaciones se informan con regularidad a la geren-
cia de TI? ¿Se están conciliando los cambios de produc-
ción con trabajo autorizado? ¿Se documentan las
interrupciones no planeadas y las variaciones del cambio
y se actúa en consecuencia? ¿Los informes que muestran
el efecto de los controles preventivos y de detección son
de fácil acceso para la gerencia y los auditores? Cuando
los controles funcionan correctamente, no solamente el
proceso de auditoría de cambio funciona más eficiente-
mente, sino que también es más probable que la gerencia
de TI alcance sus objetivos comerciales.

20
GTAG — ¿Qué preguntas debo hacer sobre
la gestión de parches y cambios? — 5

En esta sección ofrecemos un conjunto de preguntas que los
auditores pueden utilizar para comprender de qué manera se
administran los cambios con eficacia. El objetivo de esta sec-
ción es proporcionar buenas preguntas y una orientación
acerca de cómo interpretar las respuestas típicas de los distin-
tos arquetipos de gerentes de TI que tienen diferentes visio-
nes acerca de la importancia de la gestión del cambio eficaz.
Los arquetipos más habituales son:
• Gerente de TI que tiene un proceso de gestión de cam-
bio eficaz.
• Gerente de TI que tiene un proceso de cambio inefi-
caz, pero que trabaja en mejorarlo (en el modo de solu-
ción de problemas).
• Gerente de TI que tiene un proceso de cambio ineficaz
y no tiene planes de cambiarlo (en estado de negación).

Cuadro 2: Preguntas a realizar sobre la gestión del cambio agrupadas por arquetipo

Preguntas al Gerente de TI Gerente de TI con gestión de Gerente de TI con un estilo Gerente de TI en posible
cambio eficaz de modo de resolución de estado de negación
problemas

“La gestión del cambio es
muy importante. ¿Usted
piensa que tenemos un
proceso de gestión de cam-
bio eficaz?”
“Los nuestros son de prime-
ra clase. Incluso, estamos
preparados para cumplir
con los requerimientos de la
Sección 404 de la Ley
Sarbanes-Oxley puesto que
todos los controles están
implementados. Hemos
tenido que generar algunos
informes más para mostrar
los mapas de los controles,
pero estamos en buenas
condiciones”.
“Es curiosa la pregunta,
estamos trabajando en eso,
al igual que todos los que
están sujetos a la Sección
404 de la Ley Sarbanes-
Oxley. Lo sabremos mejor a
medida que avancemos en
esa dirección”.
“Tenemos un proceso que
parece que funciona. No he
oído comentarios negativos
acerca de nuestro proceso
de gestión del cambio, con-
cretamente, auditoría no ha
dicho nada al respecto. No
podemos afrontar los gastos
indirectos de un proceso
engorroso para corregir algo
que ya funciona”.

“¿Cuál es la cantidad
aceptable de cambios no
autorizados?”
“La única cantidad aceptable
de cambios no autorizados
es “cero”. Un cambio aislado
puede destruir una opera-
ción completa: por esa
razón conciliamos los cam-
bios diariamente.
Confiamos, pero siempre
verificamos”.
“Bueno, si usted lo pregunta
de esa manera, es evidente
que la cantidad aceptable
de cambios no autorizados
es cero. ¿Pero, apostaría-
mos nuestras bonificaciones
del trimestre asegurando
que eso se cumple? En
absoluto. En particular, des-
pués del último trimestre”.
“Mire, no nos pagan para
que no hagamos cambios. A
veces, tenemos que que-
brantar las reglas. Esa es la
forma en que realmente
hacemos los trabajos aquí.
La gestión del cambio es
burocrática y sólo desean
desaceleran las cosas”.

“Describa qué controles
necesita en su proceso de
gestión del cambio”.
“Solicitamos los controles
preventivos, de detección y
de corrección que son nece-
sarios para proporcionar a la
gerencia una visión exacta
del trabajo que se está reali-
zando. Hemos definido algu-
nas nuevas mediciones del
cambio y hemos identificado
a determinadas partes intere-
sadas que debemos involu-
crar en nuestro comité de
gestión del cambio. No sabí-
amos en absoluto que a los
contadores realmente les
concernía la gestión del cam-
bio, ahora, ellos participarán
en nuestras reuniones”.
“Tenemos un equipo com-
pleto de auditores internos y
consultores que están tra-
bajando en el proyecto rela-
cionado con la Ley
Sarbanes-Oxley. Ellos están
definiendo y creando un
plan para probar los contro-
les específicos. Todo el pro-
yecto Sarbanes-Oxley reveló
la necesidad de una pers-
pectiva integrada y una
visión empresarial del cam-
bio. Además, detectamos
algunos procesos de nego-
cios que necesitan mejor
control de cambios y esta-
mos trabajando también en
esa dirección”.
“Aún estamos en la fase de
análisis. Estamos simple-
mente demasiado ocupados
con las urgencias del nego-
cio y para lo único que
hemos tenido tiempo es
para el tema de controles
respecto a la Ley Sarbanes-
Oxley. Pero sabemos que es
importante y vamos a traba-
jar en eso apenas podamos.
Además, actualmente no
tenemos presupuesto para
ese trabajo. Mi experiencia
me indica que lo que tene-
mos, probablemente, sea
suficientemente bueno por-
que nadie me ha dicho
específicamente que el pro-
ceso actual es inadecuado”.

21

Cuadro 2: Preguntas a realizar sobre la gestión del cambio agrupadas por arquetipo (continuación)
Preguntas al Gerente de TI
“¿Hemos visto beneficios a
partir del proceso de gestión
del cambio?”
“¿Recuerda la interrupción que
afectó a todo el sitio durante
la semana pasada como con-
secuencia de un cambio?
¿Qué fue lo que ocurrió?”
“Cuando usted estaba traba-
jando para solucionar la inte-
rrupción, ¿cuál fue el proceso
que utilizó para identificar el
error?”
GTAG — ¿Qué preguntas debo hacer sobre
la gestión de parches y cambios? — 5
Gerente de TI con gestión
de cambio eficaz
“Rotundamente. En realidad,
los beneficios han sido tan
evidentes que hemos creado
una cultura interna de gestión
de cambios. Ya no nos senti-
mos como bomberos profe-
sionales. Hemos mejorado
sustancialmente nuestro
desempeño, grado de tiempo
productivo y de satisfacción
por parte de nuestros clientes,
y en relación con nuestro per-
sonal interno y en toda la
línea ascendente de ejecutivos
de la empresa”.
“Pudimos determinar que el
cambio en particular que pro-
vocó la interrupción de 10
minutos estaba autorizado.
Sin embargo, no pudimos
anticipar el efecto corriente
abajo en un sistema no rela-
cionado. Esto no volverá a
suceder”.
“Lo primero que hacemos
siempre es descartar los cam-
bios autorizados, tan anticipa-
damente como sea posible en
el ciclo de reparaciones.
Supimos de inmediato que la
interrupción no se debió a un
cambio programado. Luego,
verificamos los cambios de
producción de emergencia.
Identificamos cuatro cambios
que se realizaron dos minutos
antes de la interrupción y
detectamos quiénes los hicie-
ron. Estos realizaron una res-
tauración y estuvimos
nuevamente en funcionamien-
to en sólo minutos”.
22
Gerente de TI con un estilo
de modo de resolución de
problemas
“Sí, pero aún no estamos
donde deseamos estar.
Hemos reducido la cantidad
de interrupciones y hemos
incrementado nuestra tasa de
éxito del cambio de manera
significativa. Ahora, los cam-
bios ocurren dentro de la ven-
tana de mantenimiento,
aunque aún tenemos el oca-
sional 'cowboy' que se olvida
de seguir el proceso”
“Detectamos que un programa-
dor migró un cambio sin seguir
nuestros procesos aprobados.
Nunca se le debió haber otor-
gado la autoridad de aproba-
ción para los cambios en ese
sistema específico. Corregimos
esto apresuradamente y este
programador ya no podrá ni
siquiera conectarse a los servi-
dores de producción”.
“Teníamos un presentimiento
fuerte de que el problema no
provenía de un cambio autori-
zado. Probamos e implemen-
tamos nuestros cambios
únicamente dentro de venta-
nas de lanzamientos específi-
cas. Entonces, comenzamos a
investigar revisando los regis-
tros, trabajamos hacia atrás
tomando como punto de par-
tida la interrupción y busca-
mos todo lo que estuviera
fuera de la ventana.
Finalmente, encontramos
quién había realizado el cam-
bio pero no supimos porqué
se había realizado tal cambio.
Creo que el administrador
aprendió una lección muy
valiosa ese día”.
Gerente de TI en posible
negación
“El ritmo del negocio es tan
alto en estos momentos que
simplemente no tenemos
tiempo de seguir un proceso
de gestión de cambio fastidio-
so que reduce la velocidad de
las tareas, disminuye la pro-
ductividad y crea una atmós-
fera burocrática. No siempre
responsabilizo al personal por
no seguir el proceso del cam-
bio porque ellos ya están al
límite de sus posibilidades tra-
tando de mantener este lugar
en funcionamiento. No obs-
tante, las interrupciones ocu-
rren ocasionalmente y
sabemos que no podemos
seguir colapsando el sistema
de gestión de órdenes”.
“Detectamos que uno de nues-
tros proveedores estaba reali-
zando algunas tareas de
mantenimiento y actualizando
determinado software. El pro-
blema fue que sobrescribieron
una biblioteca que nosotros
habíamos personalizado. Se
suponía que ellos debían llevar
un registro de nuestras perso-
nalizaciones, como no fue así,
esta fue una violación a nuestro
contrato de mantenimiento”.
“Dado que no tenemos un
proceso centralizado, varios
equipos por separado se
movilizaron para tratar de
descubrir cuál era el error.
Finalmente, armamos un equi-
po SWAT. Rápidamente,
pudieron descubrir que la
interrupción fue ocasionada
por la actualización del prove-
edor, pero tuvimos que esta-
blecer una conferencia
telefónica con ellos para
poder identificar que la causa
había sido nuestra biblioteca.
No hubo manera de volver la
biblioteca a su versión ante-
rior, entonces, tuvimos que
restaurar todo el directorio del
software desde una cinta”.
GTAG — ¿Qué preguntas debo hacer sobre
la gestión de parches y cambios? — 5
Cuadro 2: Preguntas a realizar sobre la gestión del cambio agrupadas por arquetipo (continuación)
Preguntas al Gerente de TI
“¿De qué manera lleva una
vigilancia general del buen
funcionamiento del
proceso?”
“¿Cuál es la meta de su
proceso de gestión del
cambio?”
“¿Su proceso de parches,
qué grado de interrupciones
ocasiona?”
Gerente de TI con gestión de
cambio eficaz
“Mediante la tasa del cam-
bio, la tasa de éxito del cam-
bio; el tiempo medio de
reparación (en inglés,
MTTR), el tiempo medio
entre fallos (en inglés,
MTBF) y un conteo de los
cambios no autorizados que
omiten el proceso. Además,
tenemos una medición de
cobertura para mostrar qué
partes de la empresa no
participan en el proceso. El
trabajo no planeado es un
excelente indicador. Siempre
buscamos las variaciones y
tratamos de ver cómo
podemos reducirlas en su
origen”.
“Confiabilidad, disponibilidad
y reducción de costos. Dos
de esos valores deben incre-
mentarse mientras el tercero
debe reducirse. Tratar de
optimizar sólo uno de los
tres nos dejaría fuera del
negocio”.
“Ninguno. Entendemos que
la disponibilidad es de capi-
tal importancia. Tenemos
que ver de qué manera miti-
gamos los riesgos de seguri-
dad sin incurrir en los
peligros asociados a los
cambios. En promedio,
colocamos un lote grande
de parches por año”.
23
Gerente de TI con un estilo
de modo de resolución de
problemas
“Medimos con qué rapidez
implementamos un cambio.
Medimos el tiempo medio
entre la solicitud del cambio
y su cierre. Nos estamos
preparando para medir la
tasa de éxito del cambio así
como los cambios de emer-
gencia y los cambios no pla-
neados”.
“Deseamos efectuar tantos
cambios como el negocio lo
requiera. Deseamos imple-
mentarlos con rapidez y
exactitud”.
“La implementación de par-
ches solía ocasionar muchas
interrupciones, pero des-
pués de la interrupción
importante que sufrimos
hace seis meses atrás, repa-
samos todos los supuestos
que nos formulábamos
acerca de qué parches
implementar y cuándo.
Hemos reducido la cantidad
de tiempo empleado en los
parches de una frecuencia
semanal a una mensual, y
ahora estamos trabajando
para lograr una frecuencia
trimestral”.
Gerente de TI en posible
estado de negación
“No utilizamos mediciones
caprichosas, aunque insisti-
mos definitivamente en la
excelencia del proceso. Sé
que tenemos muchos incen-
dios que combatir, pero a
usted también le ocurriría si
tuviera que trabajar con
algunas de estas personas”.
Nuestra meta es captar la
atención de todos los parti-
cipantes clave en las reunio-
nes de gestión del cambio y
asegurarnos de que todos
estén informados de lo que
está sucediendo y por qué.
Entendemos que en la
medida en que las auditorías
sean favorables, estamos en
la dirección correcta”.
“Debido a la mala calidad del
software que nos entregan
los proveedores, seguimos
empleando demasiado
tiempo en la implementa-
ción de parches. Es una
situación sin salida. Si no
implementamos parches,
nuestros sistemas podrían
ser atacados. Si colocamos
los parches, corremos el
riesgo de que los sistemas
de producción colapsen.
Pero como no deseamos
salir en la primera plana de
las noticias, no tenemos otra
opción que implementar
parches”.
 GTAG — ¿Qué preguntas debo hacer sobre
la gestión de parches y cambios? — 5

5.1 Evolución de la capacidad de gestión del cambio
La gestión del cambio es un proceso evolutivo. Los grupos no
deben desalentarse cuando comienzan a desarrollar sus proce-
sos de gestión del cambio. Las soluciones probablemente
requieran cambiar a las personas, los procesos y la tecnología.
A continuación, las etapas típicas de la gestión del cambio:
1. Olvido del cambio: “¿Eh, se reinició el conmutador?”
2. Conciencia del cambio: “¿Eh, quién reinició el
conmutador?”
3. Anunciar el cambio: “Eh, voy a reiniciar el conmu-
tador. Avísenme si esto ocasiona un problema”.
4. Autorizar el cambio: “Eh, necesito reiniciar el con-
mutador. ¿Quién debe autorizar esto?”
5. Programar el cambio: “¿Cuándo es la próxima venta-
na de mantenimiento? Me gustaría aprovechar la
oportunidad para reiniciar el conmutador”.
6. Verificar cambio: “Al observar los registros del admi-
nistrador de fallos, observo que el conmutador se rei-
nició según lo programado”.
7. Administrar el cambio: “Vamos a programar la opera-
ción de reinicio del conmutador para la semana 45 de
manera tal que podamos realizar la actualización de
mantenimiento y el reinicio al mismo tiempo”.
La Figura 4 muestra una evolución de la capacidad de
gestión del cambio desde un estado reactivo a un estado
de mejora continua.

Figura 4: Niveles de capacidad de gestión del cambio

LOS CAMBIOS DOMINAN A LA LOS CAMBIOS DOMINAN A LA

ORGANIZACIÓN ORGANIZACIÓN

REACTIVO BASADO EN EL USO DE GESTIÓN DE CAMBIO DE MEJORA CONTINUA

• Más del 50% del UN SISTEMA DE HONOR CICLO CERRADO • Se emplea menos del 5%
tiempo se emplea en • 35% del 50% del tiempo • 15% a 35% del tiempo del tiempo en trabajos
trabajo no planeado. empleado en trabajo no empleado en trabajo no no planeados.
• Entorno caótico, planeado. planeado. • La tasa de éxito del cam-
muchas situaciones • Alguna tecnología • Hay cierto sistema de bio es muy alta.
de emergencias implementada. flujo de trabajo/ticket • Los niveles de servicio
EFICACIA

• MTTR es demasiado • Usted tiene una visión
extenso; bajos niveles correcta, pero no hay
de servicio. responsabilidad asignada.
• Sólo puede incremen- • La proporción de servido-
tar la capacidad de TI res con respecto a admi-
destinando numero- nistradores es bastante
sas personas al baja.
problema • Los costos de TI son
demasiado altos.
• El proceso se pervierte
porque se habla con las
“personas adecuadas”.
implementado.
• Los cambios se docu-
mentan y se aprueban.
• La tasa de éxito del cam-
bio es alta.
• Los niveles de servicio
son bastante buenos.
• La proporción de servi-
dores con respecto a
administradores es
buena, pero no la mejor
de todas (en inglés, BoB).
• Los costos de TI mejo-
ran, pero aún son dema-
siado altos.
• Los incidentes de seguri-
dad han disminuido.
son de primera clase.
• Los costos operativos de
TI están bajo control.
• Se puede aumentar la
capacidad de TI rápida-
mente con aumentos
marginales en costos de
TI.
• Hay procesos de revisión
de cambios y de capaci-
tación implementados.
• Puede incrementar la
capacidad de una mane-
ra rentable.

REACTIVO BASADO EN EL USO DE UN SISTEMA DE HONOR GESTIÓN DE CAMBIO DE CICLO CERRADO. MEJORA CONTINUA

Basado en el enfoque “Operaciones Visibles” de IPTI

24
GTAG — Tres meses más tarde: finaliza la historia de Silvia — 6
Cuando Silvia considera las medidas que tomó en función de
los comentarios de Fernando y la forma tan diferente con la
que está administrando su organización, queda anonadada
por la diferencia que observa en sólo tres meses. Cuando uno
se concentra en mejorar la manera de administrar los cam-
bios, los niveles de servicio y la disponibilidad aumentan, las
situaciones de emergencia disminuyen y todos se sienten más
productivos debido a que emplean el tiempo en proyectos
estratégicos importantes.
Los auditores internos están sumamente satisfechos con
el progreso que Silvia logró en su plan de gestión de parches.
No se esperaba este resultado; ella implementa parches en
sus sistemas con menor frecuencia que antes de la auditoría.
Una vez que las observaciones de auditoría se resolvieron y
validaron con éxito, José, uno de los auditores, la llamó y le
dijo: “Buen trabajo, Silvia. Parece que has logrado un gran
cambio en 90 días. Es verdaderamente notable. ¿Cómo lo
lograste?”
Silvia se pregunta exactamente cómo lo logró. No podía
decir simplemente que aplicó todo lo que Fernando había
sugerido porque, en realidad, él nunca le había dicho qué
hacer, lo cual fue inmensamente frustrante pero le permitió
analizar a fondo sus suposiciones. Luego de reflexionar un
momento sobre la pregunta, Silvia responde: “Creo que suce-
dió en tres etapas clave. ¿Quiere que le cuente más?” José
sonríe entusiasmado y asiente con la cabeza mientras busca
en su libro de notas.
Recordando su primera reunión con Fernando, Silvia
explica: “Salí de esa reunión sabiendo que había muchas
cosas en las que tenía que pensar. ¿Cuál era la causa de los
incrementos en el trabajo no planeado? ¿Por qué nuestros
proyectos siempre se demoraban y lo hacían cada vez más?
¿Fernando se había dado cuenta de algo?”
Le preguntó a su personal en qué estaban empleando su
tiempo. Algunas partes de su organización estaban resolvien-
do situaciones de emergencia del momento y, por alguna
razón, tal como la proverbial bola de nieve, nunca podían
terminar con tales situaciones. Muchas de las entrevistas no
planificadas con el personal fueron interrumpidas por las lla-
madas de los localizadores que indicaban algún corte o inte-
rrupción de servicio y la conversación se debía suspender
antes de tiempo.
Silvia comenzó a preguntarse qué estaba generando esta
cultura de urgencia continua y comenzó a seguir a los emple-
ados para ver qué hacían cuando respondían a las llamadas
de los localizadores. Durante dos semanas, empleó el 50 por
ciento de su tiempo en observar a sus gerentes, tratando de
imaginarse en qué estaban empleando el tiempo.
“Observar de cerca a mis equipos fue sumamente esclare-
cedor. Pero hubo otra reunión con Fernando que confirmó mi
pronóstico”. Fernando había regresado de Europa y le comen-
tó a Silvia sobre los procesos maduros y eficientes de TI que
había observado en los socios joint venture que su personal
estaba auditando. Esta empresa europea tenía uno de los mejo-
res resultados de mediciones en la industria, como tiempo pro-
medio de reparación bajo (MTTR, en inglés), tiempo
promedio entre fallos alto (MTBF, en inglés), tasas de éxito
del cambio superiores al 98%, así como también, el logro más
sorprendente: una proporción administrador de sistema/servi-
dor alta debido a que la mayor parte del trabajo se realiza en el
25
proceso de administración de versiones. Fernando adjudicó
parte del éxito al modo de “administrar en función de los
hechos”, una forma de operar que recluta los esfuerzos de todas
las personas de la organización para que sus resultados se tor-
nen visibles y difíciles de ignorar. Fernando le dijo: “Cuando
las organizaciones se administran basándose en los hechos,
nada se toma como cierto sin supervisión ni medición”.
Al escuchar sobre la medición de la tasa de éxito del cam-
bio, a Silvia se le ocurrió una idea. Descubrió la causa que esta-
ba generando prácticamente todo el trabajo no planeado: los
cambios fallidos. En función de lo que había observado, esti-
mó que uno de sus equipos estaba realizando alrededor de 100
cambios por semana y no podía recordar si, durante la semana
anterior, alguno de esos cambios había tenido éxito sin causar
algún reproceso o trabajo no planeado.
“Creo que ahora puedo comprender mejor la tensión
cuando diferentes equipos tienen distintas definiciones con
respecto a un cambio exitoso”. Pensó en una reunión que
había tenido con varios administradores del centro de datos
al final del día cuando todos los localizadores de la habita-
ción comenzaron a sonar. Mientras se dirigía a la puerta, uno
de sus gerentes comentó con tono cortante: “Esos deben ser
los programadores que están implementando los cambios del
día antes de irse”.
Silvia decidió concentrarse primero en el equipo de
desarrollo para descubrir cuántos cambios realizaban, cuán-
tos de ellos fallaban y por qué fallaban. Les solicitó a todos
sus gerentes que enviaran una lista de los problemas operati-
vos más importantes que habían surgido en el último trimes-
tre y que clasificaran la causa raíz en fallos de hardware,
condiciones ambientales o fallos relacionados con los cam-
bios. Quería descubrir cómo el equipo que realizaba los cam-
bios decidía si eran exitosos y si sabía o no que estos cambios
podrían crear una situación de emergencia para otro equipo.
Cuando le mostró un resumen del plan a Fernando, él
sonrió y le dijo: “Felicitaciones. Estás comenzando a plante-
ar las preguntas que todas las organizaciones de TI de alto
rendimiento se plantean”. Le preguntó cómo debía ser un
proceso de gestión del cambio eficaz. Silvia pudo identificar
algunos aspectos clave.
“¡Muy bien!”, respondió Fernando. “Entonces, ¿qué
vas a hacer para corregir los procesos deficientes y así
alcanzar tus metas?”
Silvia describió cómo sus esfuerzos recientes le permitie-
ron “estabilizar al paciente”. Redujo o eliminó el acceso para
tomar control de las fuentes de cambios no planificados y
propensos a errores. En las dos semanas anteriores, documen-
tó un nuevo proceso de gestión del cambio, notificó a todas
las partes interesadas, creó un equipo para llevar a cabo el
cambio y ventanas de cambio para controlar mejor lo que se
hacía y el momento en que se hacía y “electrificó la barrera”
para asegurarse de que todo el personal de TI se sintiera com-
pletamente responsable de las “mejoras” que realizaban.
Ahora su lema es “Confiar pero siempre verificar”. Todos
parecían haber captado el mensaje y las nuevas reuniones
semanales de gestión del cambio la ayudaron a asegurarse
que se aplicara el sistema de rastreo de solicitudes existente
y a mejorar las comunicaciones internas.
De hecho, la mayoría de sus problemas giraban en torno
a los cambios fallidos. Los nuevos controles fueron suma-
 GTAG — Tres meses más tarde: finaliza la historia de Silvia — 6
mente eficaces. Silvia recordó que le había enviado al equi-
po un mensaje de felicitaciones anunciando que no habían
surgido “sorpresas” durante los últimos cinco días, una situa-
ción poco común. (Cuando generó algunos reportes para
averiguar cuándo había sucedido eso por última vez, se son-
rió y decidió guardar en secreto los resultados. La última vez
que los niveles de servicio alcanzaron esta eficiencia fue el
verano pasado cuando este mismo equipo tuvo un trabajo de
TI fuera de la oficina, lejos de sus teclados).
Silvia ahora tenía una estadística que mostraba la cantidad
de cambios no planificados y el tiempo improductivo y un
reporte con los nombres de los proyectos y de las personas que
causaron problemas desde que se implementó el nuevo proceso.
El personal de Silvia había identificado la mayoría de las
causas del tiempo improductivo y ahora tenía un plan de
“respuesta inmediata” para poner el equipo en funciona-
miento en la mitad del tiempo. Su equipo necesitaba sólo el
20 por ciento del tiempo improductivo para identificar la
causa de la interrupción y empleaba el 80 por ciento en solu-
cionarla. Anteriormente, se empleaba mucho tiempo en
identificar qué había cambiado, quién lo había cambiado y
por qué. Silvia reconoció que ese proceso era ineficiente.
Silvia le comenta a José: “Quiero comenzar a emplear la
tasa de éxito del cambio para cada proceso de negocios y
activo de TI de manera que pueda aprender del desempeño
anterior y evitar la implementación de cambios histórica-
mente riesgosos”.
Mostrando curiosidad acerca de la participación del per-
sonal en el nuevo proceso, José le pregunta: “¿Cómo sabes si
en verdad todos están siguiendo el proceso?”.
Silvia le explica que el grupo de operaciones de TI
publica una lista de cambios autorizados. Además, ha “elec-
trificado la barrera” para asegurarse de que se siga el proceso.
Ha implementado controles de detección para informar
todos los cambios de producción, que luego se deben conci-
liar con la lista de cambios autorizados. Cuando se detectan
cambios no autorizados, se envía un mensaje a todo el equi-
po de ingeniería para comunicarle que tiene cuatro horas
para que alguien explique por qué realizó un cambio no auto-
rizado antes de activar una investigación de seguridad.
José le pregunta si todos desarrollan planes de “restaura-
ción” antes de autorizar la implementación de los cambios.
Silvia confirma esto y comenta que han logrado beneficios
medibles al definir por anticipado cómo recuperarse ante un
problema, en lugar de intentar hacerlo durante el momento
candente de la recuperación. José la felicita y está ansioso por
comentar sus éxitos con los demás gerentes de TI y departamen-
tos.
Silvia se siente gratificada pero sabe que hay mucho más
por hacer. Entonces, recuerda el consejo de Fernando: “Ahora
que has comenzado a controlar cómo se realizan los cambios
en la producción para reducir la probabilidad de trabajo no
planeado, necesitas hacer un inventario de todos los activos
de infraestructura e identificar aquellos que generan la mayor
parte del trabajo no planeado”. Como un especialista en fauna
que controla la manada de venados, Silvia debe supervisar
cada activo para descubrir cuáles están funcionando, qué ser-
vicios dependen de ese activo, quién es el responsable y cuán
frágil es el artefacto. “Tener un inventario no sólo ayuda en la
gestión de problemas sino que también contribuye al desarro-
26
llo de una biblioteca de compilación repetible de los activos y
servicios más críticos, con lo cual se reduce el costo de repara-
ción de tales elementos”.
Silvia acepta que la orientación que le dio Fernando la
ayudó a comprender lo que José le está diciendo. Espera fina-
lizar su plan de acción y debatirlo con Fernando antes de la
próxima reunión del comité de auditoría. “Ahora me doy
cuenta de que la gestión ineficaz del cambio hizo que mi
equipo viera al proceso como algo burocrático y, por lo tanto,
lo ignorara”. Cuando Silvia pudo demostrarles que el 80 por
ciento de las interrupciones eran causadas por errores de la
aplicación o de los operadores, comenzaron a comprender
por qué el departamento luchaba por asignar personas a los
proyectos de desarrollo de preproducción. José le agradece a
Silvia por su tiempo, cierra su libro de notas y se va.
Silvia está ansiosa por revisar su plan con el comité de
auditoría la semana próxima. En función de los resultados
del nuevo proceso de gestión del cambio durante los últimos
60 días, ella calcula que podrá redireccionar los esfuerzos de
dos o tres personas que actualmente manejan la gestión de
parches y de otra persona que se dedica a diagnosticar las
causas del tiempo improductivo y las etapas de corrección.
Silvia cree que puede reasignar a tres miembros del per-
sonal al nuevo proyecto de servidor Web para órdenes de
cliente y llegar a implementarlo correctamente antes de las
vacaciones, en lugar de hacerlo a principios de año. Le
comenta a Fernando: “El equipo de marketing proyecta un
incremento del 20 por ciento en las órdenes previas a las
vacaciones a través de este proceso si tenemos éxito. Es una
muy buena noticia para el consejo. Y este es sólo el comien-
zo”. Silvia le dice a Fernando. Durante una revisión de cen-
tro de datos por incumplimientos, su equipo de auditoría no
encontró ninguna discrepancia entre nuestros estándares de
configuración de TI y nuestros servidores de producción. No
sólo los miembros de mi equipo adoptaron el nuevo proceso
de gestión del cambio, sino que también instalaron software
automático para evitar y detectar variaciones entre los están-
dares y los parámetros actuales de configuración mejorando
significativamente la seguridad de nuestra información”.
No obstante, Fernando no está convencido y señala que
Silvia no puede administrar lo que no puede medir, y que eso
que se puede medir, es lo que en definitiva se debe hacer.
Silvia describe las medidas clave de su proceso de versiones,
control y resolución y de otros procesos. Entiende que si su
personal no puede describir los procesos ni realizar las medi-
ciones con respecto a estos, no sabrá qué está haciendo.
Fernando parece impresionado y dice: “No está mal,
Silvia. Suena como un gran plan”.
Por primera vez en sus conversaciones con Fernando,
Silvia se siente como si finalmente ha aprobado el examen.
Pero no puede resistirse a hacer una pregunta que ha tenido
en mente desde que conoció a Fernando. “A propósito,
¿cómo sabe tanto de gestión de cambios?”
Fernando le responde: “Como antes mencioné, soy una
persona de negocios que trabaja en auditoría interna. En
ABC Telecom, estaba en TI y era el responsable de infraes-
tructura y operaciones. Conseguí ese trabajo gracias a que
pude demostrar mi habilidad para instalar procesos repetibles
y verificables, en los que la seguridad, la disponibilidad, la
calidad y el valor se incorporaban a los procesos y se medían
GTAG — Tres meses más tarde: finaliza la historia de Silvia — 6

en el curso normal de los negocios. Sin esto, no podíamos

prestar nuestros servicios y mantener nuestros clientes. Tomé
este trabajo para aplicar el mismo proceso de ideas en toda la
empresa, no sólo en TI. Existe una verdadera necesidad de
garantizar que todos nuestros procesos de negocios y sistemas
de respaldo incluyan los controles necesarios para que no se
produzcan errores como sobrepagos a proveedores, estados
financieros erróneos o demoras en la entrega de sistemas y
servicios. ¿Dónde mejor que el departamento de auditoría
interna, con el respaldo total de la gerencia y del comité de
auditoría del consejo, para lograr esto?”

27
GTAG — ¿Por dónde deben comenzar los auditores internos? — 7
Según el Enfoque Integral de Gestión de Riesgo Empresarial
(Enterprise Risk Management - Integrated Framework), la
gerencia establece los objetivos estratégicos, selecciona las
estrategias y difunde los objetivos alineados en toda la
empresa. El enfoque de gestión de riesgo empresarial se
orienta hacia el logro de los objetivos de la entidad en cua-
tro categorías: estrategias, operaciones, generación de repor-
tes y cumplimiento. Se deben diseñar e implementar
controles preventivos, de detección y de corrección para
ayudar a garantizar que las respuestas a los riesgos se lleven a
cabo con eficacia. La auditoría puede ayudar a garantizar que
la gestión de TI cuente con un proceso eficaz para adminis-
trar los riesgos asociados con el logro de los objetivos. Entre
los ejemplos de los tipos de objetivos de gestión de cambios
que la gestión de TI debe definir, se encuentran aquellos para
la revisión y aprobación de solicitudes de cambio, que garan-
tizan que los cambios se implementen de manera adecuada y
eficaz, y que ayudan a garantizar que TI pueda efectuar una
recuperación rápida cuando los cambios fallan.
Los controles preventivos, de detección y corrección se
deben deducir de los objetivos de la gerencia para la gestión
de cambios de TI. La gestión de TI debe demostrar que los
siguientes controles existen y son eficaces [Tipton 00]:
• Controles preventivos.
– Autorización de cambios.
• Documentación que muestra el proceso de gestión
de cambios, incluidos los roles y las responsabilidades
de los participantes..
• Documentación que muestra los propietarios
autorizados para todos los procesos de negocios y
los sistemas de TI de respaldo, con niveles
asignados de autorizaciones.
– Separación de roles.
• Documentación que muestra la clara asignación y
separación de los roles y las responsabilidades de
las partes interesadas en la gestión de cambios,
incluida la autorización, la planificación, la
implementación y la revisión de cambios.
• Políticas claras que describen las categorías y los
niveles de cambios y los grados de formalidad,
aprobación y severidad asociados con el avance de
los cambios dentro de cada categoría desde la
iniciación hasta la etapa de implementación.
• El acceso para realizar cambios en la producción
está estrictamente limitado a las personas
responsables de implementar los cambios. Todos
los demás empleados, como por ejemplo los
programadores, no poseen tal acceso.
• Programas de capacitación y difusión para
promover una cultura de la gestión del cambio.
– Supervisión y monitorización.
• Documentación que muestra que el proceso de
cambios está siendo controlado, supervisado e
implementado de manera eficaz. En todo momento,
debe existir una lista publicada de cambios
autorizados, así como también una lista de cambios
no autorizados, generada mediante la conciliación
de los cambios reales de producción y los cambios
autorizados.
• Las actas de las reuniones de la gestión del cambio
28
también pueden mostrar las solicitudes de cambios
recientemente autorizados y programados. Cada
solicitud de cambio debe tener un identificador
único y una persona responsable.
• Controles de detección.
– Supervisión y monitorización:
• Métodos automáticos para detectar si los cambios
realizados en la producción están presentes y si se
revisaron independientemente. Podrían ser
registros de auditoría de cambios o utilidades que
analizan la infraestructura de producción para
encontrar los cambios.
• Cambios en el equipo de producción registrados
en registros de trabajo, tickets de trabajo y órdenes
de cambio. Estos deben identificar la fecha, la
hora, el implementador y el sistema junto con los
detalles de los cambios realizados.
• Los cambios se deben revisar para garantizar que
no exista variación entre el cambio planificado y
el cambio implementado. Las variaciones se deben
informar y explicar.
• Aceptación de cambios implementados,
documentando la correlación entre los cambios
detectados y los cambios implementados,
indicación de una implementación exitosa,
aceptación por parte de un gerente de cambios y
cierre de la orden del cambio.
– Muestreo sustantivo para auditar la exactitud de las
conciliaciones entre los cambios de producción y los
cambios autorizados.
• Muestra de solicitudes de cambios autorizados.
Recorrer el proceso de gestión de cambio para
garantizar que los cambios se hayan implementado
dentro del alcance del cambio autorizado.
• Muestra de controles de detección correspondiente
a los cambios. Garantizar que los cambios se puedan
asignar al trabajo autorizado.
• Controles de corrección y de recuperación.
– Se identifican todos los cambios realizados fuera del
proceso de gestión de cambio. La documentación
describe las acciones correctivas y lógicas tomadas.
– Revisiones posteriores a la implementación sobre los
cambios realizados, en función del grado del cambio,
importancia de las actividades comerciales que
sufrieron cambios y la significatividad de los riesgos
potenciales para el negocio.
– Cuando los cambios fallan, los gerentes de problemas
primero descartarán el cambio en el ciclo de
reparación mediante el acceso a los cambios autoriza
dos y planificados y mediante la revisión de los
cambios de producción en la infraestructura afectada.
Para lograr el éxito, la gerencia se debe alinear con las
inquietudes de los accionistas, representados por el consejo
de administración. Se deben alcanzar los objetivos de la
empresa, que, en general, son objetivos relacionados con la
participación de mercado o ingresos, con el crecimiento del
precio de las acciones o del negocio o con la contención de
los costos de personal y operaciones. Se deben formular pla-
nes para alcanzar los objetivos y se deben desarrollar de
manera eficaz en toda la organización para tener la posibili-
 GTAG — ¿Por dónde deben comenzar los auditores internos? — 7
dad de lograr el éxito. El Comité de Auditoría desea asegu-
rarse de que la gerencia haya identificado y evaluado los ries-
gos que podrían impedir el logro de los objetivos. Se deben
adoptar procesos sólidos para mitigar, administrar, aceptar o
transferir los riesgos eficazmente. La variación del plan tam-
bién es un riesgo que se debe manejar de manera activa. Los
auditores internos son los ojos y oídos de la gerencia, a tra-
vés de ellos se busca detectar las áreas del entorno de gestión
de riesgos que necesitan fortalecimiento.
Para la mayoría de las empresas, la no disponibilidad de
servicios y funciones críticas, incluso durante breves perío-
dos de tiempo, es una de las maneras más rápidas de inte-
rrumpir el progreso hacia el alcance de los objetivos del
negocio. El tiempo de inactividad de la red inesperado puede
detener la ejecución de los procesos críticos de negocios,
como la coordinación de calendarios de materiales con pro-
veedores y la respuesta rápida a órdenes del cliente. Del
mismo modo, el tiempo de inactividad en una aplicación crí-
tica, base de datos o servidores Web puede ser destructivo.
Los auditores internos, junto con la gerencia, desean asegu-
rar que estos riesgos y los riesgos relacionados se hayan iden-
tificado, medido y administrado correctamente. Pero, ¿cómo
puede administrar dichos riesgos si no ha identificado ni ana-
lizado sus causas?
Proteger el entorno de producción y respaldar a la orga-
nización mientras se persiguen los objetivos de negocio son
responsabilidades clave del departamento de TI. Los audito-
res internos tienen la responsabilidad de garantizar que se
desarrollen procesos adecuados de gestión de riesgos, incluso
dentro de TI. A esos fines, la importancia de un proceso de
gestión del cambio eficaz no puede subestimarse y los audito-
res internos deben considerar la posibilidad de efectuar revi-
siones regularmente.
7.1 El rol de la auditoría en el proceso de
gestión de cambios
Dado que los auditores internos, por lo general, no tienen
tiempo para revisar todas las facetas de las organizaciones en
las que trabajan, deben desarrollar planes de auditoría en
función de una evaluación de riesgos. Para poder evaluar los
riesgos de negocios dentro de TI, los auditores deben recopi-
lar información preliminar. A continuación se detallan las
tareas que deben llevar a cabo los auditores para determinar
el nivel relativo de riesgo de negocio asociado con las prác-
ticas de la gestión del cambio de la organización y si se debe
realizar una revisión profunda o de nivel avanzado de la ges-
tión del cambio:
1. Se deben comprender los componentes básicos de la
gestión del cambio. El término gestión del cambio, tal
como se utiliza en este documento, no incluye todo el
proceso del ciclo de vida del desarrollo de sistemas,
como el desarrollo de aplicaciones o la gestión de con-
figuración. No obstante, la gestión del cambio debe
reflejar e integrarse con el proceso del ciclo de vida del
desarrollo de sistemas (y controles relacionados).
Comprender el contenido de esta guía le proporciona
el conocimiento suficiente como para realizar las pre-
guntas difíciles relacionadas con la organización de TI
y así poder entender el nivel de mejora que posible-
mente se necesite en el proceso y los controles de ges-
29
tión del cambio. (Consulte el Cuadro 2, página 21,
para obtener preguntas útiles que podrá realizar).
2. Se deben utilizar los indicadores de procesos de gestión
del cambio eficaz e ineficaz (consulte las Secciones
3.2, página 10, y 3.3, página 11) y los niveles de capa-
cidad proporcionados en esta guía (consulte la Figura
4, página 24) para evaluar la eficacia relativa de los
procesos de gestión del cambio correspondientes a la
organización. Realice una revisión del proceso de ges-
tión del cambio y busque los elementos clave descrip-
tos en esta guía. Se debe comprender cómo la
administración de TI mide el proceso y si este respon-
de verdaderamente a las necesidades del negocio.
3. Se debe obtener una ficha de evaluación de la admi-
nistración de TI para medir los resultados y la eficacia
del proceso. Se debe determinar si se están utilizando
las mediciones adecuadas para supervisar el proceso e
impulsar mejoras continuas. (Consulte la Tabla 1,
página 16).
4. Se debe determinar si la administración de TI ha asig-
nado la responsabilidad de la gestión del cambio a un
empleado que no sea el programador de software ni el
encargado de preparar los cambios. ¿La administración
ha asegurado el entorno de producción de manera que
sólo las personas responsables de implementar cambios
puedan efectivamente implementarlos?
5. Se debe realizar una breve revisión para determinar si
existen pistas de auditoría de los cambios en el entor-
no de producción y que dichas pistas de auditoría no
puedan ser manipuladas ni destruidas.
6. Al realizar auditorías de control de cambios, se deben
buscar indicadores de gestión del cambio eficaz, tal
como se muestra en el ejemplo de programa de audito-
ría del Apéndice A (página 32). Debe concentrarse en
los riesgos del negocio causados por el fallo en alcanzar
los objetivos de control, que están basados en los
Objetivos de Control de Información y Tecnología
Relacionada (en inglés, COBIT).
7. Se debe ayudar a la administración a identificar los
modelos con los que se puede mejorar el enfoque hacia
la gestión del cambio. Un ejemplo es el libro Visible
Ops Handbook: Starting ITIL in Four Practical Steps
[ITPI 04], descrito en el Apéndice B (página 39). Esta
guía concisa contiene información útil sobre cómo es
una organización de TI de alto rendimiento y cómo
mejorar un bajo rendimiento. Presenta el proceso de
mejora en cuatro etapas:
• Estabilizar al paciente.
• Buscar artefactos frágiles.
• Crear una biblioteca de compilación repetible.
• Mejora continua.
8. Cuando la organización considera la posibilidad de ter-
cerizar funciones de TI a un proveedor de servicios, se
debe verificar que las expectativas de la organización
estén claramente identificadas en los acuerdos de niveles
de servicio (SLA, en inglés) y en los contratos. Es impor-
tante garantizar que se tengan en cuenta los siguientes
puntos respecto del proceso de gestión del cambio:
• ¿Quién es el responsable de administrar interna-
mente los cambios diarios que surgen a partir de
GTAG — ¿Por dónde deben comenzar los auditores internos? — 7

las solicitudes de cambios?

• ¿Cómo sabe la organización si los cambios fueron
realizados por el proveedor de servicios fuera del
proceso de gestión del cambio acordado?
• ¿Qué control tiene la organización sobre el prove-
edor de servicios para asegurarse de que este no
realice cambios no autorizados o ilógicos? ¿Cómo
sabe la organización si se efectuaron dichos
cambios?
• ¿Cómo se evita que el proveedor apruebe cambios
fuera de los períodos de tiempo de la ventana de
cambio, con el consiguiente impacto en el servicio
(aplicaciones no disponibles cuando se necesitan)
y en el costo (o pérdida de ingresos)?
• ¿Quién es el responsable de garantizar que los
cambios de negocio importantes que afectan a TI
se hayan evaluado, aprobado, planificado, con-
trolado, implementado y revisado adecuadamente?
• ¿El proveedor ha considerado los impactos en la
infraestructura (sistema y red) y en la seguridad
de la información como parte de la evaluación de
cada cambio?
• ¿La organización ha identificado quién, entre sus
integrantes, es la persona que pertenece a los
comités de control de cambios del proveedor?
• ¿Quién supervisa el cumplimiento de los acuerdos
de niveles de servicio?
• Para los sistemas dentro del alcance del artículo
404 de la Ley Sarbanes- Oxley u otras regulacio-
nes, el acuerdo de niveles de servicio también
debe incorporar prácticas requeridas, procedi-
mientos de validación, cálculos de tiempo de la
prueba requerida, trabajo de corrección, repeti-
ción de pruebas y otras consideraciones.
9. Al debatir y escribir las observaciones de auditoría, se
debe presentar el valor de negocio de los procesos de
gestión del cambio eficaces, además de los riesgos de
los procesos ineficaces. Se deben articular claramente
los riesgos de operaciones, financieros y reglamenta-
rios, que no se están administrando adecuadamente y
vincular los resultados con las tolerancias de riesgos
que ha establecido la administración para respaldar las
metas y los objetivos del negocio. Se debe evitar con-
centrarse en la tecnología, excepto cuando se hayan
automatizado ciertos controles del proceso de gestión
del cambio. En cambio, se le debe recordar a la admi-
nistración que la gestión del cambio está basada en
procesos, tiene un enfoque de gestión y humano, y está
respaldada por controles técnicos y automáticos.

11
ITIL es marca registrada en la Oficina de Comercio de Gobierno (en inglés, OGC).

30
 GTAG — ¿Dónde puedo obtener más información? — 8

Best in Class Security and Operations Round Table Report, Julia

Allen, Kevin Behr, Gene Kim, et al., (CMU/SEI-2004-SR-
002). Pittsburgh, PA: Software Engineering Institute, Carnegie
Mellon University, marzo de 2004. Disponible a través de los
autores mediante solicitud.
Capability Maturity Model® Integration (CMMI®).
Carnegie Mellon University, Software Engineering Institute.
Disponible en http://www.sei.cmu.edu/cmmi/cmmi.html.
Chrissis, Mary Beth, et al. CMMI®: Guidelines for Process
Integration and Product Improvement. Addison Wesley,
2003. Consulte específicamente el área de proceso de gestión
de configuración.
COBIT [Control Objectives for Information and related
Technology] 3rd Edition Executive Summary, Framework,
Control Objectives, Audit Guidelines, and Management
Guidelines, julio de 2000. Disponible en http://www.itgi.org y
http://www.isaca.org. Consulte específicamente AI-6:
Acquisition and Implementation: Manage changes y DS-9:
Delivery and Support: Manage the configurations.
Information Technology Infrastructure Library (ITIL)® 11.
Office of Government Commerce. Vaya a
http://www.ogc.gov.uk/index.asp?id=2261 y
http://www.itsmf.com. Consulte específicamente el volumen
Best Practice for Service Support, Capítulo 8, Change
Management (2000).
ISO/IEC 17799 Information Technology Code of Practices
for Information Security Management, First Edition. ISO/IEC
17799:2000(E). Diciembre de 2001. Consulte específicamente
las secciones 8.1.2 Operational change control, 10.5.1 Change
control procedures, 10.5.2 Technical review of operating system
changes y 10.5.3 Restrictions on changes to software packages.
Microsoft Service Management Functions Operations
Guide: Change Management. Microsoft Corp., 2004.
Disponible en http://www.microsoft.com/technet/itsolutions/tech-
guide/msm/smf/smfchgmg.mspx.
Systems Assurance and Control (SAC). The Institute of
Internal Auditors Research Foundation, Agosto de 2003.
Información e índice disponibles en
http://www.theiia.org/esac/index.cfm.
Visible Ops Handbook: Starting ITIL in Four Practical
Steps. Kevin Behr, Gene Kim, George Spafford. IT Process
Institute, 2004. Información disponible en
http://www.itpi.org/visibleops.

31
 GTAG — Apéndice A — Programa de auditoría
de gestión del cambio de TI — 9

Proceso, propósito y riesgos – Quién: el cambio fue implementado por una

La gestión del cambio de TI es un proceso para administrar
cambios en el hardware de producción, en los dispositivos de
red, en los sistemas operativos y en el software de aplicación.
La administración de una organización utiliza el proceso de
gestión del cambio de TI para:
• Garantizar que los cambios de TI respondan a las nece-
sidades de la organización y crean valor de negocio.
• Anticipar y administrar los problemas que se pueden
generar en el entorno de producción como resultado
de los cambios.
• Promover la eficacia y la eficiencia de los esfuerzos de
la gestión del cambio de TI.
El logro de estos objetivos estratégicos y operacionales de
alto nivel no está garantizado automáticamente. Los even-
tos, los riesgos clave y otras circunstancias podrían impedir
que la administración alcance los beneficios de negocio dese-
ados. Dichos eventos son los siguientes:
• Los cambios interrumpen las operaciones y crean otros
problemas.
• Los cambios que causan interrupciones u otros proble-
mas no son detectados ni se rastrea su origen para la
oportuna identificación de las causas y la restauración
de los servicios afectados.
• Los cambios no se realizan de manera completa u opor-
tuna.
• Los cambios no se realizan de la manera más eficiente,
lo que genera costos excesivos.
• A pesar de implementar los cambios correctamente,
estos no pueden responder a los requerimientos del
negocio y, por lo tanto, no crean el valor de negocio
deseado.
A continuación, se incluye un ejemplo de un programa de
auditoría que puede ser útil para la administración de TI y
para los auditores internos que deseen evaluar los controles
que podrían mitigar el riesgo inherente a estos eventos.
persona no autorizada
– Qué: el cambio excede el alcance del cambio auto-
rizado o el cambio pretendido se implementó, de
manera incompleta.
– Dónde: el cambio se implementó en un activo
inadecuado.
– Cuándo: el cambio se implementó fuera de la ven-
tana de cambio o ventana de mantenimiento
programada.
• Trabajo planeado: Cualquier actividad del trabajador
que puede ser asignada a un proyecto o procedi-
miento autorizado.
• Trabajo no planeado: Cualquier actividad del trabaja-
dor que no puede ser asignada a un proyecto o proce-
dimiento autorizado.13
• Incidente que afecta al servicio: Cualquier evento que
no forma parte de la operación estándar de un servicio
y que causa, o podría causar, una interrupción o reduc-
ción de la calidad del servicio. Por ejemplo, falta de
disponibilidad de aplicaciones o servicios, inactividad
del hardware o sistema, deterioro del servicio, etc.
[ITIL 00].

9.1 Definiciones de la gestión del cambio12:

• Solicitud del cambio: Procedimiento propuesto para
una adición, modificación o eliminación de elementos
aprobados, respaldados o básicos de hardware, red,
software, aplicación, entorno, sistema, compilación de
escritorio o documentación asociada. [ITIL 00]
• Cambio autorizado: Solicitud de cambio para un pro-
cedimiento de cambio que ha sido aprobado por el
Consejo de asesoramiento para el cambio (CAB, en
inglés).
• Cambio no autorizado: Cambio detectado mediante
los controles de detección de producción que no se
puede asociar a un cambio autorizado. Los ejemplos de
las variaciones que podrían generar un cambio no
autorizado son los siguientes:

12
Si la gerencia no desarrolló sus propias definiciones, el auditor y el auditado deben acordar en qué consisten las definiciones a los fines de la auditoría.
13
Lo ideal es que el trabajo planeado y no planeado se mida en lugar de calcularlo. No obstante, incluso cuando se usan las definiciones más informales, la
cantidad de trabajo planeado y no planeado puede resultar un indicador excelente de la eficacia de la organización de TI. Toda interrupción del servicio
representa un trabajo no planeado, al igual que el trabajo originado por un cambio fallido, cambio de emergencia, parche o incidente de seguridad. El tra-
bajo no planeado es aquel que hace que los gerentes de TI reorganicen sus horarios y no permite que los administradores de sistemas puedan llevar a cabo
sus planificaciones diarias.

32
GTAG — Apéndice A — Programa de auditoría
de gestión del cambio de TI — 9

Cuadro 3: Programa de auditoría de gestión del cambio de TI

Referencia
Riesgo Objetivo del control Prueba
en COBIT

Se debe obtener:
• Políticas, normas y procedimientos de gestión del cambio de TI.
• Enumeración de los organigramas departamentales y de personal
donde consten los participantes de la gestión del cambio, espe-
cialmente los responsables del desarrollo y la implementación de
los cambios.
• Información relativa a los proveedores de servicios de terceros
que participan en el proceso, incluidos los acuerdos de niveles
de servicio (en inglés, SLA) y contratos relacionados.
• Diagramas de flujo en los que figure el proceso de gestión del
cambio de TI.
• Inventario y descripciones de los elementos del entorno de
producción alcanzado por la auditoría (por ejemplo, dispositivos
de red, servidores, bibliotecas, bases de datos).
• Mediciones, normas y compromisos de niveles de servicio de las
operaciones de TI, especialmente los que se vinculan directa-
mente con la gestión del cambio y del problema.
• Informes de muestra que indiquen cómo las mediciones, las
normas y los compromisos de nivel de servicio se deben
informar a la gerencia.
• Informes y análisis de los problemas recibidos por la mesa de
servicio.
• Lista de los cambios autorizados.
• Registros de control del cambio.

Es posible La gestión de TI asegu- Se debe establecer que las políticas, normas y procedimientos de AI6.
que el proce- ra que todas las solici- gestión del cambio de TI se apliquen de manera lo suficientemente Gestionar
so de gestión tudes de cambio, el amplia como para asegurar el control de gestión del entorno de los cam-
del cambio de mantenimiento del sis- producción. Se debe comprobar que prevean: bios
TI no contri- tema y el mantenimien- • Diferentes opciones según los costos y riesgos del cambio.
buya adecua- to de los proveedores
damente al sean estandarizados y • Información del caso de negocio que sirva de guía para el esta-
logro de las estén sujetos a procedi- blecimiento de un orden de prioridad para los esfuerzos realiza-
metas del mientos formales de dos en pos del cambio.
negocio. gestión del cambio. La • Una evaluación estructurada de los riesgos y el impacto que
gerencia dispone de tenga en cuenta todos los impactos posibles en el sistema ope-
una visibilidad adecua- rativo y su funcionalidad.
da de los cambios de TI • El establecimiento de categorías y prioridades para los cambios.
realizados al entorno de
la producción y ejerce • El manejo específico de los cambios de emergencia.
un control apropiado • La comunicación con los solicitantes del cambio en relación con
de estos. el estado de su solicitud.
• La definición de los requerimientos.
• Las pruebas (incluyendo las de unidad, regresión, sistema, inte-
gración capacidad/desempeño y la prueba de aceptación de
usuario según corresponda).

33
 GTAG — Apéndice A — Programa de auditoría
de gestión del cambio de TI — 9
Cuadro 3: Programa de auditoría de gestión del cambio de TI (continuación)

• La generación y/o modificación adecuadas de la documen-

tación relacionada.
• La comunicación adecuada de los cambios pendientes a las
partes afectadas, entre ellas a la gerencia, los usuarios, los
programadores , los administradores de seguridad, opera-
ciones de TI y al personal de la mesa de ayuda.
• La separación adecuada de los entornos de desarrollo,
prueba y producción.
• La consideración adecuada de las consecuencias de los contro-
les (por ejemplo, que incluya desde un principio la gestión de
seguridad de la información).
• La consideración adecuada de los efectos para la continui-
dad del negocio.
• Las responsabilidades para la investigación de los fallos ,
junto con el proceso de resolución de incidentes.
• Los controles definidos a lo largo del proceso de cambio.

Se deben revisar las mediciones, normas, niveles de servicio, com-

promisos e informes relacionados con las operaciones de TI. Se
debe verificar que proporcionen a la gerencia información inde-
pendiente, oportuna, exacta, completa, concisa y relevante para
determinar los efectos de los cambios y problemas en las opera-
ciones de TI y en última instancia en las metas del negocio. Las
medidas deben incluir:

• La cantidad de cambios autorizados por semana: ¿Cuántos

cambios, según la medición realizada durante el proceso de
gestión del cambio? (En general, cuanto mayor sea la cantidad,
mejor, siempre que la tasa de éxito del cambio también se
mantenga elevada).

• La cantidad de cambios reales realizados por semana: ¿Cuántos

cambios, según las mediciones realizadas por controles de
detección? (En general, cuanto más cambios se realicen mejor,
pero no deben superar la cantidad de cambios autorizados por
el consejo de asesoramiento para el cambio).

• La cantidad de cambios no autorizados: ¿Cuántos cambios sos-

layaron el proceso de cambio? Esto generalmente se mide
usando los controles de detección o, lo que es peor, a través
de interrupciones no planeadas. (Cuanto menos, mejor).

• La tasa de éxito del cambio: ¿Cuántos cambios se implementan

de manera exitosa sin ocasionar interrupciones o episodios de
trabajo no planeado? (Cuanto más, mejor). La tasa óptima
supera el 99 por ciento).

• La cantidad de interrupciones que afectan el servicio: ¿Cuántos

cambios generan deterioros del servicio o interrupciones?
(Cuanto menos, mejor).

• Cantidad de cambios de emergencia: ¿Cuántos cambios necesi-

taron del uso del proceso de cambio de emergencia? (En gene-
ral, cuanto menos, mejor ya que indica un porcentaje más ele-
vado de trabajo planeado).

34
GTAG — Apéndice A — Programa de auditoría
de gestión del cambio de TI — 9
Cuadro 3: Programa de auditoría de gestión del cambio de TI (continuación)
A través de entrevistas, análisis o revisión de los registros de las AI6.2
reuniones, se debe verificar que existe un grupo de gestión, como Evaluación del
un consejo de asesoramiento para el cambio, que se reúne regu- impacto
larmente, revisa las solicitudes de cambio de TI y las aprueba o
rechaza según corresponda. Se debe establecer que los socios
brinden a la gestión una explicación adecuada de los cambios y
control sobre los mismos. Verifique que los usuarios estén inclui-
dos, si corresponde.

Se deben obtener listados de personal y copias de los organigra- AI6.6

mas donde figure el grupo responsable de la gestión e implemen- Mantenimiento
tación de los cambios de TI. Se debe verificar que el grupo sea autorizado
independiente de los responsables de la solicitud y
desarrollo/preparación de los cambios.
Se debe seleccionar una muestra de los cambios introducidos a AI6.1 Inicio y
los elementos de producción dentro del alcance y el término de la control de la
auditoría. Se debe establecer que existe documentación clara que Solicitud de
indique que para la implementación de los cambios se respetaron Cambio
todas las políticas, normas y procedimientos aplicables.

Es posible que Que se aprueben Se debe revisar las políticas, normas y procedimientos para que AI6.2
se implemen- únicamente los establezcan que los cambios requieren la aprobación de la geren- Evaluación del
ten cambios de cambios adecua- cia, incluida la aprobación de las operaciones de TI y de los usua- impacto
TI que no satis- dos. rios comerciales . La aprobación debe requerirse en los puntos
facen las nece- adecuados del proceso de cambio. Por ejemplo, se puede reque-
sidades rir la aprobación por parte de la gerencia correspondiente al final
comerciales de de la preparación del caso de negocio, de la definición inicial de
la gerencia. los requerimientos y/o de determinadas fases de prueba.

Revisar las normas, procedimientos, prácticas y tecnologías de

gestión del cambio de TI para comprobar que antes de la aproba-
ción final:
• Se haya verificado que los requerimientos responden al caso
de negocio para el cambio.
• Se haya cumplido con los requerimientos tal como se evidenció
mediante la prueba.
Revisar las normas, procedimientos, prácticas y tecnologías de AI6.7 Política
gestión del cambio de TI para comprobar que antes de la aproba- de Versión de
ción final, las pruebas hayan demostrado adecuadamente que el Software
cambio no dañará el entorno de producción.
Sólo se imple- Obtener información de control de acceso a los códigos fuente y AI6.6
mentan los cam- ejecutables de producción (una muestra de estos). Comprobar Mantenimiento
bios aprobados. que sólo los responsables de la implementación de los cambios autorizado
puedan modificarlos, añadirlos o eliminarlos.
Revisar las políticas y normas para determinar que se requieran
pistas de auditoría confiables y de fácil revisión de los cambios
operados a los elementos de producción.
Revisar la tecnología de pistas de auditoría y los procesos asocia-
dos. Nadie debe disponer de derechos de acceso permanente
para eliminar o modificar las pistas de auditoría. Estas se deben
administrar para que estén disponibles con el fin de facilitar las
revisiones a corto plazo y para las investigaciones a largo plazo.
Revisar los procedimientos para analizar las pistas de auditoría de
los cambios introducidos a los elementos de producción dentro
del alcance de la auditoría. Comprobar que se requiera revisión
independiente, oportuna, seguimiento de las excepciones y evi-
dencias de la revisión.

35
 GTAG — Apéndice A — Programa de auditoría
de gestión del cambio — 9
Cuadro 3: Programa de auditoría de gestión del cambio de TI (continuación)

Revisar las normas, procedimientos, prácticas, y tecnologías de AI6.3 Control

gestión del cambio para determinar que los controles aseguran de los cambios
que los componentes implementados en la producción coinciden
con los componentes desarrollados, probados y aprobados.

Revisar las normas, procedimientos, prácticas y tecnologías de AI6.3 Control

gestión del cambio para determinar que los controles aseguren de los cambios
que los códigos fuente y ejecutables implementados en la produc-
ción coincidan entre sí.

Los cambios imple- Revisar las políticas, normas y procedimientos de gestión del cam- AI6.1 Inicio y
mentados cumplen bio de TI para determinar si los cambios con costo o riesgo signifi- control de la
con los requerimien- cativos requieren la aprobación de los usuarios del negocio en los solicitud de
tos del negocio. puntos adecuados para ello. cambio

Establecer a través de entrevistas y revisiones de la documenta-

ción, que para cada cambio significativo haya una revisión poste-
rior a la implementación que evalúa su eficacia y lo compare con
el caso de negocio aplicado en la iniciación del cambio.

Es posible Los cambios de TI Revisar las normas, procedimientos, prácticas y tecnologías de ges- AI6.7 Política
que los se implementan tión del cambio de TI para verificar que los controles aseguren: de Versión de
cambios de siguiendo una Software
TI ocasio- secuencia adecuada • Que los cambios se implementen de forma periódica como
nen proble- y sin interferir con versiones y no como modificaciones aisladas al entorno de
mas de otros cambios. producción.
producción.
• Que los cambios que puedan afectarse entre sí estén sincro-
nizados adecuadamente (por ejemplo, que sólo un programa-
dor por vez modifique un módulo dado).

CLos cambios se Se debe comprobar que la gestión del cambio, el control y la dis- AI6.3 Control
implementan de tribución del software se integren de forma adecuada con un sis- de los cambios
forma exacta y tema integral de gestión de configuración.
según lo planeado.
Revisar las políticas, normas y procedimientos de gestión del cam-
bio de TI para asegurar que los cambios documenten de forma ade-
cuada los pasos necesarios para la implementación del cambio.
Verificar que el sistema utilizado para supervisar los cambios intro- AI6.3 Control
ducidos a los sistemas de aplicación sea automático para respal- de los cambios
dar el registro y seguimiento de los cambios efectuados a
sistemas de información amplios y complejos.
Las operaciones de Revisar las políticas, normas y procedimientos de gestión del cam-
TI se pueden recu- bio de TI para verificar que los cambios tengan la documentación
perar de forma efi- adecuada para dejarlos sin efecto , antes de su puesta en escena
ciente y eficaz de los en producción.
problemas relaciona-
dos con el cambio.

Revisar las políticas, normas y procedimientos de gestión del cam- AI6.3 Control
bio de TI para verificar que los cambios documenten exhaustiva- de los cambios
mente qué se cambió, cuándo y quién lo hizo. Todos los cambios
deben contar con una organización exacta en todo momento (por
ejemplo, en su desarrollo, implementación retiro, cancelación, etc.).
Dicha documentación debe ser de una exactitud confiable y de
fácil acceso.

36
GTAG — Apéndice A — Programa de auditoría
de gestión del cambio de TI — 9
Cuadro 3: Programa de auditoría de gestión del cambio de TI (continuación)

Es posible que Los procesos de cam- Revisar las normas y procedimientos de la gestión del
las operaciones bio y de gestión de cambio para comprobar que cada cambio registre de
de producción problemas están inte- forma explícita todos los problemas para cuya solución fue
no se recuperen grados. diseñado.
eficientemente
de los problemas
ocasionados por
los cambios.

Revisar las normas y procedimientos de la gestión del pro-

blema para comprobar que cada problema registre de
forma explícita todos los cambios que hayan originado o
contribuido a dicho problema.

Los cambios que Los cambios de emer- Verificar que las políticas, normas y procedimientos de AI6.4 Cambios
se deben imple- gencia se implementan gestión del cambio de TI establezcan parámetros para de emergencia
mentar más rápi- de tal manera que se definir cambios de emergencia y procedimientos para
damente de lo preservan los controles controlar dichos cambios cuando soslayan el proceso
previsto por el de cambio. normal de evaluación técnica, operativa y de gestión, antes
ciclo normal de de la implementación.
cambio pueden
evitar o compro-
meter los contro-
les de cambio.

Revisar los procedimientos de los cambios de emergencia

para comprobar que se puedan implementar de forma
rápida, eficaz y de manera que se preserve la responsabili-
dad, identificación y revisión independiente.

Seleccione una muestra de cambios de emergencia reali- AI6.4 Cambios

zados durante el plazo de la auditoría y verifique que: de emergencia
• El cambio resultaba necesario por una emergencia
verdadera:
• Se siguieron procedimientos de emergencia.
• La gerencia de TI los registró y autorizó antes de su
implementación.
• Se notificó rápidamente a la gerencia adecuada de las
áreas afectadas.
• Se detectaron los cambios no aprobados y las excep-
ciones se elevaron al nivel correspondiente y se resol-
vieron con premura.
• Todo la limpieza necesaria se realizó con prontitud.
• Los manuales del usuario se actualizaron con los cam-
bios que afectan la interfaz de usuario, el funcionamiento
del programa, la seguridad y otros cambios.

37
 GTAG — Apéndice A — Programa de auditoría
de gestión del cambio de TI — 9

Las Tablas 4 y 5 muestran los roles típicos y los cargos
asociados a estos, además de las obligaciones que no se deben
combinar. Los auditores reconocerán rápidamente los para-
lelos de estas pautas y las pautas típicas del procesamiento de
transacciones. Por ejemplo, aquellos que administran la
infraestructura no deben auditarla. Aquellos que implemen-
tan el cambio no deben aprobarlo. Aquellos que crean la
aplicación no deben probarla, ejecutarla ni operarla.
Como se observó en la Sección 4.5 “Integración de la
Gestión de Parches a la Gestión de Cambio” (página 18),
cuanto más complejo y dinámico es el entorno de produc-
ción de TI, mayor es la necesidad de aplicar controles efica-
ces. Dado que la cantidad de personas que implementan
cambios y las tasas de cambio se incrementan, también lo
hace la necesidad de aplicar monitorización y supervisión
automáticas e independientes.

Cuadro 4: Roles típicos

Roles en el ciclo de vida del cambio Títulos y roles típicos
Solicitante del cambio Unidad de negocio, operaciones de TI, seguridad, gerente de
servicio.
Preparador del cambio Investigación y desarrollo, administrador de bases de datos,
equipo de desarrollo de aplicaciones, programador de apli-
caciones.
Aseguramiento de calidad, equipo de armado y preparación,
equipo de preproducción, equipo de plataforma.
Aprobación del Cambio Gerente del cambio, consejo de asesoramiento para el cam-
bio, comité de control del cambio, dirección de gestión del
cambio.
Implementador del cambio Operaciones de TI, operaciones de redes, ingeniería de
redes, administradores de sistemas, seguridad.
Revisor del cambio Gestión de las operaciones de TI, consejo de asesoramiento
para el cambio, seguridad, auditoría.
Auditoría del cambio Gestión de las operaciones de TI, consejo de asesoramiento
para el cambio, seguridad, auditoría.

Cuadro 5: Separación de funciones

Para cada cambio… Debe ser independiente de…
Los implementadores Los solicitantes
Los operadores del entorno de producción Los preparadores

Los evaluadores Los preparadores

Los implementadores Los preparadores

Por lo menos uno de los responsables de la aprobación Los preparadores

Por lo menos uno de los responsables de la aprobación Los solicitantes
Por lo menos uno de los responsables de la aprobación Los implementadores
Los revisores Los implementadores
El auditor Todos los mencionados precedentemente

Fuentes: COBIT Control Objectives, 3º Edición, julio 2000: Planning & Organization 4 (P04), página 42, ISO/IEC
17799:2001, Auditors Guide, Sección 8.1.4. Segregation of Duties

38
GTAG — Apéndice B — Metodología de Operaciones Visibles — 10
La Metodología de Operaciones Visibles, publicada por el
Instituto de Procesos de TI (ITPI, en inglés), brinda una
orientación para los gerentes de TI sobre cómo desarrollar
procesos auditables y aceleradores en cuatro etapas. En la
primera etapa, se desarrolla un proceso de gestión del cambio
viable atacando a los principales contribuyentes del trabajo
no planeado (por ejemplo, interrupciones autoimpuestas,
períodos de reparación prolongados debido a la ausencia de
información de cambios, etc.). Para “estabilizar al paciente”,
debe hacer lo siguiente:
1. Reducir o eliminar el acceso: Retirar a todos de los
activos a menos que estén autorizados formalmente a
realizar cambios. Dado que estos activos tienen bajas
tasas de éxito del cambio, debemos reducir la cantidad
de reintentos.
a. Documentar la nueva política del cambio:
Nuestra política de cambio recomendada es muy
simple: “No realizar absolutamente ningún
cambio en este activo a menos que yo lo autorice”.
Esta política es nuestro control preventivo y crea
una expectativa de comportamiento.
b. Notificar a las partes interesadas: Una vez
establecida la política de cambio inicial, se debe
notificar a todas las partes interesadas acerca del
nuevo proceso. Asegúrese de que todo el personal
lo vea. Envíelo por correo electrónico al equipo.
Imprímalo. Agréguelo a los carteles de inicio de
sesión. Publíquelo en el sitio Web o en la página
de inicio del portal de Intranet.
2. Electrificar la barrera: Para hacer cumplir el nuevo pro-
ceso de gestión del cambio, debe electrificar la barrera y
asegurarse de que todos los cambios de producción se
detecten y se correlacionen con los cambios autorizados.
Cuando se detectan cambios no autorizados, utilícelos
para reforzar el proceso de cambio y refuércelo constan-
temente. Por ejemplo, “Equipo, quiero ser claro en esto:
estos procesos se desarrollaron para lograr el éxito de
todo el equipo y no sólo el éxito individual. Por lo tanto,
cualquiera que realice un cambio sin autorización soca-
va el éxito del equipo y tendremos que hacer frente a
eso. Como mínimo, tendrá que explicarle a todo el equi-
po por qué realizó un cambio no autorizado. Si esto se
repite, probablemente esa persona quede suspendida por
un día y, con el tiempo, es posible que no sea más parte
de este equipo”.
3. Modificar la primera respuesta: clave para la acelera-
ción: Para garantizar que el proceso de gestión del
cambio le devuelva el valor a la organización, integre
el proceso de gestión del cambio con la función de ges-
tión de problemas. Asegúrese de que los administrado-
res de problemas tengan toda la información
relacionada con el cambio cuando trabajan con los
problemas. Dado que el 80 por ciento de las interrup-
ciones se debe a los cambios y el 80 por ciento del
tiempo promedio de reparación se emplea para inten-
tar descubrir qué cambió, tener a mano esta informa-
ción garantiza que toda la evidencia relevante y causal
esté disponible. Por lo general, cuando se preparan de
esta manera, los administradores de problemas pueden
diagnosticar los problemas con éxito sin tener que
39
iniciar sesión en las infraestructuras más del 50 por
ciento del tiempo.
4. Crear el equipo para llevar a cabo el cambio: En los
pasos anteriores, hemos comenzado a especificar el
camino correcto para el cambio y hemos desarrollado
los mecanismos para garantizar que se siga el proceso.
En este paso, creamos el camino correcto para ir del
cambio deseado al cambio autorizado. Creamos un
Consejo de asesoramiento para el cambio (en inglés,
CAB), compuesto por las partes interesadas relevantes
de cada servicio de TI crítico. Estas partes interesadas
son las personas que están mejor preparadas para tomar
decisiones con respecto a los cambios debido a su
conocimiento sobre los objetivos de negocio y los ries-
gos técnicos y operacionales.
5. Crear un sistema de seguimiento de la solicitud de
cambio: Un requisito previo para cualquier proceso de
gestión del cambio eficaz es la habilidad de rastrear las
solicitudes de cambio (RFC, en inglés) a través del
proceso de autorización, implementación y verifica-
ción. Los sistemas de manuales impresos en papel rápi-
damente se tornan poco prácticos cuando la
organización es grande o compleja o cuando existe una
gran cantidad de cambios. Por eso, la mayoría de los
grupos utilizan medios computarizados para rastrear las
solicitudes de cambio y asignar los números de órdenes
de trabajo. Algunos se refieren a estas aplicaciones
como “sistemas de emisión de boletos” o “sistemas de
flujo del cambio”. Cualquiera sea la manera de rastre-
ar los cambios que adopte, no permita que el uso de la
tecnología suplante la necesidad de un proceso sólido.
6. Inicio de las reuniones semanales sobre gestión de
cambio (para autorizar el cambio) e informes de cam-
bio diario (para anunciar los cambios): Ahora que
hemos identificado las partes interesadas en los cam-
bios mediante la creación de un consejo de asesora-
miento para el cambio, el próximo paso es crear un
foro para que se puedan tomar decisiones sobre los
cambios solicitados. El Consejo de asesoramiento para
el cambio (CAB) autorizará, denegará o negociará un
cambio con el solicitante. Los cambios autorizados se
programarán, se implementarán y, finalmente, se veri-
ficarán. El objetivo es crear un proceso que permita un
rendimiento superior y exitoso del cambio para la
organización con la menor cantidad posible de proce-
sos burocráticos. Si bien puede parecer anormal al
principio, con la práctica, se pueden lograr reuniones
de gestión del cambio de 15 minutos una vez por sema-
na. En especial, trate de evitar la actitud de inmedia-
tez y poca importancia, que hace que las personas
realicen cambios que soslayan el proceso de aproba-
ción del cambio. Si facilitamos el flujo de todos los
cambios a través de nuestro proceso, será más fácil uti-
lizar el proceso que soslayarlo, incluso durante situa-
ciones de emergencia.
La Metodología de Operaciones Visibles lo ayudará a desa-
rrollar un proceso de gestión del cambio sostenible que iden-
tifique y corrija rápidamente las causas de las bajas tasas de
éxito del cambio.
 GTAG — Apéndice C — Ejemplo Práctico de
Negocio para la Gestión del Cambio — 11
Las organizaciones de alto rendimiento utilizan los procesos
de gestión del cambio de TI para reducir los riesgos e incre-
mentar la eficacia y la eficiencia operativas. De esta manera,
los beneficios de los controles eficaces de los cambios son sig-
nificativos y medibles. Ser capaz de demostrar esto facilita la
tarea de desarrollo de un caso de negocio para mejorar los
controles de cambios, a diferencia de hacerlo sólo para “com-
Cuadro 6: Problemas e indicadores de gestión ineficaz del cambio
Nuestros síntomas
“Al igual que muchas organizaciones de TI importantes, está-
bamos experimentando los efectos de los cambios no docu-
mentados. Sabíamos que se estaban produciendo, pero eran
difíciles de rastrear, y en la atmósfera actual, tan consciente de
la seguridad, esto era inaceptable”.
“Cuando se produjeron interrupciones en los sistemas fijos de
transacciones entrantes, la mesa de ayuda fue la primera en
saberlo. Esto llegaba hasta el grupo de gestión de TI, quien
organizaba un equipo de respuesta y reunía los antecedentes
para descubrir lo que había sucedido”.
“Era como en el Lejano Oeste. La gente no documentaba sus
cambios y ni hablar de recibir una aprobación al respecto. Esto
se hacía evidente en nuestras estadísticas de disponibilidad”.
Cuadro 7: Beneficios de una transformación eficaz (basada en los resultados reales informados)
Nuestra solución
“Nos dimos cuenta de que las consecuencias inesperadas de
los cambios representaban el factor que más contribuía a la
generación de trabajo no planeado. Formalizamos la aproba-
ción requerida para realizar los cambios de producción y para
iniciar el proceso. Además “electrificamos la barrera” para
garantizar que se respete el proceso de gestión del cambio”.
“Comenzamos por crear una responsabilidad real en cuanto a
rendición de cuentas para que todos siguieran el proceso de
gestión del cambio. Elegimos nuestras reuniones de gestión
de disponibilidad diaria (en inglés, “reuniones DAMM), presidi-
das por Kenny, nuestro vicepresidente de operaciones. Kenny
revisa todos los cambios fallidos con los implementadores del
cambio y organiza una sesión especial para quienes hayan
omitido el proceso de gestión del cambio. Digamos simple-
mente que los cambios no autorizados y los de tipo subrepti-
cio se producen con mucha menos frecuencia”.
40
placer a la auditoría”. Como se describió en las secciones
anteriores, las mediciones operacionales clave están com-
puestas por la tasa de fallos del cambio, el tiempo de recupe-
ración en caso de cambios fallidos y el trabajo no planeado
resultante. El Cuadro 6 resume los indicadores de la gestión
ineficaz del cambio. El Cuadro 7 describe las maneras de
solucionar esto en función de la experiencia real en campo.
Causas subyacentes
Niveles de servicio y disponibilidad deficientes.
Cantidad no conocida de cambios operativos.
Tasa de cambio no controlada.
Tasas de éxito del cambio bajas (inferiores a 70%).
Grandes cantidades de trabajo no planeado (inferior a 40%).
Cuando los cambios fallaban, la investigación de las causas y
la gestión de los problemas insumían más del 25% de la carga
de trabajo.
Un diagnóstico inexacto conduce a una tasa de resolución
de problemas en primera instancia baja (en inglés, FFR,
inferior a 50%).
La ausencia de controles de detección en los procesos de
gestión del cambio genera un rendimiento deficiente.
La ausencia de los controles de cambio impide la prueba de
los controles preventivos y de detección para que los audito-
res puedan certificar que los controles son eficaces.
Ventajas
Mejor visibilidad de la gestión de los cambios propuestos.
Los cambios operativos son sólo los autorizados por el proce-
so de gestión del cambio.
Un mayor control de la tasa de cambio puede generar incre-
mentos en la tasa de éxito del cambio de hasta un 95% debi-
do a la visibilidad y las pruebas.
(Este negocio en particular calcula el tiempo de inactividad a
$7.000 por minuto).
La cantidad de cambios no autorizados se redujo de “varios al
día” a “varios al año”. Dado que cada interrupción requería dos
horas para restablecer el servicio (un cálculo bastante conser-
vador), se destinaban 5.000 horas de trabajo, teniendo en
cuenta una base anual.
Todos los cambios se documentan por completo, lo cual per-
mite que se descarte el cambio en primer lugar en el ciclo de
reparaciones, permitiendo que el tiempo de restauración pase
de “horas” a “minutos”. Para las 11 interrupciones producidas
en Q3, se ahorraron aproximadamente 13 horas de tiempo de
interrupción del sistema.
GTAG — Apéndice C — Ejemplo Práctico de
Negocio para la Gestión del Cambio — 11
Cuadro 7: Beneficios de una transformación eficaz (basada en los resultados reales informados) (continuación)
Nuestra solución
“Nos dimos cuenta de que las consecuencias inesperadas de
los cambios representaban el factor que más contribuía a la
generación de trabajo no planeado. Deseábamos aplicar
mejor nuestras normas y poder eliminar el tiempo destinado
al trabajo de detección.
“Es más, la preparación para las auditorías pasó de represen-
tar cuatro semanas de trabajo al año por cada proyecto a
estar listo para cada auditoría en menos de medio día.
“Por último, solíamos tener tres equipos de cumplimiento dife-
rentes: uno para el Artículo 404 de la Ley Sarbanes-Oxley,
otro para la Ley Gramm-Leach Bliley y otro más para la Ley
de Responsabilidad y Portabilidad del Seguro de Salud.
Cuando nos dimos cuenta de que todas ellas requerían la pre-
paración eficaz de reportes de controles de cambio, reempla-
zamos todos esos equipos por uno solo encargado del
cumplimiento de las tres leyes”.
“Además de que todos nosotros ya no tenemos que usar los
localizadores en nuestros hogares, hemos descubierto que
disponemos de más tiempo para trabajar en los proyectos
planeados, en lugar de estar apagando incendios todo el
tiempo”.
41
Ventajas
El cumplimiento de las normas se maneja ahora como un
tema cotidiano, en lugar de una preparación de último minuto
en el borde del colapso.
Dado que la prueba de controles de cambio eficaces se gene-
ra con regularidad, los auditores externos no generaron cartas
con comentarios para la gerencia (en comparación con el año
pasado, se evitaron 130 horas de trabajo no planeado y de
honorarios de auditoría al respecto).
El mapa de los controles de cambio en función de los requeri-
mientos regulatorios ordinarios reduce la cantidad de trabajo
duplicado que hacen los equipos por separado. Se ha reasig-
nado a doce miembros del personal de TI al equipo de opera-
ciones de TI.
El trabajo no planeado se redujo de más de un 40% a un 15%.
Las entregas puntuales de los proyectos pasaron de cero a
un 60%.
El Director de TI (CIO) le ha asignado al grupo de gestión de TI
los proyectos estratégicos clave para el año siguiente.
 GTAG — Apéndice D — Herramientas de la Gestión
del Cambio y Proveedores — 12

A continuación se presentan algunas de las herramientas

más utilizadas para automatizar los procesos descritos en esta
guía:
• Visible Ops Handbook: Starting ITIL in Four Practical
Steps.
• Flujo de gestión del cambio (control preventivo).
– BMC/Remedy Action Request System.
(http://www.remedy.com/solutions/coretech/
index.html)
– HP Service Desk.
– (http://managementsoftware.hp.com/products/
desk/index.html).
• Auditoría y supervisión de cambios (control de detección).
– Tripwire for Servers and Networking Devices
(http://www.tripwire.com)

42
GTAG — Guía de Auditoría de Tecnología Global Referencias — 13
El material para el ejemplo de la guía de auditoría presenta-
do en el Apéndice A se extrajo, en parte, de http://audit-
net.org/asapind.htm.
[Allen 04] Allen, Julia; Behr, Kevin; Kim, Gene et al.
Best in Class Security and Operations Round Table Report
(CMU/SEI-2004-SR-002). Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University, Marzo
de 2004. Disponible mediante solicitud.
[BDO 04] BDO Seidman LLP, et al. A Framework for
Evaluating Control Exceptions and Defiencies. BDO Seidman
LLP, Crowe Chizek and Co. LLC, Deloitte & Touche LLP,
Ernst & Young LLP, Grant Thornton LLP, Harbinger PLC,
KPMG LLP, McGladrey & Pullen LLP,
PricewaterhouseCoopers LLP, 20 de diciembre de 2004.
Disponible en varios sitios incluido
http://www.kpmg.com/Rut2000_prod/Documents/9/US_DP
P_ICOFR_04_024_A01.pdf.
[BITS 04] BITS Financial Services Roundtable. Patch
Management Best Practices for IT Service Providers. BITS,
julio de 2004. Disponible en http://www.bitsinfo.org/bits-
patchmgmt2004.pdf
[Chambers 03] Chambers, Andrew. Tolley's Corporate
Governance Handbook: 2nd Edition, Appendix B: Fraud.
Lexis Nexis, 2003.
[CISWG 04] Corporate Information Security Working
Group. Subcommittee on Technology, Information Policy,
Intergovernmental Relations & the Census Government
Reform Committee, U.S. House of Representatives. Report
of the Best Practices and Metrics Teams. 17 de noviembre de
2004. Disponible mediante solicitud.
[COSO 04] The Committee of Sponsoring
Organizations of the Treadway Commission. Enterprise Risk
Management - Integrated Framework. Septiembre de 2004. El
resumen ejecutivo y la información de solicitud están dispo-
nibles en http://www.coso.org.
[Gartner 03] Series on Change Management:
• Brittain, Kris. Change Management Makes an
Impact on IT Service Quality. Note AV-19-3311,
Gartner, 13 de marzo de 2003.
• Scott, Donna; Brittain, Kris. Defining IT Change
Management. Research Note COM-19-1428,
Gartner, 6 de marzo de 2003.
• Brittain, Kris; Scott, Donna. Critical Factors
Powering Operational Change Management.
Research Note DF-18-4179, Gartner, 4 de marzo
de 2003.
• Scott, Donna; Brittain, Kris. Best Practices for
Operational Change Management. Commentary
COM-19-1253, Gartner, 6 de marzo de 2003.
• Brittain, Kris; Scott, Donna. Governance/Policy
Back Operational Change Management.
Commentary COM-18-4180, Gartner, 6 de marzo
de 2003.
[Gall 86] Gall, John. Systemantics: The Underground
Text of Systems Lore, General Systemantics Press, 1986.
[Goldratt 92] Goldratt, Eliyahu; Cox, Jeff. The Goal: A
Process of Ongoing Improvement, 2nd Rev edition, North River
Press, mayo de 1992.
43
[Hulme 04] Hulme, George. “Federal CISOs Rank
Patch Management As Biggest Obstacle.” InformationWeek,
22 de noviembre de 2004. Disponible en http://information-
week.com/story/showArticle.jhtml?articleID=53701321.
[ITIL 00] Information Technology Infrastructure
Library (ITIL)®14. Office of Government Commerce. Vaya
a http://www.ogc.gov.uk/index.asp?id=2261 y
http://www.itsmf.com. Consulte específicamente Best
Practice for Service Support, Capítulo 8 Change Management
(2000).
[ITPI 04] Behr, Kevin; Kim, Gene; Spafford, George.
Visible Ops Handbook: Starting ITIL in Four Practical Steps. IT
Process Institute, 2004. La información de presentación y
solicitud está disponible en http://www.itpi.org.
[Kim 03] Kim, Gene. “High-Performing IT Operations
and Security Workshop Findings: Part 1.” ComputerWorld,
diciembre de 2003. Disponible en http://www.computer-
world.com/securitytopics/security/story/0,10801,91205,00.ht
ml?nas=SEC2-91205.
[Mair 73] Mair, William; Wood, Donald; Davis, Keagle.
Computer Control and Audit. Touche Ross & Co., 1972,
1973, 1976 y 1978. Distribuido anteriormente por The
Institute of Internal Auditors, Inc. Ya no se encuentra dispo-
nible en formato impreso.
[O’Reilly 98] O’Reilly, Vincent; McDonnell, Patrick;
Winograd, Barry; Gerson, James; Jaenicke, Henry.
Montgomery's Auditing, 12th Edition. Wiley, 1998.
[PWC 04] PriceWaterhouseCoopers. The Discipline of
Enterprise Patch Management: A Critical Component of a
Broader Approach to Protection, 2004. Disponible en
http://www.pwcglobal.com/extweb/manissue.nsf/DocID/5BF8D
134DFEE39A385256E5F006A0F89.
[Salamasick 03] Salamasick, Mark. PC Management
Best Practices - A Study of the Total Cost of Ownership, Risk,
Security, and Audit. The Institute of Internal Auditors
Research Foundation, Noviembre de 2003. La información
de solicitud está disponible en
http://www.theiia.org/iia/bookstore.cfm?fuseaction=pro-
duct_detail&order_num=482.
[Tipton 00] Tipon, Hal, Miki Kraus.
Handbook Information Security Management. Auerbach
Publications, 2000.
 GTAG — Guía de Auditoría de Tecnología
Global — Acerca de los autores — 14
Julia H. Allen es miembro superior del personal técnico del
programa Networked Systems Survivability en el Instituto
de Ingeniería de Software (SEI, en inglés), una unidad de la
Universidad Carnegie Mellon en Pittsburgh, Pensilvania. El
centro de coordinación CERT® también forma parte de este
programa.
Allen participa en el desarrollo y transición de los enfoques
de seguridad empresarial y los programas de alcance ejecuti-
vo en la seguridad y dirección empresarial. Con anterioridad
a esta asignación técnica, Allen se desempeñó como directo-
ra suplente del SEI durante un período interino de seis meses
y como vice directora/directora de operaciones durante tres
años. Posee el título de Licenciada en Ciencias de la
Computación (Universidad de Michigan) y una Maestría en
Ingeniería Eléctrica (Universidad de Southern California).
Es autora de The CERT Guide to System and Network
Security Practices (Addison-Wesley, Junio de 2001).
Información de contacto:
Carnegie Mellon University
Software Engineering Institute
4500 Fifth Ave.
Pittsburgh, PA 15213 Estados Unidos
jha@sei.cmu.edu, jha@cert.org
Glenn L. Hyatt, CIA, CISA, CISSP es gerente de seguri-
dad de datos en General Motors Acceptance Corp.
(GMAC) Mortgage, donde administra las operaciones e
investigaciones de seguridad de la información. Hyatt se ha
desempeñado durante más de 20 años en cargos relacionados
con TI, desde programador hasta gestión de seguridad de la
información, consultoría de TI y gerencia de auditoría de TI.
Anteriormente trabajó en Federal Reserve Bank of
Philadelphia, Citibank y Ernst & Young. Posee una Maestría
en Ciencias de la Computación e Información de la
Universidad de Delaware.
Información de contacto:
GMAC Mortgage
4 Walnut Grove Dr., 190-400-215
Horsham, PA 19044 Estados Unidos
+1-215-682-3424
Glenn.Hyatt@gmacm.com
Gene H. Kim, CISA, es el director de tecnología (en inglés,
CTO) y fundador de Tripwire Inc. En 1992, fue coautor de
Tripwire mientras estaba en la Universidad de Purdue con el
Dr. Gene Spafford. En el año 2004, escribió The Visible Ops
Handbook y cofundó el Instituto de Procesos de TI, dedicado a
la investigación, comparación y desarrollo de orientación
prescriptiva para los auditores y la gestión de seguridad y ope-
raciones de TI. Actualmente trabaja, de manera activa, con el
Instituto de Ingeniería de Software y el Instituto de Auditores
Internos para investigar cómo las mejores organizaciones inte-
gran las operaciones de TI, la seguridad, la administración, la
dirección y el trabajo de auditoría para alcanzar los objetivos
comunes del negocio. Actualmente, Kim participa de la
Comisión de Tecnología Avanzada del IIA.
Kim posee una Maestría en Ciencias de la Computación de
la Universidad de Arizona y es Licenciado en Ciencias de la
Computación de la Universidad Purdue. Recientemente,
44
Kim fue nombrado uno de los “Top 4 CTOs to Watch” por
la revista InfoWorld debido a sus “actividades de vanguardia
y de avanzada”. También fue uno de los presidentes del taller
técnico de SANS en abril del 2003, denominado Auditable
Security Controls That Work y considerado por SANS
como uno de los cinco regalos más importantes a la comuni-
dad y una de las principales iniciativas del 2003. Kim fue uno
de los presidentes de Best in Class Security and Operations
Roundtable (BIC-SORT) junto con el Instituto de
Ingeniería de Software en octubre de 2003. Kim posee certi-
ficaciones en procesos de auditoría y gestión de TI, tanto de
ITIL Foundations como de CISA.
Información de contacto:
Gene Kim
Tripwire Inc.
326 SW Broadway Ave., 3rd Floor
Portland, OR 97205 Estados Unidos
+1-503-276-7676
genek@tripwire.com
Jay R. Taylor, CIA, CFE, CISA, es director general de
Auditoría de Tecnología de Información de General Motors
Corp. y es el responsable de evaluar los riesgos y proporcionar
auditoría interna global y servicios de consultoría con respec-
to a las unidades de negocio e inversiones conjuntas de
General Motors y General Motors Acceptance Corp. en todo
el mundo. GM opera en un entorno sumamente complejo uti-
lizando numerosos proveedores de TI de todo el mundo.
Taylor obtuvo su Maestría en Administración de Empresas
(MBA) en la Universidad de Michigan y trabaja activamente
en el Comité Internacional de Tecnología de Avanzada del
Instituto de Auditores Internos. Anteriormente, trabajó en el
Comité Internacional de Productos Educativos del IIA y fue
presidente del Capítulo de Mid-Michigan del IIA y miembro
de la Junta de Gobierno del Capítulo de Detroit. Sus contri-
buciones profesionales recientes incluyen presentaciones rea-
lizadas en la Conferencia sobre la Gestión del Riesgo
Empresarial del IIA y en la Conferencia sobre Prácticas de
Liderazgo y Tendencias Emergentes del IIA, ambas realizadas
en el año 2004.
Información de contacto:
General Motors Corp.
300 Renaissance Center
Mail Code 482-C18-B76
Detroit, MI 48265-3000 Estados Unidos
+1-313-665-3700
jay.r.taylor@gm.com
 GTAG — Equipo de Revisión de Proyecto

Equipo de Revisión de Proyecto

Charlie LeGrand, CHL Associates
Claude Cargou, AXA
Norman Marks, Maxtor
Warren Malmquist, Coors
Larry Brown, Options Clearing Corporation
Michael Prospect, SIAC
Jennifer Bayuk, Bear Stearns
Rod Brennan, Siemens
Angelina Chin, General Motors Corporation
Clint Kreitner, Center for Internet Security
Jon Stanley, General Motors Corporation
Ed Hill, Protiviti
Mark Salamasick, Universidad de Texas
Sydney Leo, KPMG
Matt Snyder, General Motors Corporation
Bill Shinn, Washington Mutual
James Christiansen, Experian
Carol Woody, Universidad Carnegie Mellon, Instituto de Ingeniería de Software
Stuart M.McCubbrey, General Motors Corporation
Controles de gestión de parches y cambios
Esta guía fue desarrollada para ayudar a los DEA a realizar las preguntas de
TI correctas a la organización a evaluar su capacidad de gestión de cambio.
Describe las fuentes de cambio a su probable impacto sobre los objetivos de
negocio, así como también de qué manera los controles de gestión de parche
y cambios ayudan a gestionar los riesgos y costos de TI.

¿Qué es GTAG?
La Guía de Auditoría de Tecnología Global (GTAG) ha sido preparada por
el Instituto de Auditores Internos y está escrita en un lenguaje de negocios
claro y directo para abordar temas de actualidad relacionados con la gestión,
el control o la seguridad de la tecnología de la información. GTAG es una
colección de recursos lista para ser utilizada por los directores ejecutivos de
auditoría en la educación de los miembros del Consejo de Administración y
del Comité de Auditoría, Dirección, propietarios de los procesos y otros en
lo que respecta a riesgos asociados a la tecnología y prácticas recomendadas.

www.theiia.org