Gestión de la auditoría de

tecnología de la información
 Guía de Auditoría de Tecnología Global

Gestión de auditoría de tecnología de la información

Autor
Michael Juergens, Principal, Deloitte & Touche LLP

Autor colaborador
David Maberry, Senior Manager, Deloitte & Touche LLP

Colaboradores editoriales
Eric Ringle, Gerente Superior, Deloitte & Touche LLP
Jeffrey Fisher, Gerente Superior, Deloitte & Touche LLP

Marzo 2006

Copyright © 2006 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 infor-
mació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.
GTAG — Índice

1. Resumen ejecutivo … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …1
2. Introducción … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …2
3. Definición de TI … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …4
3.1 Gestión de TI … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …5
3.2 Infraestructura técnica … … … … … … … … … … … … … … … … … … … … … … … … … … … … …5
3.3 Aplicaciones … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …6
3.4 Conexiones externas … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …6
4. Los riesgos asociados a TI … … … … … … … … … … … … … … … … … … … … … … … … … … … … …7
4.1 La teoría del “copo de nieve” (Snowflake Theory) … … … … … … … … … … … … … … … … … … … …7
4.2 La evolución del riesgo … … … … … … … … … … … … … … … … … … … … … … … … … … … … …7
4.3 Proliferación de los riesgos asociados a TI … … … … … … … … … … … … … … … … … … … … … … …8
4.4 Tipos de riesgos de TI … … … … … … … … … … … … … … … … … … … … … … … … … … … … …8
4.5 Evaluación de los riesgos de TI … … … … … … … … … … … … … … … … … … … … … … … … … …9
5. Definición del universo de auditoría de TI … … … … … … … … … … … … … … … … … … … … … … … …11
5.1 Consejos para el DEA … … … … … … … … … … … … … … … … … … … … … … … … … … … … …11
5.2 Realizar el presupuesto de auditoría de TI … … … … … … … … … … … … … … … … … … … … … … …12
6. Realización de la auditoría de TI … … … … … … … … … … … … … … … … … … … … … … … … … … …13
6.1 Estructuras y normas … … … … … … … … … … … … … … … … … … … … … … … … … … … … …13
6.2 Gestión de los recursos de auditoría de TI … … … … … … … … … … … … … … … … … … … … … …15
7. Aceleradores de la auditoría de TI … … … … … … … … … … … … … … … … … … … … … … … … … …18
7.1 Facilitadores de auditoría … … … … … … … … … … … … … … … … … … … … … … … … … … … …18
7.2 Aceleradores para pruebas … … … … … … … … … … … … … … … … … … … … … … … … … … … …18
8. Preguntas para el DEA … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …21
Apéndice A: Temas emergentes … … … … … … … … … … … … … … … … … … … … … … … … … … … …22
A.1 Redes inalámbricas … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …22
A.2 Dispositivos móviles … … … … … … … … … … … … … … … … … … … … … … … … … … … … …22
A.3 Interfaces … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …23
A.4 Gestión de datos … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …23
A.5 Privacidad de datos … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …24
A.6 Separación de funciones … … … … … … … … … … … … … … … … … … … … … … … … … … … …24
A.7 Acceso administrador … … … … … … … … … … … … … … … … … … … … … … … … … … … … …25
A.8 Controles configurables … … … … … … … … … … … … … … … … … … … … … … … … … … … …26
A.9 Piratería … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …27
Otros recursos … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …27
Notas sobre los autores de esta guía … … … … … … … … … … … … … … … … … … … … … … … … … … … …29
 GTAG — Resumen ejecutivo — 1

La tecnología de la información (TI) está modificando la tos emergentes proporcionará datos específicos de
naturaleza de la función de la auditoría interna. A medida algunas de las tecnologías emergentes, la evaluación de
que surgen nuevos riesgos, se requieren nuevos procedimien- los riesgos que ellas pueden representar para la organi-
tos para gestionarlos adecuadamente. Esta guía ha sido crea- zación, y las recomendaciones sobre cómo debe el
da para asistir al Director Ejecutivo de Auditoría Interna DEA responder a dichos riesgos.
(DEA) en la planificación y gestión de la función de audi-
toría de TI con mayor eficacia y eficiencia, y contempla lo Esta guía está enfocada para proporcionar información
siguiente: pragmática en un lenguaje claro, con recomendaciones
Definir la TI – ¿Qué áreas se deben tener en cuenta para específicas que pueden ser implementadas de forma inmedi-
incluir en el plan de auditoría de TI? El DEA debe ata. Contempla además las preguntas que pueden surgir por
poder medir el alcance de la auditoría de TI previsto parte del DEA para determinar si la función de auditoría de
contra las pautas presentadas aquí para asegurar que el TI que gestiona es de alto rendimiento.
alcance de los procedimientos de auditoría de TI es
adecuado.
Evaluar los riesgos asociados a la TI – Está claro que la
evolución de la TI conlleva nuevos riesgos para la
organización. Esta guía asistirá a la dirección ejecutiva
de auditoría interna a determinar la mejor manera de
identificar y cuantificar los riesgos relacionados con la
TI. Esto les ayudará a asegurarse de que los proced-
imientos y recursos de auditoría de TI se centren en las
áreas que representan el mayor riesgo para la organi-
zación.
Definir el universo de auditoría de TI – Normalmente
los recursos para la auditoría de TI son escasos, y los
requerimientos de auditoría de TI son sustanciales. La
sección para la definición del universo de auditoría
puede ayudar al DEA a comprender cómo construir un
plan de auditoría de TI que logre un equilibrio entre
las necesidades de auditoría de TI y las limitaciones de
los recursos.
Ejecutar la auditoría de TI – La proliferación y comple-
jidad de la TI provoca la necesidad de elaborar nuevos
procedimientos de auditoría de TI.

La realización de auditorías mediante cuestionarios o

entrevistas probablemente sea insuficiente. Este documento
ofrece orientaciones específicas para la dirección ejecutiva
de auditoría interna sobre la manera de llevar a cabo los pro-
cedimientos de auditoría de TI y cómo determinar qué nor-
mas y marcos de referencia existen en el mercado que
puedan respaldar los procedimientos requeridos
Gestionar la función de auditoría de TI – La gestión de
la función de auditoría de TI requiere nuevas técnicas
y procedimientos de gestión. Esta guía proporciona
consejos y técnicas útiles que pueden ayudar a maxi-
mizar la efectividad de la función de auditoría de TI y
la gestión de sus recursos.
Abordar los temas emergentes – La TI evoluciona con
rapidez. Esta evolución puede introducir nuevos ries-
gos importantes para la organización. La dirección
ejecutiva de auditoría interna de primer nivel centra
su atención sobre la auditoría de TI no sólo en la
estructura básica de la TI, sino también en las tec-
nologías nuevas y emergentes. La sección de los aspec-

1
GTAG — Introducción — 2
No cabe duda de que la TI modifica la naturaleza de la fun-
ción de auditoría interna. Los riesgos a los que se enfrenta
una organización, los tipos de auditoría que deben realizarse,
la manera de priorizar el universo de auditoría y la forma de
presentar resultados acertados son las cuestiones que los
DEA deben abordar. No obstante, sin una experiencia técni-
ca profunda puede resultar un gran reto hallar las respuestas
a estas y otras preguntas.
Esta Guía de Auditoría de Tecnología Global (GTAG)
está dirigida a los DEA y a los gerentes de auditoría interna
responsables de la supervisión de la auditoría de TI. El obje-
tivo de esta guía es asistir en la clasificación de aspectos
estratégicos de la planificación de la auditoría de TI, así
como en la realización y elaboración de informes. Se con-
templan los aspectos básicos además de los emergentes.
Crece la importancia de la auditoría de TI principal-
mente porque las organizaciones dependen cada vez más de
la tecnología de la información. Sus procesos clave están
automatizados o son factibles gracias a la tecnología. Existe
la posibilidad de que un pedido entre por un sitio Web, se
transmita al almacén y se envíe al cliente sin que nadie a
excepción del empleado de almacén vea o toque dicho pedi-
do.
A medida que las organizaciones aumentan su depen-
dencia en la TI, surgen dos asuntos de importancia:
• Probablemente un alto porcentaje de los controles
internos claves para la organización son promovidos
por la tecnología. Por ejemplo: la política de la empre-
sa dicta que antes de realizar cualquier pago a un
proveedor se debe realizar una triple comprobación:
históricamente esta comprobación la realizaba un
empleado que físicamente comprobaba los documen-
tos en papel, los grapaba y luego los archivaba.
Actualmente, esas comprobaciones son realizadas por
el sistema de planificación de recursos empresariales
(ERP, en inglés) de la empresa. Este sistema realiza
automáticamente la comprobación en base a una pre-
configuración de reglas y niveles de tolerancia, y
automáticamente contabiliza las diferencias en unas
cuentas definidas para las variaciones. Para auditar este
control de forma efectiva, un auditor debe ingresar a
los parámetros del sistema ERP para evaluar las reglas
y tal configuración. Esto requiere habilidades y proced-
imientos de auditoría totalmente distintos a los que se
aplicaban en el proceso histórico. Para realizar la audi-
toría de forma efectiva será necesario rediseñar el
enfoque histórico de auditoría para abordar los nuevos
riesgos. Todo esto requiere centrar la atención en la
tecnología de auditoría y comprender todo con respec-
to a ella
• Los sistemas que no poseen integridad o contiene
deficiencias de control tendrán un mayor impacto en
las operaciones de la organización así como en su
preparación para competir, lo cual aumenta la necesi-
dad de controles efectivos de TI. Por ejemplo: con-
2
sidere el proceso anteriormente descrito, donde se
recibe el pedido a través de un sitio Web y es transmi-
tido por el sistema ERP directamente al almacén.
Ahora bien, considere qué pasa cuando un cliente, por
error, hace un pedido de 100 palés en lugar de 100
unidades. Si la empresa ha optimizado por completo
sus procesos con el sistema ERP, es posible que el sis-
tema compruebe el inventario y cuando vea que los
100 palés no se encuentran disponibles, proceda a
actualizar el plan de producción para producir dichos
palés, enviando automáticamente los pedidos de mate-
ria prima a través del sistema de intercambio electróni-
co de datos (EDI, en inglés). Potencialmente existe la
posibilidad de que no se detecte el error hasta que el
cliente reciba su pedido, momento en que ya es
demasiado tarde.
Claramente, para mitigar los riesgos de este tipo, la orga-
nización debe llevar a cabo un plan de TI adecuadamente dis-
eñado que contemple los aspectos de este tipo.
Desafortunadamente, la mayoría de las organizaciones han
migrado a entornos altamente automatizados en los últimos
diez años o menos. Como consecuencia de ello, es posible que
no exista tradicionalmente un enfoque amplio sobre las tec-
nologías de auditoría, ni que existan bases sólidas de liderazgo
de procesos en relación a cómo auditar las tecnologías. Esto se
debe en parte al ritmo acelerado de los avances tecnológicos.
Durante muchos años no ha habido avances importantes en la
triple comprobación; sin embargo, las aplicaciones que sopor-
tan dichos procesos evolucionan anualmente.
Un tema adicional que surge con frecuencia, cuando se
planifica el universo de auditoría de TI, se refiere a la verdadera
comprensión de la forma en que los controles de TI se relacio-
nan con la información financiera, los fraudes y otros asuntos
clave. Esto se puede percibir fácilmente cuando se evalúan los
controles dentro de un sistema de aplicación (por ejemplo: los
parámetros de la triple comprobación anteriormente comenta-
dos). Sin embargo, es mucho más difícil cuando se evalúan las
tecnologías que dan soporte. Si se supone que una empresa
mantiene una conexión a Internet, pero carece de filtros de
seguridad para proteger la red interna, ¿la información
financiera es incorrecta? ¿las operaciones se han visto afec-
tadas? Es cada vez más difícil realizar una correlación directa a
medida que existe mayor distancia entre la tecnología y las
operaciones del negocio.
Dada esta situación, muchos DEA a menudo prestan
menos atención a dichas tecnologías de soporte, lo cual puede
representar una visión un tanto miope de los riesgos de TI. La
realidad es que las deficiencias de control en las tecnologías de
soporte pueden tener un impacto mucho mayor sobre la orga-
nización que los controles específicos de TI con respecto a un
determinado proceso.
Por ejemplo, supongamos que una organización crea un
proceso de pagos electrónicos para envíos a sus proveedores.
Dichos pagos se envían electrónicamente a las cuentas bancar-
 GTAG — Introducción — 2

ias empleando los códigos asignados a cada cuenta de provee-

dor del sistema de compensación electrónica (ACH, en
inglés). Todos estos códigos están almacenados en algún lugar
dentro de una tabla en el sistema de base de datos de la orga-
nización. Un administrador de base de datos, o cualquier otra
persona con derechos de acceso a la base de datos, podría fácil-
mente modificar todos los códigos de la tabla por el ACH de
su cuenta personal. La siguiente vez que se ejecutase la función
de pagos, todos los pagos de esa sesión se depositarían en la
cuenta del autor del fraude. Esto burlaría completamente todos
los mecanismos de seguridad, control y pistas de auditoría que
existan en los procesos y aplicación del negocio, incluidos los
pagos auténticos.
En las situaciones anteriormente descritas se puede ver
fácilmente cómo una deficiencia de control a nivel de base de
datos puede tener un impacto mucho mayor que una deficien-
cia en los parámetros de la triple comprobación. Por esta razón,
los DEA deben considerar cuidadosamente todos los niveles
del entorno de TI a la hora de planificar el universo de audi-
toría para el año..

3

Uno de los primeros retos al que se enfrenta el DEA, al
desarrollar el plan anual de auditoría de TI, está en la defini-
ción de las fronteras de TI. ¿Los sistemas de teléfono y men-
sajería de voz son parte de TI? ¿Se deben incluir credenciales
de identificación y sistemas físicos de seguridad? ¿Qué pasa si
estos procesos se externalizan a una empresa que gestiona las
instalaciones? Estos son algunos de los asuntos que los DEA
deben tratar al intentar determinar cómo distribuir los recur-
sos de auditoría de TI.
La realidad es que la TI representa cosas diferentes para
las distintas organizaciones. Aún cuando dos empresas estén
en el mismo sector, pueden tener entornos tecnológicos rad-
icalmente diferentes. Desafortunadamente, qué es la TI o lo
que debe ser no está claro ni universalmente definido.
Esta sección asistirá al DEA en la manera de considerar
la TI dentro de una organización. Si se reconoce que existe
una alta heterogeneidad en los entornos de TI, una manera
en que el DEA puede enfocar la definición de la TI es con-
siderarla por capas o niveles, como si fuera un parfait. Cada
capa o nivel es distinto e importante. Existen riesgos en cada
nivel del entorno, que varían de forma significativa. La
piratería informática del sitio Web corporativo representa un
riesgo muy distinto del que corresponde al robo cometido en
la ejecución del sistema de pagos anteriormente comentado.
Considerar cada nivel
Para que sea efectiva una función de auditoría de TI,
será necesario considerar los riesgos de cada nivel y priorizar-
los, además de asignar recursos de auditoría para cada uno de
esos niveles. Si el plan de auditoría de TI no contempla audi-
torías para cada nivel del entorno, es probable que el plan
Clientes
Transaccional
Soporte
Aplicaciones
Infraestructura técnica
Gestión de TI
Figura 1 · Entorno de TI
4
GTAG — Definición de TI — 3
global no aborde el riesgo de TI de la organización de forma
adecuada.
Se puede señalar que en algunos casos será más apropia-
do considerar todos los niveles durante un período de tiem-
po (es decir, durante varios años en forma rotativa), en lugar
de abarcar todos los niveles durante un solo año. Las empre-
sas u organizaciones privadas que no estén sujetas al
cumplimiento de la Ley Sarbanes-Oxley de 2002 de Estados
Unidos, o a otros controles regulatorios o legales, como la
denominada Ley de Mejoras de la Corporación Federal de
Seguro de Depósitos (FDICIA, en inglés), podrán optar por
establecer un plan que cubra el universo de auditoría de TI
dentro de un período de dos o tres años. Es probable que los
planes rotativos que superen los dos o tres años sean inade-
cuados dado el alto ritmo de cambio en el entorno de TI.
¿Cuántos recursos se deben asignar a cada nivel?
¿Dónde se deben asignar dentro de cada nivel? Las respues-
tas a estas inquietantes preguntas deben ser el resultado nat-
ural de los procesos de análisis de riesgos en combinación
con el juicio y la visión estratégica del auditor. Todos los
niveles deberán tenerse en cuenta sin reparar en la asi-
gnación específica de los recursos.
¿Cuáles son los niveles?
La Figura 1 presenta una descripción sencilla de un entorno
de TI. Está claro que cada organización es distinta, aunque
este gráfico debería cubrir la mayoría de los sistemas críticos
de gran parte de las organizaciones. Los niveles claves a con-
siderar son los siguientes:
• Gestión de TI
• Infraestructura técnica
Proveedores
GTAG — Definición de TI — 3
• Aplicaciones
• Conexiones externas
Hay que tener en cuenta que este gráfico no define las
clasificaciones dentro de un plan de auditoría de TI. Cuando
se planifican auditorías específicas de TI, éstas se pueden
organizar en categorías según los procesos de la organización,
o en forma de estructuras estandarizadas, etc. Este gráfico se
ha diseñado para estimular la reflexión del DEA con respec-
to al entorno de TI para que asegure que se asignen recursos
de auditoría a cada nivel. La organización de cada auditoría
se deja al criterio del DEA.
3.1 Gestión de TI
Este nivel incluye el conjunto de las personas, políticas,
procedimientos y procesos que gestionan el entorno de TI.
Las tecnologías se pueden implementar, por ejemplo, una
organización podrá implementar un sistema ERP como
SAP en un entorno Unix, pero la integridad de los sistemas
y datos depende significativamente de las tareas específicas
realizadas regularmente por el personal administrativo. Por
lo tanto, este nivel incluye:
Supervisión del Sistema – La supervisión incluye la iden-
tificación de transacciones que no se han contabilizado
debido a un error de proceso, o la detección cuando una
base de datos se ha corrompido.
Programación– En muchas organizaciones se realiza la
programación interna para varios sistemas. Esto se
debe gestionar y supervisar de tal manera que los pro-
gramas que contengan errores no causen un impacto
sobre la integridad de los sistemas clave.
Planificación – El departamento de TI debe desarrollar
planes estratégicos de TI a largo y a corto plazo. Estos
deben estar en línea con los planes de la organización
en los mismos plazos. Ante la ausencia de un plan
estratégico de TI adecuado, no se podrá garantizar que
la TI se alinee con los objetivos globales de la organi-
zación, tomados como un todo
Gestión de la externalización de servicios – En muchas
organizaciones se externalizan varios o todos los com-
ponentes del entorno de TI a un proveedor externo.
En tales situaciones, la gestión efectiva de esta relación
es un elemento crítico para asegurar la integridad del
entorno informático.
Gobierno de TI– Establecer pautas sólidas en el más alto
nivel para el diseño, la construcción y la explotación
de los sistemas de TI con integridad; comunicar dicha
cultura a toda la función de TI; supervisar el desarrol-
lo e implementación de políticas y procedimientos; y
analizar el rendimiento son todos componentes clave
en la gestión de función de TI.
Hay que tener en cuenta que las auditorías de dichas fun-
ciones serán similares a las auditorías de procesos. El auditor
de TI examina las personas y tareas en contraposición con
5
los parámetros técnicos del sistema. El análisis de controles
será algo distinto y requerirá un cierto grado de criterio pro-
pio.
3.2 Infraestructura técnica
A este nivel se le puede llamar de muchas formas, tal como
controles generales de informática, controles generalizados,
o tecnologías de soporte. Se refiere básicamente a los sis-
temas que sustentan, soportan y hacen posible la disponibil-
idad de aplicaciones primarias del negocio Generalmente
incluye:
Sistemas Operativos – El grupo de programas que dan
instrucciones a los sistemas informáticos para su fun-
cionamiento. Ejemplos de estos son Unix, Windows
2003, y OS/400. Todos los programas y archivos even-
tualmente residen en alguna parte del sistema operativo.
Las acciones realizadas a nivel de sistema operativo nor-
malmente sortean la mayoría de los controles y seguridad
que existen en el nivel de procesos. Por ejemplo, se
puede considerar el caso de la computadora portátil de
un ejecutivo. Si el ejecutivo desea eliminar un correo
electrónico, entra en la aplicación para realizarlo.
Probablemente el programa pregunte: ¿Está seguro?
Entonces se almacenará el correo eliminado en una car-
peta especial durante un tiempo para poder recuperarlo.
Sin embargo, dicho ejecutivo podría también abrir
Windows Explorer para eliminar todos los directorios en
la unidad C del disco. El efecto sería el mismo ya que el
correo desaparece. Sin embargo, en el último ejemplo
existen claramente menos controles.
Bases de datos – Todos los datos de negocio, ya sean críti-
cos o no, terminan por residir en algún tipo de base de
datos en el entorno. Las bases de datos se componen de
tablas que contienen datos que, entre otras cosas, for-
man la base de todos los informes del negocio. Algunos
ejemplos son: Oracle, MS SQL Server, y DB2. Las
acciones realizadas en este nivel de base de datos tien-
den a eludir la mayoría de los controles existentes en
el nivel de procesos, en comparación con el ejemplo
anteriormente comentado sobre el fraude en los pagos.
Redes – Para que puedan fluir los datos a través de la orga-
nización, se requiere una forma de viajar que puede ser
vía cable, cable de fibra óptica, o sistema inalámbrico.
La red consiste en componentes físicos como los
cables, los dispositivos que gestionan el movimiento de
tráfico de la red e interruptores, ruteadores o filtros de
seguridad, además de los programas que controlan el
movimiento de los datos. La integridad de la red tiene
un papel importante a la hora de asegurar que los datos
del negocio son completos y correctos. Por ejemplo, si
un empleado de almacén que prepara un envío emplea
un escáner de código de barras para escanear el produc-
to ¿cómo se contabilizará la operación en los libros de
contabilidad? La respuesta es que viaja a través de la
GTAG — Definición de TI — 3

red y se procesa. ¿Pero qué pasa si no viaja a través de
la red? ¿Qué pasa si se modifica en el camino o desa-
parece por completo?¿Cómo puede hacer la organi-
zación para darse cuenta de esto?
Las auditorías de la infraestructura técnica tienden a cen-
trarse más en la revisión de los parámetros de la configu-
ración que en los procesos.
3.3 Aplicaciones
Las aplicaciones de negocio son programas que realizan tar-
eas específicas relacionadas con las operaciones del nego-
cio. Normalmente se pueden clasificar en dos categorías:
aplicaciones transaccionales y aplicaciones de soporte.
Aplicaciones transaccionales
Las aplicaciones transaccionales consisten principalmente
en un software que procesa y registra las operaciones del
negocio. Ejemplos de estas aplicaciones son el proceso de
pedidos, la contabilización en libros y la gestión del almacén.
Las aplicaciones transaccionales normalmente pueden estar
dentro de alguna de las siguientes categorías:
Ámbito de compras – posibilita los procesos de aprovi-
sionamiento y cadena de logística
Ámbito de ventas – posibilita los procesos de ventas y
distribución..
Administración – posibilita la contabilidad financiera,
deudores y acreedores, y los procesos de recursos
humanos.
ERP – un software integrado que realiza una o más de las
funciones descritas arriba.
Internet, claramente, es la primera que viene a la mente,
pero a menudo los DEA comenten el error de detenerse allí.
En realidad, es muy probable que la red corporativa esté
conectada a muchas otras redes. Por ejemplo, ¿la organi-
zación, hace negocios a través de EDI? Si es así, es probable
que la red corporativa esté conectada a la red del proveedor
de EDI, o quizá esté directamente conectada a la red de un
socio comercial. ¿Usa la organización proveedores externos
de alojamiento y almacenamiento? Si es así, las dos redes
probablemente estén enlazadas.
Además, a medida que las organizaciones sigan ade-
lante en la automatización de procesos clave, se concede
mayor acceso a personas ajenas a la empresa, a la red corpo-
rativa, a menudo, vía Internet. Hay que considerar, por
ejemplo, la posibilidad de mirar el estado de la cuenta de una
tarjeta de crédito o el estado de envío de un paquete por
mensajería. Los clientes que realizan dichas actividades
probablemente entran en las redes internas de las com-
pañías, a través de Internet.
El asunto aquí es que las redes externas no se
encuentran bajo el control de la organización y por lo tanto,
no se debe confiar en ellas. Toda comunicación proveniente
de redes externas, o hacia ellas, se debe controlar y supervis-
ar rigurosamente. La definición de los procedimientos de
auditoría de TI para abordar tal riesgo puede representar un
desafío porque la organización sólo puede auditar lo que con-
trola. Por lo tanto, es de vital importancia auditar los puntos
de entrada y salida como mínimo.

Aplicaciones de soporte
Las aplicaciones de soporte son programas de software espe-
cializado que facilitan las actividades de negocio aunque nor-
malmente no procesan transacciones. Algunos ejemplos son
los programas de correo electrónico, fax, sistemas de visual-
ización de documentos, y programas de diseño.
Gran parte de la atención por parte de auditoría de TI
se debe orientar hacia las aplicaciones transaccionales. No
obstante, según el sector, algunas aplicaciones de soporte
pueden también representar un alto riesgo. Por ejemplo, la
Compañía XYZ fabrica un producto de consumo con una
marca altamente reconocida. Constantemente pierde dinero
debido a imitaciones vendidas por la piratería corporativa.
Su equipo creativo diseña los nuevos productos empleando
un paquete informático de software integrado de diseño. En
ese caso, la empresa debe analizar los controles alrededor de
la aplicación de soporte porque podría representar un riesgo
esencial para la empresa si se roban los nuevos diseños antes
de su llegada al mercado.

3.4 Conexiones externas

La red corporativa no opera de forma aislada. Muy probable-
mente esté conectada con otras muchas redes externas.

6
GTAG — Riesgos asociados a la TI — 4
4.1 La teoría del “copo de nieve”
(Snowflake Theory)
La teoría del “copo de nieve” (Snowflake Theory) argumen-
ta que todo entorno de TI es único y por lo tanto representa
una serie de riesgos únicos. Las diferencias de cada entorno
hacen que sea cada vez más difícil adoptar un enfoque
genérico o emplear cuestionarios con respecto a la auditoría
de TI. Para lograr la efectividad, cada organización debe
definir el enfoque de auditoría de TI y crear planes de traba-
jo para la auditoría de TI que sean específicos a las necesi-
dades del entorno en cuestión.
Esto presenta una diferencia con respecto a las auditorías
financieras u operativas, donde ciertos riesgos son endémicos
a un determinado sector de la industria, o al tamaño de la
empresa. Consideremos el siguiente caso: la compañía ABC
y la compañía XYZ se dedican a los medios de comunicación
y al negocio del entretenimiento. Las dos enfrentan un ries-
go al calcular los asientos contables finales para las películas
que han sido estrenadas. Es indudable que este proceso
debería ser auditado por la función de auditoría interna.
Sin embargo, con respecto a la TI, la empresa ABC uti-
liza aplicaciones Oracle como principal sistema del negocio
que opera con Windows 2000 y utiliza una base de datos
Oracle. Hay un sistema Oracle centralizado. Por otro lado, la
función de TI se encuentra descentralizada en la compañía
XYZ, y cada unidad de negocio emplea su propio sistema uti-
lizando una variedad de plataformas. Los datos de cada
unidad de negocio llegan a un sistema de consolidación que
la empresa ha subcontratado a través de un proveedor exter-
no. Claramente, las auditorías de TI planificadas y llevadas a
cabo para la empresa ABC variarán significativamente de
aquellas para la compañía XYZ.
El factor de la configuración
Otro factor importante en la teoría del “copo de nieve” es la
configuración. Cuando una empresa implementa una deter-
minada tecnología, la configura para soportar sus objetivos
particulares. Puede existir una gran variabilidad entre
entornos. Una empresa que usa Windows 2003 como sistema
operativo principal puede haber establecido múltiples
dominios con relaciones fiables entre todos los dominios.
Otra puede haber establecido un único dominio utilizando
Windows Active Directory para gestionar todo el acceso de
los usuarios. Si bien ambas empresas emplean la misma tec-
nología, los riesgos que presentan son muy distintos, y por lo
tanto, las auditorías de TI se llevarán a cabo de forma muy
diferente.
La configuración tiene un impacto, además, en las apli-
caciones de negocio. La empresa ABC y la compañía XYZ
han implementado SAP como sistema principal de negocio
habilitando el proceso de pagos con SAP. La empresa ABC
ha configurado SAP para realizar la triple comprobación
respecto al precio, cantidad y fecha. Ha definido niveles de
tolerancia máximos y mínimos de USD50 y/o 5%, cualquiera
7
sea menor. La compañía XYZ ha configurado SAP para
realizar una “liquidación valorada sobre recepción” por la
cual se genera el pago automáticamente sobre lo que se reci-
ba sin tener en cuenta lo que se ha pedido o facturado. No se
realiza la triple comprobación y no se han establecido nive-
les de tolerancia. Una vez más, aunque ambas empresas uti-
lizan SAP, los riesgos asociados a cada configuración son
distintos, por lo que las auditorías de TI a realizar en cada
empresa también serán diferentes.
Una serie de variables
Otros variables que tienen impacto sobre la teoría del “copo
de nieve” son:
• El grado de centralización de sistemas
• El grado de centralización geográfica
• El número de servidores
• La elección de tecnologías de infraestructura
• El grado de personalización de los sistemas
• La estructura organizativa del departamento de TI
• Las versiones de las tecnologías empleadas (por ejemp-
lo, Windows 2000 versus Windows 2003)
• El grado y método de externalización
• Las políticas corporativas (por ejemplo, guardar todos
los correos electrónicos por tiempo ilimitado o no
guardar ninguno)
El resultado neto de todas estas variables es la teoría del
“copo de nieve”: no existen dos entornos de TI iguales. Por
lo tanto, es muy difícil, si no imposible, adoptar un enfoque
en base a cuestionarios para la planificación y ejecución de
las auditorías de TI. Cada empresa debe tener un plan de
auditoría de TI único en base a sus riesgos específicos de TI.
El reto, claramente, se encuentra en la identificación
adecuada de los riesgos del negocio y los riesgos de TI que
sean específicos al entorno particular de una organización.
Por ese motivo, el proceso de evaluación de los riesgos de TI
es de vital importancia, y probablemente más aún que la
evaluación global de riesgos. Además, dicha evaluación debe
ser realizada por personas que tengan los conocimientos ade-
cuados, como que comprendan cómo el uso del directorio
activo por parte de la empresa afectará a las auditorías de TI
que deban realizarse.
4.2 La evolución del riesgo
La teoría del “copo de nieve” establece que cada empresa
debe tener un perfil de riesgos que sea único para la organi-
zación. No obstante, existe otra dimensión del riesgo que
debe también considerarse: la evolución del riesgo. Esto se
basa en la Ley de Moore que fue inicialmente propuesta en
1965 y que dice que la densidad de los datos en un circuito
integrado se duplica cada 18 meses. En la práctica esto sig-
nifica que la tecnología aumenta a un ritmo acelerado, lo
que no debe sorprender a nadie.
Como consecuencia de ello, los riesgos de TI no son
 GTAG — Riesgos asociados a la TI— 4
estáticos. Dado el alto crecimiento y la expansión de las tec-
nologías, los riesgos asociados a TI cambiarán, a veces de
forma dramática, de un año a otro. Puede incluso existir una
situación en que la agenda de auditorías de TI se haya basa-
do en un proceso efectivo de evaluación de riesgos, pero a la
hora de realizar las auditorías, ese perfil de riesgos haya
evolucionado y las auditorías TI planificadas ya no resulten
suficientes.
Para combatir este problema relacionado con la evolu-
ción de riesgos TI el DEA debe hacer lo siguiente:
• Reconocer la naturaleza dinámica del riesgo de TI y
realizar anualmente evaluaciones independientes de
los riesgos.
• Comprender los planes a corto plazo del departamento
de TI para un determinado año y analizar cómo esas
iniciativas podrían tener impacto sobre la evaluación
de riesgos de TI.
• Iniciar cada auditoría de TI real actualizando el com-
ponente de evaluación de riesgos de dicha auditoría.
• Ser flexible con respecto al universo de auditoría de TI;
supervisar el perfil de riesgos TI de la organización y
estar dispuesto a adaptar los procedimientos de audi-
toría según la evolución de ese perfil.
4.3 Proliferación de los riesgos asociados a TI
La tercera dimensión a considerar a la hora de evaluar los
riesgos de TI es el concepto de proliferación, que está rela-
cionado con la naturaleza sumatoria de los riesgos de TI.
Suponiendo que la organización ha identificado el riesgo
“A” y el riesgo “B” asociados a la TI. De forma independi-
ente, cada riesgo podría ser bajo, pero cuando los dos proce-
sos asociados a dichos riesgos operan de forma conjunta, se
crea el riesgo de TI “C” que es mucho mayor que la suma de
los riesgos individuales.
Por ejemplo: la compañía XYZ utiliza aplicaciones
Oracle. No existe un proceso para supervisar la actividad del
sistema. Además, los administradores de sistemas tienen
acceso completo al sistema. De manera independiente, cada
uno de estos elementos representa un riesgo, pero conjunta-
mente representan una situación en que un determinado
número de personas podría hacer lo que quisiera en el sis-
tema (aprobar facturas, emitir talones, establecer nuevas
cuentas de nómina, etc.) sin ninguna verificación o cuadre
independiente. En este caso la comprensión de los procesos
de gestión y supervisión de TI, junto con la seguridad especí-
fica del sistema, es importante para entender el riesgo real.
Por esta razón, es importante considerar el riesgo asoci-
ado a la TI de manera holística, y no, por separado. El DEA
debe considerar el riesgo asociado a TI, en el nivel de la
empresa, evaluando no sólo los riesgos individuales, sino la
forma en que se afectan el uno al otro. Hay que recordar que
el entorno TI tiene niveles. Dicho de una manera más gráfi-
ca: es como si se quisiera tamizar arena sobre un número de
filtros colocados uno sobre el otro. Aunque cada filtro tiene
agujeros, las capas de filtros impedirán que la arena se filtre
8
hasta abajo. Imaginando ahora que cada filtro tiene un agu-
jero pequeño que está directamente alineado con el de abajo,
la arena puede caer a través de todos los filtros sin impedi-
mento.
El DEA de primer nivel siempre considera todos los
niveles de un entorno TI a la hora de planificar y llevar a
cabo las auditorías de TI. La evaluación del impacto de los
riesgos en un nivel determinado en relación a los riesgos de
otros niveles, es muy importante cuando se hace el análisis
de riesgos de TI.
4.4 Tipos de riesgos de TI
El primer paso para entender los riesgos asociados a TI es
identificar qué puede ir mal, se incluyen:
• Disponibilidad: cuando el sistema no está disponible
para su utilización.
• Seguridad: cuando tiene lugar un acceso no autorizado.
• Integridad: cuando los datos son incompletos o
incorrectos.
• Confidencialidad: cuando no se guarda secreto sobre los
datos.
• Efectividad: cuando el sistema no tiene disponible una
función, como estaba previsto o se esperaba.
• Eficiencia: cuando los sistemas causan una utilización
subóptima de los recursos.
Los diversos riesgos asociados de TI se pueden agrupar gen-
eralmente en dos categorías principales: riesgo generalizado
y riesgo específico.
Riesgo generalizado
Algunos riesgos asociados a TI no se limitan a un proceso o
sistema concreto. Estos riesgos causan impacto sobre la
empresa de forma global, y por lo tanto, se les denomina ries-
gos generalizados. Por ejemplo, la compañía XYZ se conecta
a Internet pero no mantiene un filtro de seguridad. ¿Qué
saldo contable se podría ver afectado? Potencialmente todas
las cuentas o ninguna. Otro ejemplo sería la presencia de
rociadores automáticos en el centro de proceso de datos. Si
se activan de forma accidental y mojan los servidores,
entonces ¿qué procesos operativos se verían afectados?
Podrían ser todos, ninguno o, a medio camino, cualquier
otro aspecto.
Riesgo específico
El riesgo específico, por otra parte, se puede atribuir directa-
mente a procesos específicos o cuentas contables.
Considerando los parámetros para la triple comprobación
mencionados en la Introducción a esta guía, y si estos no se
han establecido de forma correcta, el riesgo afectará especí-
ficamente el proceso de pagos y de caja.
El DEA a menudo lucha con el hecho de que los riesgos
generalizados representan riesgos mucho mayores para la
empresa que los riesgos específicos. Sin embargo, es muy difí-
cil cuantificar un riesgo generalizado. Además, cuando se
informa sobre una deficiencia de control relacionado con un
GTAG — Riesgos asociados a la TI — 4
riesgo generalizado, es mucho más difícil asociarlo al impacto
sobre el negocio debido a la naturaleza de la deficiencia.
Lo importante aquí es el equilibrio. El DEA debe recor-
dar que tanto los riesgos generalizados como los específicos
son importantes, y centrar su atención auditora en ambos
tipos. Si una revisión del universo de auditoría planificado
no pone de manifiesto auditorías que cubran ambos tipos de
riesgos, es probable que dicho universo no cubra los riesgos
de la organización de forma adecuada.
4.5 IT Evaluación de los riesgos de TI
El auditor debe emplear una técnica o enfoque adecuados de
evaluación de riesgos, a la hora de desarrollar el plan global
para la asignación efectiva de los recursos de auditoría de TI.
La evaluación de riesgos es una técnica empleada para exam-
inar las unidades auditables dentro del universo de auditoría
y seleccionar las áreas a revisar que tengan la mayor exposi-
ción al riesgo. Los riesgos asociados a cada nivel de TI no se
pueden determinar revisando los riesgos asociados a TI de
forma aislada, sino que se deben considerar en conjunto con
los procesos y objetivos de la organización.
Impacto versus probabilidad
La evaluación del riesgo asociado a TI debe también consid-
erar el impacto y la probabilidad de su ocurrencia. El
impacto de los eventos de riesgos de TI a menudo es alto y
en particular para los riesgos generalizados. La probabilidad
será más difícil de determinar porque se trata de un valor de
predicción (por ejemplo, ¿cuál es la probabilidad de que un
pirata informático entre en el sitio Web de la organización?).
La experiencia anterior y las prácticas pueden emplearse
como soporte a estas estimaciones. El resultado del impacto
y de la probabilidad ayuda a definir la severidad del riesgo,
proporcionando una base para comparar y priorizar los ries-
gos asociados a TI.
Considerando que la empresa XYZ ha implementado
Windows 2003 ¿Se debe incluir esto en las auditorías de TI
del año en curso? La respuesta a esta pregunta, como a
muchas otras, es la palabra “depende”. En ese caso, existen
muchos factores que afectan la decisión. La consideración
clave es el riesgo para el negocio y el impacto de la tec-
nología sobre las operaciones de la organización. Si la única
aplicación que opera sobre Windows 2003 es la que actualiza
los códigos postales cuando los modifica Correos, entonces
dicha tecnología claramente tiene un impacto muy reducido
sobre la integridad global de las operaciones de la organi-
zación. Por lo tanto, la auditoría de este sistema representaría
un desperdicio de recursos de auditoría de TI. Por otra parte,
si los sistemas de la cadena de suministros operan sobre
Windows 2003, entonces la tecnología definitivamente afec-
ta a la consecución de los objetivos de la organización y se
debería incluir en el plan de auditoría de TI.
Con frecuencia, sin embargo, las respuestas no son tan
obvias. Por este motivo, la función efectiva de una auditoría
de TI depende en gran medida de la realización de una sóli-
9
da evaluación de los riesgos de TI. Dicha evaluación ayuda a
abordar los temas planteados por la teoría del “copo de
nieve” y permite a la organización determinar las áreas que
merecen mayor atención por parte de auditoría.
Acotaciones sobre las evaluaciones tradicionales de
riesgos
Es importante señalar que los procesos y actividades rela-
cionados con la evaluación tradicional de riesgos posible-
mente no proporcionen una evaluación efectiva de riesgos
de TI. Dichos procesos y tareas deben rediseñarse para abor-
dar adecuadamente los requerimientos de un proceso de
evaluación de riesgos de TI. Concretamente, la mayoría de
los procesos heredados para la evaluación de riesgos se basan
fundamentalmente en entrevistas. Por sí solas, las entrevistas
probablemente sean insuficientes para evaluar el riesgo de TI
porque gran parte de tal riesgo se basa en cómo la tecnología
está específicamente configurada dentro de la empresa.
Además, buena parte del riesgo en el área de TI está impues-
ta por aspectos emergentes. Por ejemplo, un pirata informáti-
co ha descubierto un nuevo defecto en Windows 2003 y
diseña una herramienta para explotar esta deficiencia.
Microsoft identifica el problema y pone en circulación un
parche que elimina el defecto. Un auditor de TI probable-
mente necesitará entender la información sobre qué ajustes
han sido instalados, antes de poder analizar adecuadamente
el riesgo real alrededor de la tecnología.
Riesgo estático versus riesgo dinámico
En la sección “tipos de riesgos”, se consideró el concepto del
riesgo generalizado versus el riesgo específico. La compren-
sión de los riesgos dinámicos es importante. Sin embargo, al
realizar un análisis de riesgos de TI, también es importante
considerar el riesgo estático versus el dinámico.
Riesgo estático: Este tipo de riesgo no cambia de un año
para otro y normalmente es el sector dentro del cual
opera la organización que lo impulsa. Por ejemplo, la
compañía XYZ vende libros “en línea” y su riesgo está
asociado a sus servidores del sitio Web que operan el
sistema de pedidos “en línea”. Si los servidores caen, la
fuente de ingresos de la empresa se paraliza hasta que
los servidores vuelvan a activarse.
Al evaluar el riesgo estático, las técnicas de entre-
vista y de solicitud de información son adecuadas en
muchos casos. Estas evaluaciones tienden asimismo a
requerir alguna actualización cada año, en base a las
nuevas condiciones, aunque generalmente continúan
siendo ciertas año tras año. A menos que la compañía
XYZ decida paralizar el negocio de ventas de libros “en
línea” para abrir una solución más tradicional, los
servidores de la Web continuarán siendo una zona de
alto riesgo.
Riesgo dinámico: El riesgo dinámico representa un ries-
go que cambia constantemente. Tiende a estar menos
influenciado por el sector y más por la evolución de las
 GTAG — Riesgos asociados a la TI — 4
tecnologías (recordemos la Ley de Moore). El des-
cubrimiento de una deficiencia en Windows 2003 es
un ejemplo estupendo del riesgo dinámico. La evalu-
ación del riesgo del año anterior no hubiera identifica-
do aquel riesgo, porque no existía en ese momento. El
riesgo dinámico también influye en la manera en que
se debe llevar a cabo el proceso de evaluación del ries-
go. Para dicho caso, el proceso de evaluación de riesgos
de TI debe centrarse en el proceso que ha implantado
la gestión de TI para supervisar los parches y medir su
implementación oportuna.
Los asuntos relacionados con aspectos legales y
normativas también representan riesgos dinámicos
importantes. Estos aspectos afectan a todas las áreas
del negocio, aunque dada la evolución de las tec-
nologías, cada año surgen muchas cuestiones nuevas,
legales y normativas, relacionadas con la tecnología;
como por ejemplo, las nuevas reglas y reglamenta-
ciones relacionadas con la privacidad promulgadas
recientemente
Evaluación del riesgo dinámico de TI
A la hora de evaluar el riesgo dinámico de TI, los proced-
imientos de obtención de información probablemente sean
insuficientes. Habrá que seguir dos pasos clave: el descubrim-
iento y el análisis.
Descubrimiento: El descubrimiento es el proceso de
determinar las tecnologías que han sido implemen-
tadas, cómo se han configurado y los procesos de nego-
cio que soportan y su alineación con estos. En muchos
casos, se hace uso de herramientas a modo de apoyo al
proceso de descubrimiento. Por ejemplo, una organi-
zación con una función descentralizada de TI posible-
mente no sepa el número de servidores y versiones de
sistemas operativos que se usan en la empresa. El des-
cubrimiento de la red y la herramienta de mapeo
pueden ayudar a recopilar esos datos de forma rápida y
correcta.
Análisis: El análisis se basa en la evaluación de la infor-
mación una vez que ha sido recopilada. Una vez más,
es probable que no se encauce a través de procedimien-
tos de interrogación sino que se base más en el análisis
realizado por el auditor de TI de los datos recopilados
con respecto a los temas emergentes y a los nuevos ries-
gos de tecnológicos.
Otro concepto que surge en la fase de análisis es el con-
cepto de dependencia del riesgo. Se ha hecho alusión a dicho
concepto al describir anteriormente, la analogía de tamizar
arena sobre un montón de filtros (Apartado “Proliferación
del riesgo de TI”). Si existe un agujero en cada filtro,
entonces la arena podría caer a través de todos ellos. Esta es
la esencia de la dependencia del riesgo. El impacto de un
determinado riesgo dependerá de la presencia de otros ries-
gos. Por ejemplo, la red de la compañía XYZ no se encuentra
10
segregada y emplea una serie de redes inalámbricas. El equipo
de ingeniería colabora electrónicamente en documentos de
diseño para nuevos productos. En este caso, el riesgo de nego-
cio radica en el hecho de que su competidor podría situarse
cerca de la empresa con una antena, y obtener datos sobre los
diseños de los nuevos productos. El riesgo resulta de la com-
binación del diseño de la red y de los procesos de diseño así
como de la nueva tecnología, y cada riesgo depende de la
existencia de los otros dos riesgos. El riesgo global es mayor
que la suma de cada riesgo por separado.
Por este motivo muchas organizaciones emplean una
estrategia de ‘niveles de defensa’ que proporciona múltiples
capas de seguridad y control. Durante el proceso de análisis
será importante que el DEA evalúe el diseño y efectividad de
todos los niveles de defensa antes de concluir sobre el
impacto de un riesgo o debilidad de TI.
Evaluación consistente de riesgos de TI
Considerando estos aspectos, el DEA debe planificar en con-
secuencia y asegurar que el proceso de evaluación de riesgos
cumpla lo siguiente:
• Que se realice cada año en profundidad y que no sea
sólo una actualización del año anterior.
• Que tenga en cuenta todos los niveles del entorno
de TI.
• Que considere los riesgos estáticos y dinámicos.
• Que no se base únicamente en entrevistas, sino que
emplee otras técnicas de descubrimiento.
• Que se complete con un nivel apropiado de análisis una
vez realizado el descubrimiento.
• Que sea realizado por personal adecuado.
Este último apartado podría plantear uno de los mayores
retos para el DEA dado que la TI representa un concepto
muy amplio y comprende muchos niveles. Las habilidades
necesarias para comprender cada nivel varían de forma
dramática. Un especialista en redes con conocimientos téc-
nicos profundos tiene habilidades muy distintas a las del
especialista en aplicaciones SAP con amplios conocimientos
técnicos. Para llevar a cabo una evaluación de riesgos de TI
efectiva se requerirán especialistas en todos los niveles y
capas del entorno de TI. Rara vez o casi nunca todas esas
habilidades se reúnen en una sola persona. Es mucho más
probable que se requiera la intervención de un equipo de
especialistas en auditorías de TI con conocimientos que
cubran todos los niveles. Dicho equipo tendrá que trabajar
conjunta y estrechamente durante el proceso, principal-
mente por existe una dependencia entre los riesgos.
GTAG — Definición del universo de auditoría de TI — 5
Una vez que se ha realizado la evaluación de los riesgos de TI
con un grado adecuado de exactitud, el siguiente paso es
determinar las auditorías de TI que se deben realizar. Si se ha
llevado a cabo la evaluación de riesgos de forma efectiva, la
organización tendrá una idea razonable de los riesgos de TI
que existen. Sin embargo, esto planteará una serie de retos,
entre ellos, la definición de las auditorías de TI.
En el ejemplo previo (en el apartado 4), la empresa
había identificado el riesgo de negocio de transmitir datos
importantes con relación al diseño de sus productos fuera de
la organización. ¿Qué auditorías se deberían realizar para
abordar dicho riesgo?
¿Se debe llevar a cabo una auditoría de las redes inalám-
bricas, una auditoría de su arquitectura y diseño o una
revisión de la aplicación del sistema de diseño electrónico? Y
si se dividen las auditorías de esta manera, es probable que la
comunicación de los hallazgos de la auditoría esté orientada
hacia los parámetros técnicos de cada tecnología individual.
Eso es correcto, pero al Comité de Auditoría no le impor-
tarán posiblemente los parámetros técnicos de detalle y
probablemente desee que los hallazgos de la auditoría de TI
estén relacionados con el negocio.
Por lo tanto, la manera en que se definan las auditorías
de TI representa un papel importante en la efectividad glob-
al de la función de auditoría de TI. Esto se complica por la
necesidad de que la función de auditoría de TI se integre con
la de los auditores financieros u operativos o de proceso y los
procedimientos que realizan, especialmente en entornos
donde existan grandes aplicaciones ERP integradas, en los
que hay un gran número de controles de procesos dentro de
los sistemas.
Aunque no exista una forma correcta para definir las
auditorías de TI, sin duda hay formas incorrectas. Por ejem-
plo, muchos DEA cometen el error de definir el alcance de
una auditoría de “controles generales de TI”. Este concepto
es tan amplio que prácticamente carece de significado, espe-
cialmente en una organización grande. ¿Incluye las conex-
iones telefónicas? ¿Y la configuración de las computadoras de
mesa? ¿Los controles ambientales en el centro de cómputo?
¿Todo lo anterior? De ser así, la auditoría demandará un
tiempo considerable para su realización.
5.1 Consejos para el DEA
El reto se encuentra en poder proporcionar el nivel apropia-
do de detalle en la definición del universo de auditoría de TI
para hacerlo efectivo y eficiente. Esto varía para cada fun-
ción de auditoría de TI (una ampliación de la teoría del
“copo de nieve”), pero se pueden señalar algunos aspectos a
considerar a la hora de definir las auditorías de TI:
• El empleo de definiciones demasiado amplias para las
auditorías de TI (por ejemplo, controles generales de
TI) prácticamente asegurará que habrá desplaza-
mientos en el alcance de los procedimientos de audi-
toría. Además podrá existir una brecha entre lo que
piensa la dirección que se está auditando y los proced-
11
imientos de auditoría que realmente se estén realizan-
do. Por ejemplo, la compañía XYZ implementa SAP
para sus procesos de contabilidad financiera. La fun-
ción de auditoría de TI realiza una revisión de la
posimplementación de los controles configurables para
las cuentas a pagar, pero lo denomina “Revisión posim-
plementación de SAP”. Después de dicha auditoría,
surge un problema importante con la parametrización
de la seguridad de usuarios. El Comité de Auditoría
probablemente preguntará por qué no se ha detectado
en la revisión pos implementación de SAP. La respues-
ta es que no fue evaluado. Pero la nomenclatura de la
auditoría era engañosa. Con esto en mente, los DEA
deben asegurarse que la definición de cada auditoría de
TI represente una descripción ajustada y correcta de lo
que se está revisando.
• El universo de auditoría anual deberá tocar todos lo
niveles en el entorno TI. Aunque cada entorno de TI
difiere, los niveles tienden a ser los mismos. Si el plan
de auditoría de TI no incluye una forma de revisión
para cada uno de esos niveles, es probable que sea glob-
almente deficiente.
• Las auditorías de TI se deben estructurar de tal
forma que proporcionen informes efectivos y lógicos.
Las revisiones de las aplicaciones, por ejemplo, casi
nunca son efectivas de forma óptima cuando son dividi-
das de forma independiente (por ejemplo, una revisión
de las cuentas a pagar en Oracle). Las aplicaciones,
deben integrarse desde la ejecución y elaboración de
informes con las auditorías financieras/operativas/de
proceso. Las auditorías de TI de las tecnologías pene-
trantes (por ejemplo, redes, procesos, etc.) tienden a ser
más efectivas cuando se realizan a nivel empresa. En
otras palabras, no tiene sentido realizar una auditoría de
redes en la oficina de Pittsburg y otra igual en Phoenix,
sino que se debe realizar una auditoría de la red a nivel
de la empresa. La geografía importa menos que los pro-
cesos.
• Las auditorías de TI deben cubrir los riesgos apropi-
ados. En muchos casos se determinan los presupuestos
de auditoría de TI antes de realizar la evaluación de los
riesgos de TI. Inevitablemente esto conduce a una o
dos de las siguientes situaciones:
1. Una cantidad inadecuada de horas de auditoría
se distribuye entre demasiadas auditorías; lo
cual, invariablemente, da como resultado audi
torías de TI de mala calidad porque no hay sufi
ciente tiempo para efectuarlas de forma correcta.
2. No se hacen las auditorías que deben realizarse
porque el presupuesto no lo permite.
La planificación y el presupuesto de auditoría de TI deben
ser el resultado del proceso de evaluación de riesgos de TI, no
se deben realizar antes de la evaluación de riesgos de TI.
Además, la evaluación de riesgos de TI se debe considerar en
el contexto de la evaluación de riesgos de la empresa en su
 GTAG — Definición del universo de auditoría de TI — 5
totalidad. Podría darse el caso de que en una organización en
particular, el entorno de TI presente un riesgo tan impor-
tante para la empresa que todos los procedimientos de audi-
toría interna del año deban ser de TI; una situación extrema,
aunque no imposible.
5.2 Realizar el presupuesto de auditoría de TI
Uno de los errores comunes que se cometen a la hora de
definir el universo de auditoría es subestimar el tiempo nece-
sario para realizar la auditoría de TI. Este tema, en muchos
casos representa la teoría del “copo de nieve”. Por ejemplo:
la empresa ABC procesa la aplicación financiera en un
AS/400. El auditor de TI desea acceder a la seguridad alrede-
dor del AS/400 y emplea unas 100 horas realizando la
revisión. La compañía XYZ también opera con una apli-
cación similar en un AS/400. ¿Las dos revisiones requerirán
el mismo tiempo?
Es claro que la respuesta es “depende”. Si la empresa
ABC tiene 100 usuarios y la compañía XYZ 1000 usuarios,
podríamos correctamente asumir que la revisión duraría 10
veces más en la compañía XYZ, si la auditoría fuera a evalu-
ar a todos los usuarios. Si el enfoque de la auditoría es sola-
mente evaluar los derechos de acceso de una muestra de 10
usuarios, entonces ambas durarían el mismo tiempo, pero
ofrecerían distintos niveles de confianza.
Dicho ejemplo ilustra el riesgo en la estimación de los
presupuestos de auditoría de TI. Es muy posible calcular
erróneamente el esfuerzo necesario de acuerdo a la magni-
tud, que no se entiende claramente en el lado operacional o
financiero de la función de auditoría. Dichas estimaciones
12
probablemente sean incorrectas, pero no por razones de mag-
nitud.
Otro ejemplo podría ser la auditoría de un sistema SAP.
La revisión de seguridad de dicho sistema para dos clientes
en producción llevará el doble de tiempo que una revisión de
dicho sistema para un cliente. ¡Qué desgracia para el DEA
que haya estimado el presupuesto sin entender completa-
mente el entorno TI! (véase el apartado referente a la eval-
uación de riesgos de TI). Si las estimaciones se han realizado
sin saber cuántos clientes existen en producción, puede que
tales estimaciones de presupuesto estén muy alejadas de la
realidad.
¿Cómo debe el DEA abordar este tema? Ciertamente
uno de los elementos decisivos es la comprensión del
entorno TI, lo cual debe desarrollarse naturalmente al
realizar una evaluación de riesgos TI de forma adecuada.
Otro elemento crítico es estimar correctamente el tiempo
requerido para llevar a cabo las tareas de auditoría de TI.
Algunas tareas, como la revisión de los parámetros de una
configuración, pueden realizarse de forma rápida y eficaz.
Otras, tales como la auditoría de una arquitectura compleja
de la seguridad de usuarios, puede consumir una cantidad de
tiempo considerable. Como táctica, el DEA debe cuestionar
las estimaciones de los presupuestos para auditorías planifi-
cadas, debe asegurarse de que se haya realizado la planifi-
cación inicial de manera suficiente como para justificar tal
estimación, y asegurarse de que la dirección y el personal de
auditoría de TI están de acuerdo con esa estimación. Sean
conscientes de que muy pocas veces, una auditoría de TI de
menos de 80 horas resulta efectiva para una tecnología.
GTAG — Realización de la auditoría de TI — 6
El proceso para la ejecución de una auditoría de TI no es, en
teoría, distinto al que corresponde a la realización de una
auditoría operativa. El auditor planifica el trabajo, identifica
y documenta los controles, realiza pruebas sobre el diseño y
efectividad de los controles, prepara sus conclusiones y emite
un informe. Como la mayoría de los DEA ya están familiar-
izados con este proceso global, no se comentará sobre ello en
esta guía. No obstante, existen ciertos elementos de una
auditoría de TI que sí varían, en algunos aspectos, con
respecto a las auditorías tradicionales. Por lo tanto, esta sec-
ción identificará algunos de esos aspectos para proporcionar
a los DEA perspectivas e ideas sobre cómo gestionarlos.
6.1 Estructuras y normas
Un reto al que se enfrentan los auditores, cuando llevan a
cabo una auditoría de TI, es saber contra qué deben auditar.
Muchas organizaciones no han desarrollado completamente
sus líneas de base para los controles de TI en todas las apli-
caciones y tecnologías. La evolución rápida de las tec-
nologías probablemente ocasione que no sean de utilidad al
cabo de un corto período de tiempo.
La teoría del “copo de nieve” dicta que cada entorno de
TI es distinto. No obstante, lo anterior no resta valor al con-
cepto de objetivos de control. Los objetivos de control, por
definición, se mantienen más o menos constantes de
entorno en entorno. Consideremos el objetivo de que de
todos los datos críticos y programas deben tener una copia de
seguridad y deben ser recuperables. Cada entorno puede
hacer esto de forma diferente, las copias de seguridad pueden
realizarse manual o automáticamente, o se puede utilizar una
herramienta. Estas copias podrían ser sólo incrementales, o
bien, una copia completa de todo. Se pueden hacer diaria-
mente, semanalmente, mensualmente, etc. Su almace-
namiento podría ser interno en una caja de seguridad
resistente al fuego, o externo en otro local de la empresa o
mediante subcontrato con un tercero. El método empleado
por la organización para gestionar las copias de seguridad
ciertamente tendrá un impacto sobre los procedimientos de
auditoría y su presupuesto, si bien el objetivo de control no
Visión del proceso de auditoría
Comprender Identificar
el entorno los controles
clave
Figura 2 – Visión del proceso de auditoría
cambiará. Teniendo en cuenta esto, el DEA debe poder
comenzar con un conjunto de objetivos de control de TI y
seleccionar un marco adecuado, aunque no sea 100% especí-
fico de ese entorno en particular.
COSO y COBIT
¿Dónde puede el DEA encontrar un grupo exhaustivo de
objetivos de control? Los textos “Enfoque integrado de con-
trol interno” y “Enfoque integrado de gestión de riesgo
empresarial” emitidos por el Comité de Organizaciones
Patrocinadoras de la Comisión Treadway (COSO) represen-
tan unas excelentes fuentes de información, aunque no se
centren en la TI. Además, la TI ha evolucionado significati-
vamente desde 1992, año en que se publicó el primer
enfoque COSO. Esto significa que los objetivos de control
de COSO para TI son menos efectivos para la gestión de las
tecnologías de hoy en día. Un entorno de control basado en
COSO se debe incrementar con objetivos de control de TI
más minuciosos a fin de evaluar el entorno de controles de
forma efectiva. Existe un buen número de opciones para ello.
Una estructura de controles de TI se encuentra en el
texto titulado “Objetivos de control de información y tec-
nología relacionadas (COBIT, en inglés)”, que fue publicado
originalmente por el Instituto de Gobierno de TI en 1994,
con el apoyo de la Asociación de Auditoría y Control de
Sistemas de Información (ISACA, en inglés). La versión 4.0
se publicó en noviembre de 2005. COBIT no pretende com-
petir con los enfoques COSO, si bien se puede emplear para
complementarlos dado que COBIT proporciona objetivos de
controles más sólidos y específicos de TI. COBIT 4.0 con-
tiene 214 objetivos de control minuciosos organizados en
aproximadamente 34 procesos de TI. COBIT claramente
proporciona un enfoque más detallado que las estructuras de
control interno de COSO o de ERM, lo cual representa un
buen punto de partida en la identificación de los objetivos de
control relevantes para el entorno que se va a auditar.
Políticas, normas y procedimientos
Una estructura como la de COBIT ofrece un grupo de obje-
Evaluar Probar su Informar
su diseño efectividad sobre los
hallazgos
13
 GTAG — Realización de la auditoría de TI — 6
tivos de control generalmente aceptados, que ayuda a la
dirección a conceptualizar un enfoque para la medición y
gestión del riesgo de TI. La dirección generalmente usará
una estructura de este tipo como guía para el desarrollo de un
grupo exhaustivo de políticas, normas y procedimientos de
TI.
Por ejemplo, una estructura funcional de control nor-
malmente incluirá un objetivo de control para la seguridad
de los sistemas de información contra accesos no autorizados.
Una organización puede lograr dicho objetivo definiendo
una política que especifique que sólo se puede acceder a los
sistemas de producción a través de una única identificación
de usuario y contraseña. Dicha política se ampliará mediante
una norma organizativa que defina los requisitos para la
identificación y contraseña (por ejemplo, que la identifi-
cación de usuario esté formada por la primera letra del nom-
bre de pila seguida por el apellido; y que las contraseñas
deben contener por lo menos ocho caracteres, con una mez-
cla de letras y caracteres, etc.). Una norma de este tipo una
vez más se ampliará con procedimientos que definen la man-
era en que se implementan las normas en cada plataforma
especificando la “evidencia del control” creada y guardada a
través de la ejecución satisfactoria del procedimiento. Este
enfoque en cascada desde la estructura de control hasta las
políticas, las normas y los procedimientos es la esencia para
asegurar que los controles de TI se corresponden efectiva-
mentecon el negocio y el entorno de control de la empresa.
Supongamos que en el ejemplo anterior la organización
no haya definido una norma que proporcione las especifica-
ciones sobre la longitud de la contraseña, etc. En ese caso, el
DEA se enfrentará al reto de intentar determinar contra qué
debe auditar, y esto a menudo terminará en un debate con la
gestión de TI sobre qué constituye un control adecuado.
¿Qué es más seguro, una contraseña con un mínimo de seis
caracteres que vence cada 30 días, o una con un mínimo de
ocho caracteres que vence cada 90 días? A menudo se hace
referencia a las “mejores prácticas” pero no siempre se
establece una relación específica.
Si no existen normas específicas de control de TI en la
organización, se puede recurrir a las diversas normas públicas
de control de TI por sector y mercado. Estas ayudan a
respaldar los procedimientos de auditoría de TI al ofrecer
una serie de recomendaciones basadas en las “mejores
practicas”, allí se exponen los detalles específicos (por
ejemplo, que una contraseña debe contener al menos ocho
caracteres y que se debe establecer que caducará cada 60
días). Un auditor de TI puede hacer uso de estas normas
como líneas de base para realizar su auditoría en referencia a
ellas. También pueden ser útiles para informar sobre defi-
ciencias dado que se elimina la subjetividad de estas. Si se
compara la afirmación: “sería conveniente mejorar la
seguridad de las contraseñas” con “las contraseñas no están
en conformidad con la normativa ISO27001 sobre seguridad
de la información”, está claro que la redacción de la segunda
14
frase no da lugar a debates al respecto.
El desafío que presenta la utilización de normas públicas
para auditar radica en que existen muchas normas distintas
que no siempre recomiendan lo mismo. El objetivo de esta
guía no consiste en analizar los méritos de esas diversas nor-
mas, sino sencillamente en invitar al DEA a evaluar la posi-
bilidad de respaldar sus auditorías de TI usando alguna
norma, la que tenga mejor sentido para la organización y que
sea aceptable para la gestión de TI. La mayoría de las veces
las normas se relacionan con elementos muy específicos del
entorno de TI, tal como la seguridad o la adaptación de pro-
gramas. En la mayoría de los casos, el DEA no se encuentra
en una posición de dictar la norma específica que debe
emplear la organización. Esta decisión la toma el área de TI
o la dirección ejecutiva. Si la norma ya se ha acordado e
implementado, el DEA deberá identificarla para auditar con-
tra ella. También tiene la obligación de evaluar la ade-
cuación de las normas elegidas por la gestión de TI para
asegurar que responden al perfil de riesgos de la organización,
así como a los requerimientos del negocio y a la legislación
vigente.
Seis fuentes de normas
Algunas normas que se deben tener en cuenta:
ISO27001 / ISO17799 – La Organización Internacional
para la Estandarización publicó esta norma genérica
reconocida internacionalmente sobre seguridad de la
información, que comenzó como una norma británica
(BS7799) para luego evolucionar a una norma ISO
(ISO17799), y ahora se conoce como ISO27001. Esta
contiene las mejores prácticas generalmente aceptadas
con respecto a la gestión de seguridad de la informa-
ción y representa un punto de referencia útil contra la
que los auditores de TI pueden realizar su trabajo.
http://www.iso.org
Integración del modelo de madurez de capacidad
(CMMI, en inglés) – El Instituto de Ingeniería de
Software de la Universidad de Carnegie Mellon (SEI,
en inglés) ha publicado varios Modelos de Madurez de
Capacidad (CMM, en inglés) para diversos procesos de
la organización, principalmente relacionados con la
implementación de software. Algunos ejemplos son
el CMM de Ingeniería de Sistemas y el de Adquisición
de Software. Estos CMM proporcionan un modelo
para construir procesos controlables y sostenibles
dentro de una organización y son útiles para los
auditores de TI que realizan las auditorías de los
procesos de desarrollo de sistemas. En 2005, el SEI
integró todos los CMM existentes y creó CMMI.
http://www.sei.cmu.edu/cmmi/general/general.html
Instituto Nacional de Normas y Tecnología (NIST, en
inglés) – El Centro de Recursos en Seguridad de Datos
es una división del NIST que proporciona una serie
exhaustiva de publicaciones que ofrecen información
GTAG — Realización de la auditoría de TI — 6
detallada sobre temas de control de la seguridad de la
información. Entre dichas publicaciones se encuentra
la “Especificación biométrica de datos para la
verificación de la identidad personal” y la “Guía para
asegurar Microsoft XP para los profesionales de TI”.
Estas normas (imprescindibles para el auditor de
TI en el sector público, en la industria aeroespacial
y de defensa) proporcionan las mejores prácticas
que también se pueden aplicar a otros sectores.
http://csrc.nist.gov/publications/nistpubs/index.html
Instituto SANS (SysAdmin, Audit, Network, Security
Institute) – Se trata de una de las fuentes
mundialmente más fiables para la capacitación en
seguridad de la información (y definitivamente la más
grande). El Instituto SANS publica numerosos docu-
mentos sobre diversos aspectos de la seguridad de difer-
entes tecnologías. Las publicaciones SANS
proporcionan una serie de requisitos específicos
que un auditor de TI puede usar para auditar.
http://www.sans.org/aboutsans.php
Biblioteca de Infraestructura de TI (ITIL, en inglés) –
La Biblioteca de Infraestructura de TI está patrocinada
por el Instituto de Normas Británicas del Reino Unido
y proporciona las mejores prácticas para los servicios
de TI. Las publicaciones ITIL se centran en el soporte
de la gestión de los servicios de TI. Como tales, repre-
sentan una herramienta valiosa para el auditor interno
que realiza la auditoría del nivel correspondiente a la
gestión de TI. http://www.itil.co.uk/
Normas específicas del proveedor – Muchos proveedores
emiten pautas de seguridad y control de la tecnología
que producen. Por ejemplo, SAP edita una guía de
seguridad de tres volúmenes que proporciona
recomendaciones detalladas sobre la protección y con-
trol de la aplicación ERP SAP. A menudo, estas nor-
mas de proveedores no contemplan el mismo nivel de
control y seguridad que el que indicaría una publi-
cación NIST, pero brindan un buen punto de partida.
Además, pueden servir para limitar los debates sobre
los hallazgos de la auditoría (por ejemplo, “las restric-
ciones sobre las contraseñas SAP no se han estableci-
do de acuerdo a las especificaciones de los
requerimientos de seguridad documentados por el
proveedor”). Los DEA deben verificar con los provee-
dores si hay normas específicas disponibles para los sis-
temas críticos de la misión del negocio. En muchos
casos, el proveedor puede no haber realizado ninguna
publicación, pero seguramente lo ha hecho el grupo de
usuarios asociados a la tecnología en cuestión (por
ejemplo, el Grupo de usuarios de SAP de América).
6.2 Gestión de los recursos de auditoría de TI
Los recursos asignados para la ejecución de auditorías plani-
ficadas desempeñan un papel crítico en la eficiencia y efec-
tividad de las auditorías. La TI abarca una gama amplia de
15
tecnologías, el conjunto de habilidades requerido para audi-
tar la configuración de los filtros de seguridad es inmensa-
mente distinto del que se necesita para auditar las tablas para
la triple comprobación en el proceso de pagos de las aplica-
ciones Oracle. Será de primordial importancia unir los
conocimientos necesarios para llevar a cabo una auditoría de
TI específica con el auditor de TI apropiado.
Uno de los retos a que se enfrentan hoy en día los DEA
es la identificación, contratación y retención de profesion-
ales de auditoría de TI competentes. Inevitablemente,
cualquier debate en este aspecto girará en torno al tema de
la contratación de un profesional de TI, formándolo en téc-
nicas de auditoría versus la contratación de un auditor, for-
mándolo en TI. No existe una solución perfecta y siempre
existirán excepciones, pero como pauta, el DEA debe pensar
que ningún auditor de TI podrá realizar todas las auditorías
de TI. Por lo tanto, cualquier función de auditoría de TI
necesitará disponer de algunos auditores de TI que estén más
alineados con las aplicaciones y otros con las tecnologías de
infraestructura. Respecto a los primeros, generalmente resul-
ta más efectivo encontrar auditores, personal financiero o de
proceso y capacitarlos en una aplicación específica. Para los
auditores que estén más alineados con la auditoría de
infraestructuras, normalmente será más efectivo contratar
personal de TI y capacitarlos en técnicas de auditoría. Por
consiguiente, un DEA que tiene un sólido conocimiento del
universo actual de auditoría de TI y fija los conocimientos de
auditoría de TI actuales en el personal debe tener, conse-
cuentemente, la destreza de centrarse en la contratación de
los refuerzos.
Estrategia de retención de auditores de TI
Una vez que hayan sido contratados, el siguiente desafío será
la retención del personal. Los auditores de TI tienden a tener
más movilidad que los auditores tradicionales debido a que
los primeros escasean actualmente en el mercado. Una forma
de abordar este tema por parte del DEA es mejorar las ret-
ribuciones, aunque en muchos casos, los presupuestos no per-
mitirán dicha mejora, así que el DEA tendrá que ser creativo
a la hora de diseñar una estrategia de retención.
Muchos auditores de TI encuentran su motivación en la
exposición a las tecnologías y disfrutan de la experi-
mentación con tecnologías nuevas e interesantes. A contin-
uación, se presentan algunos aspectos que el DEA puede
emplear para lograr sus objetivos de retención del personal al
aprovechar el deseo del auditor de TI de mayor contacto con
las tecnologías.
Certificaciones – Existen algunas certificaciones rela-
cionadas con la tecnología, como las diversas certifica-
ciones sobre los ruteadores Cisco y técnicas de bases de
datos, además de las que cubren modelos específicos de
SAP. ISACA ofrece una de Auditor Certificado de
Sistemas de Información (CISA, en inglés). La certifi-
cación de la Fundación ITIL se refiere a conocimien-
tos básicos de los diversos procesos ITIL para la gestión
 GTAG — Realización de la auditoría de TI — 6
y entrega de servicios. Esta certificación es obligatoria
para los auditores de TI que revisan departamentos de
TI que emplean procesos ITIL.
El DEA puede considerar la posibilidad de otorgar
al auditor una bonificación en función de las certifica-
ciones relacionadas con los conocimientos más
demandados, como el caso de un auditor de TI que
recibe una bonificación por haber obtenido la certifi-
cación “Asociado Certificado en Redes Cisco”
(CCNA, en inglés). Esto permite a la organización dar
una retribución adicional sin la necesidad de aumentar
el salario de base. Además, muchas de estas certifica-
ciones requieren un tiempo significativo para su
obtención, así se asegura que el auditor de TI per-
manecerá, como mínimo, ese tiempo hasta la certifi-
cación. No obstante, la experiencia nos dice que en
algunas ocasiones el auditor de TI se dedicará a reunir
certificaciones con vistas a salir de la función de audi-
toría. Será conveniente examinar cuidadosamente las
certificaciones que el auditor de TI desea obtener para
asegurarse de que se encuentren dentro del universo de
auditoría de TI planificado.
Rotación – Se puede considerar un programa de rotación
entre el departamento de TI y la función de la audi-
toría interna de TI. Esto puede ayudar a incrementar la
capacidad de auditoría de TI, así como a fortalecer su
relación con dicho departamento. Hay que tener en
cuenta el factor de independencia al emplear una
estrategia de este tipo. También sería conveniente ase-
gurar que la función de auditoría de TI sea capaz de
proporcionar algunos conocimientos de auditoría al
personal sujeto a rotación.
Formación continua – ILos auditores de TI necesitarán
más formación que los auditores de proceso o de opera-
ciones. El proceso de la triple comprobación ha exper-
imentado pocas modificaciones de importancia en los
últimos años, pero sin duda alguna se han dado pasos
gigantes en TI. Para que los auditores de TI se manten-
gan actualizados, necesitan capacitación anticipada y
frecuente. El DEA debe reconocerlo y realizar una
estrategia de capacitación para el departamento, que
contemple las necesidades de los auditores de TI.
También se debe considerar el desarrollo de experien-
cia en una amplia gama de aspectos de importancia.
Esto se puede lograr designando algunos auditores de
TI como especialistas en una tecnología determinada
(por ejemplo, un auditor de TI, especialista en
Microsoft; otro, en bases de datos y un tercero, en
SAP). Así se obtendrá mejor calidad en las auditorías
que si se intentara formar a todos los auditores de TI en
todos los temas. No obstante, se requiere mayor dili-
gencia y planificación a la hora de elaborar un plan de
formación para el año.
Grupos de usuarios – La mayoría de los proveedores de
tecnologías mantienen grupos de usuarios integrados
16
por clientes que utilizan la tecnología en cuestión y que
se reúnen para compartir sus ideas y los temas que les
preocupan, y si es posible, influir en los futuros desar-
rollos de la tecnología. Si bien dichos grupos tradi-
cionalmente se componen de profesionales de TI y
usuarios del negocio podrían también ser de valor para
los auditores de TI. El Grupo de usuarios de SAP de
América, por ejemplo, mantiene un subgrupo centrado
en la seguridad y los controles. Los auditores de TI
deben buscar los grupos de usuarios para las tecnologías
críticas y formar parte de ellos. En muchos casos, no
significará un incremento del coste para la organi-
zación. La mayoría de los grupos se gestionan a nivel de
empresa y no se restringe su acceso a los empleados.
Dotación adecuada de personal
En muchos casos existen restricciones presupuestarias en la
función de auditoría de TI que impiden que haya una
nómina con la gama de conocimientos necesarios para abor-
dar el universo de auditoría de TI de manera efectiva. La
organización no puede esperar que el departamento de TI
funcione sin el personal con experiencia en sistemas
operativos, bases de datos, redes y aplicaciones. Sin embar-
go, a veces parece que se piensa que la función de auditoría
de TI puede funcionar sin los recursos adecuados. Esto
inevitablemente da lugar a que se realicen las auditorías
basándose en cuestionarios o empleando técnicas de
entrevista como principales fuentes de evidencia de
auditoría. Tal como se ha indicado a través de todo este
documento, si se pretende que la función de auditoría
de TI sea efectiva, debe contar con un plan específico de
auditoría guiado por una evaluación sólida de riesgos
y con el respaldo de procedimientos de auditoría diseñados
específicamente en función de las particularidades del
entorno en cuestión. El DEA debe justificar, ante la alta
dirección y el comité de auditoría, la necesidad presupues-
taria de mantener una gama de conocimientos para las audi-
torías de TI.
Una de los principales motivos para que el DEA abogue
por el mantenimiento de suficientes recursos tiene su origen
en el párrafo 140 de la Norma N.º 2 del Consejo Superior
Contable de Empresas Públicas de EE. UU. (PCAOB, en
inglés), una auditoría de los controles internos de la informa-
ción financiera realizada conjuntamente con la revisión de
los estados contables, que dice lo siguiente:
“la siguiente [circunstancia] debe considerarse al
menos como una deficiencia importante y un fuerte
indicador de que existe una debilidad material en los
controles internos de la información financiera… La
función de auditoría interna o la de evaluación de los
riesgos carece de efectividad en una empresa para la
cual esa función debe ser lo suficientemente eficaz
como para tener un componente efectivo de evalu-
ación de riesgo y supervisión, como en el caso de
empresas de gran tamaño o complejidad.”
GTAG — Realización de la auditoría de TI — 6
La ausencia de una función de auditoría interna de TI o
una presencia limitada dentro de una organización con un
entorno de TI grande o complejo puede tener como conse-
cuencia que el auditor externo de la organización concluya
que se debe aplicar el párrafo 140.
En algunas circunstancias, el DEA puede contemplar la
posibilidad de apoyarse en el co-sourcing (utilización de una
mezcla de recursos internos y externos), para las auditorías
de TI. La mayoría de los DEA entiende las ventajas y
desventajas del co-sourcing y esta guía no pretende pro-
moverlo. Sin embargo, los DEA normalmente luchan con
este tema para determinar el grado en que deben compartir
recursos y en qué auditorías de TI aplicarlo. La mezcla ópti-
ma varía según la organización (aquí se aplica otra vez la
teoría del copo de nieve), pero el DEA podría tomar como
benchmark los siguientes datos del informe de la Red Global
de Información de Auditoría (GAIN, en inglés) del Instituto
de Auditores Internos (IIA) de 2004:
• El 39% de todos los servicios externalizados de audi-
toría están asociados a la auditoría de TI.
• Los porcentajes de trabajos de auditoría de TI que se
externalizan son los siguientes:
- 8,1% de las organizaciones externalizan el
100% de su trabajo de auditoría de TI.
- 7,1%, la mayor parte del trabajo de auditoría
de TI.
- 8,3%, entre el 25% y 50% de los trabajos de
auditoría de TI.
- 33,1%, algunos trabajos de auditoría de TI.
- 41,6% no externalizan ningún trabajo de la
auditoría de TI.
• La estrategia para los siguientes tres años consiste en lo
siguiente:
- El 18,9% de las organizaciones tienen previsto
aumentar la externalización del trabajo de audi
toría de TI.
- El 64,9% no tienen previsto modificar el nivel
de subcontratación de auditoría de TI.
- El 13,3% de las organizaciones tiene previsto
disminuir la subcontratación de auditoría de TI.
Algunas sugerencias adicionales con respecto al tema de co-
sourcing son las siguientes:
Co-sourcing para auditorías técnicas: En este caso, el térmi-
no “auditorías técnicas” se refiere a las que se realizan en
las capas de aplicación e infraestructura técnica del
entorno de TI. Generalmente estas auditorías requieren
un nivel mayor de conocimientos técnicos específicos, y
estos más probablemente se encuentren externamente que
internamente. Por otro lado, las auditorías de TI del nivel
gerencial se centran más en los procesos de TI (por ejem-
plo, el desarrollo de sistemas) por lo que requieren menos
profundidad en cuanto a conocimientos técnicos.
17
Examinar la posibilidad de emplear dos proveedores: En
co-sourcing, tal vez sea útil contratar a un proveedor
secundario, además del proveedor principal de servicios.
En algunos casos, puede ocurrir que un proveedor eviden-
cie un conflicto de intereses para la realización de una
auditoría determinada por alguna razón; en ese caso, se
puede disponer del segundo proveedor de respaldo que
estará listo para intervenir. No obstante, hay que tener
cuidado en este tema y asegurar que el proveedor principal
realice al menos el 80% de las actividades externalizadas.
Una proporción menor daría lugar a la disminución de la
eficiencia (dado que, por ejemplo, se duplicarían las
reuniones y aumentaría la carga administrativa), reducien-
do las ventajas. No se deben emplear más de dos provee-
dores para asegurar que ellos puedan aprender bien el
negocio de la organización y la traten como cliente impor-
tante. Si la empresa ABC suministra la mayor parte de los
servicios relacionados con las auditorías de TI, su relación
será bastante distinta que si se encuentra entre dos o tres
firmas y sólo suministra el 30% de dichos servicios de audi-
toría de TI.
Externalización de las auditorías que se realizan a nivel
mundial: La mayoría de las empresas mantienen emplead-
os en todas las regiones más importantes del mundo y
emplean distintas estructuras de tarifas para los recursos
locales. Por lo tanto, si una organización desea auditar sus
operaciones en Kuala Lumpur, podría emplear una empre-
sa con recursos locales en Malasia con un coste reducido,
en lugar de enviar los recursos a Malasia. La excepción a
esta recomendación se produce cuando el estatuto de audi-
toría interna establece que la función de auditoría interna
debe proporcionar un grado de servicio de consultoría a las
unidades de negocio con respecto a los controles. En dicho
caso, será conveniente emplear un equipo de auditoría que
cubra los distintos países a fin de implementar las “mejores
prácticas” internas, tal equipo será compartido entre las
unidades de negocio.
 GTAG — Aceleradores de auditoría de TI — 7
Como se ha comentado anteriormente, los presupuestos para
la auditoría de TI entrañan dificultades en cuanto a esti-
mación y gestión. El DEA debe buscar oportunidades para
usar aceleradores (herramientas y/o técnicas que dan soporte
a los procedimientos realizados por los auditores de TI) para
aumentar la eficiencia y efectividad de la auditoría. El DEA
puede emplear un acelerador para realizar la misma auditoría
en menos tiempo, o realizar procedimientos de auditoría en
mayor detalle sin reducir el tiempo.
Muchos aceleradores requieren una inversión, así que el
DEA debe considerar cuidadosamente la relación coste o
beneficio de cualquier solución antes de realizar la inversión
en un acelerador. Los aceleradores de auditoría se pueden
dividir en dos grandes categorías: los facilitadores de audi-
toría que darán soporte a la gestión global de la auditoría
(por ejemplo, una herramienta para papeles de trabajo elec-
trónicos), o los aceleradores de pruebas, que son herramien-
tas que automatizarán las pruebas de auditoría (por ejemplo,
herramientas para el análisis de datos).
7.1 Facilitadores de auditoría
Papeles de trabajo electrónicos
Aunque esto no sólo se aplica a las auditorías de TI, la
gestión de papeles de trabajo electrónicos puede ser de gran
utilidad. Dichas soluciones proporcionan la gestión central-
izada, la retención de los papeles de trabajo, la gestión del
flujo de trabajo, la trazabilidad de las versiones, el cierre elec-
trónico del trabajo, etc… Existe una variedad de provee-
dores que ofrecen estas herramientas. Es importante
considerar su funcionalidad. Por ejemplo, si la herramienta
en cuestión puede dar soporte a varias auditorías de manera
simultánea. Sería conveniente definir los requerimientos
funcionales de auditoría antes de su implementación. No
obstante, quizás es más importante el contenido que ofrezca
la herramienta. ¿Dispone de sugerencias sobre procedimien-
tos de auditoría o actividades de control? Sin duda, los DEA
tendrán que personalizar la base de conocimientos,
cualquiera sea la que esté incorporada en la herramienta, si
bien servirá como buen punto de partida.
Programas para la gestión de proyectos
Aunque no se emplean solamente para auditorías, los progra-
mas para la gestión de proyectos sirven para crear calendar-
ios para los planes de trabajo, asignar el responsable de cada
tarea, llevar un seguimiento de los plazos importantes y de
los informes/resultados a entregar, y la función de la audi-
toría de TI puede emplear dichos programas para obtener
consistencia adicional en el trabajo y en los informes de
auditorías de TI. El 35% de los que respondieron a la encues-
ta GAIN de 2004 emplean programas para la gestión de
proyectos.
Programas de diagramas de flujo
SEl software que gráficamente documenta el flujo de transac-
ciones, los puntos de control y los pasos clave de los proce-
18
sos es de gran utilidad, casi necesario, a la hora de documen-
tar los procesos, y en particular para el cumplimiento de la
legislación estadounidense de Sarbanes-Oxley. El almace-
namiento electrónico de la documentación gráfica sobre los
procesos facilita su actualización y permite que se almacene
y se comparta fácilmente. El 59% de los que respondieron a
la encuesta GAIN de 2004 utilizan software para los diagra-
mas de flujo.
Programas para el control de los asuntos abiertos
Este software permite el control o seguimiento de todos los
asuntos de auditoría pendientes o deficiencias y a menudo se
integra con el software para la gestión documental, y en par-
ticular aquel que ha sido diseñado para cumplir con la legis-
lación estadounidense de Sarbanes-Oxley. Su funcionalidad
normalmente incorpora la posibilidad de asignar respons-
abilidades para los procedimientos correctivos con sus corre-
spondientes fechas de entrega y documentos a entregar, así
como el control y los informes sobre su progreso. El 47% de
los que respondieron a la encuesta GAIN del 2004 utilizan
software de este tipo.
Sitio Web del departamento de auditoría
Muchos departamentos de auditoría han establecido sitios
Web departamentales que normalmente se colocan en la
Intranet, si bien también pueden estar en Internet. Las solu-
ciones basadas en Internet ofrecen la posibilidad de compar-
tir información a través de distintas organizaciones, aunque
a su vez dan lugar a temas de confidencialidad. Ambas solu-
ciones proporcionan a la función de la auditoría interna la
posibilidad de mantener una forma centralizada de compar-
tir información y comunicarla. Se pueden desarrollar inter-
namente o se pueden adquirir a un proveedor. El 42% de los
que respondieron a la encuesta GAIN de 2004 cuentan con
un sitio Web para sus departamentos de auditoría.
7.2 Aceleradores para pruebas
Los aceleradores para pruebas pueden automatizar tareas
de auditoría que consumen mucho tiempo, como la revisión
de grandes cantidades de datos. Asimismo, el uso de una her-
ramienta para realizar procedimientos de auditoría ayuda a
establecer una consistencia. Por ejemplo, si se emplea una
herramienta para evaluar la configuración de seguridad de
los servidores, todas las pruebas realizadas sobre ellos emple-
ando esta herramienta serán evaluadas sobre la misma base.
Si dichas pruebas se realizan de forma manual, existirá un
grado de interpretación por parte del auditor de TI. Por últi-
mo, el empleo de herramientas de este tipo permite a los
auditores de TI realizar pruebas sobre una base de datos com-
pleta, en lugar de sólo sobre una muestra de transacciones,
esto permite un grado mucho mayor de confianza de la audi-
toría.
El DEA debe tener en cuenta las siguientes considera-
ciones con respecto a los aceleradores de auditoría de TI:
• Las herramientas implican un coste. Antes de su
GTAG — Aceleradores de auditoría de TI — 7
implementación, el DEA debe asegurarse de que sus
beneficios superen los costes correspondientes.
• Se deberá capacitar a los auditores de TI en el uso de la
nueva herramienta. A veces ocurre que el departamen-
to de auditoría interna posee una herramienta que no
se utiliza porque nadie sabe cómo se debe usar, esto
claramente disminuye el rendimiento de la inversión.
• La herramienta requerirá soporte, gestión de parches y
actualizaciones. Según la herramienta en cuestión,
puede suceder que requiera un servidor propio. Por este
motivo, la selección de la herramienta se debe ges-
tionar con la ayuda del departamento de TI.
• En algunos casos, la gestión de TI o el contrato del
proveedor no permite el acceso directo de estas her-
ramientas al entorno de producción. Es conveniente
analizar en profundidad los temas relacionados con las
herramientas y/o secuencias de comandos con la
gestión de TI, y obtener su aprobación, además de pro-
bar tales herramientas antes de su implementación.
Programas para análisis de datos
Estas herramientas permiten al auditor de TI realizar un análi-
sis estadístico sólido sobre grandes bases de datos. Se pueden
emplear como soporte para las auditorías operativas o de
proceso (por ejemplo, la revisión de pagos para la detección de
fraudes), además de poder realizar muchos tipos de prueba,
como el análisis de Benford, el muestreo acumulativo, etc…
Un tema a considerar a la hora de utilizar una herramienta
para el análisis de datos es que puede ser difícil extraer
los datos de la fuente original. Es crítico llevar a cabo
procedimientos de auditoría para determinar si los datos fuente
son completos y correctos. Algunos de los principales provee-
dores en este tema son:
• ACL: http://www.acl.com/Default.aspx?bhcp=1
• Idea: http://www.audimation.com/product_feat_
benefits.cfm
• Monarch: http://monarch.datawatch.com/
• SAS: http://www.sas.com/
Herramientas para análisis de la seguridad
Se trata de una amplia gama de herramientas que pueden revis-
ar un gran grupo de dispositivos y/o usuarios e identificar las
exposiciones de seguridad. Existen muchos tipos distintos de
herramientas para el análisis de la seguridad, aunque general-
mente se pueden clasificar de la siguiente manera:
Herramientas para el análisis de redes – Son programas
de software que se pueden ejecutar en una red y recopilar
datos sobre ella. Los piratas informáticos normalmente
emplean este tipo de herramientas en el punto de entra-
da de un ataque para determinar el aspecto que tiene la
red. Los auditores de TI pueden emplear estas herramien-
tas para una diversidad de procedimientos de auditoría,
incluidos los siguientes:
• Verificar la exactitud de los diagramas de la red medi
ante el mapeo de la red corporativa.
19
• Identificar los principales dispositivos de red que
merecen mayor atención por parte de auditoría.
• Recopilar datos sobre qué tráfico se permite a través
de la red (esto respaldará directamente el proceso de
evaluación de riesgos de TI).
Se puede obtener una lista de las 75 herramientas princi-
pales en www.insecure.com.
Herramientas contra piratería informática: La mayoría
de las tecnologías poseen vulnerabilidades estándar,
como las identificaciones, las contraseñas o los parámet-
ros predeterminados que se evidencian cuando la tec-
nología que se instala es del tipo “lista para usar”. Las
herramientas contra la piratería informática proporcio-
nan un método automático para la verificación de las
vulnerabilidades estándar. Esas herramientas pueden diri-
girse contra filtros de seguridad, servidores, redes y sis-
temas operativos. Muchas de ellas son del tipo “listas
para usar”, el auditor de TI ingresa el intervalo en el que
desea que la herramienta realice la búsqueda, se va y
cuando regresa en unas horas o al día siguiente, verá que
la herramienta ha desarrollado un informe sobre las vul-
nerabilidades identificadas en ese intervalo.
Estas herramientas son importantes para un auditor de TI
por varios motivos, entre ellos porque son las mismas que
utiliza un pirata informático para organizar un ataque
contra la organización. La organización debe, como míni-
mo, disponer de la misma información que el pirata
informático. Es importante señalar que algunas de estas
herramientas son potencialmente peligrosas al ser ejecu-
tadas, ya que pueden afectar la integridad de los sistemas
que escanean. El auditor de TI debe revisar la utilización
prevista de este tipo de herramienta con el responsable
de seguridad y coordinar las pruebas con la gestión de TI
para asegurar que, a la hora fijada, el análisis no afecte el
proceso de producción. En algunos casos, puede ocurrir
que el responsable de seguridad o los administradores de
sistemas ya ejecuten algunas de estas herramientas regu-
larmente, como parte de los procesos de gestión de sis-
temas. En ese caso, si están diseñadas y se ejecutan
apropiadamente, sus resultados se podrán emplear para
dar soporte a las auditorías de TI. Se puede obtener una
lista de las 75 herramientas principales en www.insecure.
com.
Herramientas para análisis de la seguridad en las apli-
caciones: – Si una organización utiliza una aplicación
integrada de gran tamaño (como ERP, SAP u Oracle),
muchos de los controles internos clave dependen en gran
medida de la seguridad. Por ejemplo, la política corpora-
tiva de la empresa XYZ requiere que todos los pagos de
más de USD10.000 sean aprobados por la dirección antes
de que se efectúen: Esto ciertamente es un buen control.
Supongamos que dicha empresa ha configurado su sis-
tema Oracle para que cualquier pago de más de
USD10.000 se coloque automáticamente en una cola de
espera para su aprobación y liberación. Esto también rep-
 GTAG — Aceleradores de auditoría de TI — 7

resentaría una forma sólida de cumplir con la política de

la empresa. Sin embargo, si se asume que todos los usuar-
ios del sistema Oracle tienen acceso completo al sistema,
entonces claramente cualquier usuario podría entrar en la
cola de espera para aprobar y liberar el pago. Por este
motivo se debe diseñar bien la seguridad a nivel de la
aplicación en conjunto con sus procesos y controles.
También, esto representa un ejemplo de por qué
cualquier tipo de auditoría (financiera, de proceso, opera-
tiva o de TI) dentro del entorno de una aplicación
integrada de gran tamaño necesita incorporar un compo-
nente de seguridad para que sea efectiva.
Desafortunadamente, muchos proveedores no consideran
que el desarrollo de la funcionalidad para dar soporte a las
auditorías de seguridad de usuarios sea una prioridad, y
tienden a centrarse más en los aspectos operativos. Como
consecuencia, a menudo la realización de las auditorías de
seguridad de aplicaciones es engorrosa y requiere mucho
tiempo. Dichas auditorías se pueden acelerar empleando
una herramienta para el análisis de la seguridad, muchas de
las cuales tienden a ser específicas de la aplicación
(PeopleSoft, SAP o Oracle), y analizan la seguridad de
usuarios contra reglas preconfiguradas. Estas herramientas
también pueden evaluar la separación de funciones dentro
de la aplicación. El DEA debe de tener en cuenta
que muchas de estas herramientas poseen parámetros pre-
configurados o se basan en las “mejores prácticas” promovi-
das por el proveedor. Debido a la teoría del “copo de nieve”,
cualquier implementación de una herramienta de este
tipo tendrá que ser acompañada de un proyecto sustantivo
para crear el conjunto de parámetros o reglas relevantes
adecuadas a la organización en cuestión. La omisión de estas
acciones resultará en informes de auditorías que contengan
resultados positivos-falsos o negativos-falsos.
Algunos de los principales proveedores para este tema son:
• Approva: http://www.approva.net/
• LogicalApps: http://www.logicalapps.com/
• Virsa: http://www.virsa.com/
• Q Software: http://www.qsoftware.com/index.htm
• Control Solutions International:
http://www. csi4sap.com/en/home/

20
 GTAG — Preguntas para el DEA— 8

La auditoría de TI es de larga data, si bien constantemente realización de pruebas)? ¿Si la respuesta es negativa,
evoluciona y se modifica. Como consecuencia de ello, el por qué no? ¿Si la respuesta es positiva, estas han sido
DEA debe continuamente adaptar y desarrollar el enfoque probadas y aprobadas por la gestión de TI?
de auditoría de TI, así como el universo de auditoría de TI • ¿Con qué tipo de personal cuenta el departamento de
para realizar los procedimientos de auditoría de TI necesar- TI? ¿Se emplean especialistas para las diversas tec-
ios con objeto de lograr un cumplimiento adecuado de las nologías (por ejemplo, aplicaciones versus tecnologías
normas y ayudar en la gestión del riesgo global de negocio de de infraestructura)? ¿Si la respuesta es negativa, por
la organización. qué no? ¿Cómo se revisan los papeles de trabajo de
Aunque esta guía no cuenta con todas las soluciones y, auditoría de TI en cuanto a su adecuación y calidad?
en algunos casos, incluso puede llegar a generar más pregun- • ¿Se ha establecido una estrategia de capacitación para
tas que respuestas, se espera que el DEA pueda utilizarla los auditores de TI? ¿Se consideran todos los niveles
como herramienta de ayuda en esa evolución. Se han inclu- del entorno de TI?
ido las siguientes preguntas para ayudar a los DEA cuando • ¿Se evalúan anualmente los temas emergentes y los
consideren estos temas dentro del contexto de su organi- riesgos para determinar su relevancia dentro de la orga-
zación: nización? ¿Cómo se identifican los temas emergentes
• ¿La organización ha definido claramente qué significa dentro de la organización?
la TI para ella? ¿Se han documentado las áreas de • ¿La función de auditoría ha comparado la función de
responsabilidad del director de TI (CIO, en inglés)? auditoría de TI con determinados patrones de referen-
¿Se han considerado todas las áreas en el enfoque de cia y mejores prácticas de la industria? ¿Se ha emplea-
auditoría de TI al evaluar el riesgo y definir el universo do la encuesta GAIN u otro repositorio de datos para
de auditoría de TI? facilitar el proceso?
• ¿Anualmente, la función de la auditoría interna realiza • ¿Todas las auditorías de proceso contienen proced-
una evaluación efectiva del riesgo de TI? ¿Han partici- imientos que evalúan los parámetros de configuración
pado en dicha evaluación especialistas en tecnologías de las aplicaciones que automatizan los procesos?
de infraestructura, sistemas de aplicación y procesos de ¿Cómo se coordinan estos procesos entre los recursos
TI? de auditoría (procesos versus TI )?
• ¿La evaluación de los riesgos tiene en cuenta la arqui-
tectura tecnológica específica y la configuración
empleada por la organización?
• ¿Cómo se cuantifican los riesgos de TI? ¿Se considera
tanto la estimación de su impacto como la de la proba-
bilidad de su ocurrencia? ¿Qué referencias del sector y
“mejores prácticas” se utilizan para respaldar esas esti-
maciones?
• ¿En el universo de auditoría de TI, se planifican audi-
torías para cada nivel del entorno de TI? ¿Y de no ser
así, por qué? ¿Existen circunstancias especiales o es que
el plan de auditoría no es el óptimo?
• ¿Cómo se estiman los presupuestos de auditoría de TI?
¿Se han recopilado suficientes datos para respaldar una
estimación correcta? ¿Se ha tenido en cuenta la config-
uración específica de la tecnología?
• ¿Cómo se definen los procedimientos de auditoría de
TI? ¿Se desarrollan internamente para el entorno
específico de la organización, o se emplean cuestionar-
ios disponibles en el mercado?
• ¿Se han implementado estructuras de control y normas
de TI dentro de la organización? ¿Si es así, cuáles? ¿En
caso contrario, se han establecido internamente líneas
de base para la seguridad y el control? ¿Si no se ha
hecho, el DEA ha recomendado su implementación
como parte de la auditoría de dirección y gobierno de
TI?
• ¿Se emplean herramientas para acelerar las auditorías
de TI (por ejemplo, aceleradores o facilitadores para la

21
GTAG — Apéndice A — Temas emergentes
La Ley de Moore pronostica la evolución continua de las tec-
nologías. Este apéndice cubre algunas de las tecnologías
emergentes que deben tener en cuenta los DEA, y su poten-
cial impacto sobre la organización y la función de auditoría
de TI. De ninguna manera representa una lista completa de
las tecnologías emergentes, aunque sí un indicador de
algunos de los asuntos más sobresalientes en el mercado.
Estos asuntos ciertamente variarán de entorno a
entorno (la teoría del “copo de nieve”) y pueden representar
un riesgo mayor o menor según el sector de industria, la tec-
nología, o las prácticas de negocio. Los asuntos con sus cor-
respondientes riesgos y recomendaciones se presentan sin un
orden predeterminado y pretenden estimular la reflexión del
DEA en cuanto a su entorno específico y si la auditoría de TI
programada en ese momento evalúa tales asuntos.
A.1 Redes inalámbricas
Las redes inalámbricas proliferan a través de las organiza-
ciones porque son útiles y pueden dar soporte directo a los
objetivos de negocio. Sin embargo, también son fáciles de
instalar (como lo puede corroborar cualquiera que haya
hecho esto en su propio domicilio) y forman un punto
potencial por el que se puede entrar a la red corporativa. Los
DEA deben preocuparse tanto por la seguridad de las redes
inalámbricas autorizadas por la organización, así como por
aquellas establecidas por usuarios sin autorización.
Riesgos de una red inalámbrica
Intrusión: Las redes inalámbricas facilitan la entrada no
autorizada a la red corporativa.
Interceptación furtiva: Las redes inalámbricas permiten
que personal no autorizado tenga acceso a datos confi-
denciales transmitidos a través de la red inalámbrica.
Piratería informática: Un usuario no autorizado podría
suplantar la identidad del usuario autorizado en una
sesión de la red inalámbrica y utilizarla para obtener
acceso a la red corporativa.
Gestión de radiofrecuencia: Es posible que la red inalám-
brica envíe transmisiones a zonas no deseadas, y esto
puede tener otros impactos. Por ejemplo, en los hospi-
tales pueden existir equipos que reaccionen negativa-
mente a las transmisiones por ondas de radio, y por lo
tanto no se debe exponerlos a redes inalámbricas.
Recomendaciones con respecto a una red inalámbrica
Se debe realizar una auditoría exhaustiva de la red inalámbri-
ca que incorpore los siguientes dos componentes:
• Es bastante probable que la organización cuente con
redes inalámbricas que han sido aprobadas e imple-
mentadas por un motivo específico de negocio. La fun-
ción de auditoría de TI debe evaluar dichas redes para
asegurar que la seguridad y los controles cumplen con
los objetivos de la dirección.
• Es posible que existan dentro de la organización redes
22
inalámbricas no autorizadas establecidas por los usuar-
ios. La función de auditoría de TI debe realizar proced-
imientos para detectar su existencia y tomar las
acciones necesarias. Será más difícil efectuar esa com-
probación que asegurarse de que las redes son seguras y
están controladas, y es probable que el auditor de TI
deba dar un paseo a través de las instalaciones con una
antena para detectar su presencia.
Como mínimo, el auditor de TI debe obtener y revisar
la lista de todas las redes inalámbricas aprobadas por la orga-
nización. Se deben establecer políticas y procedimientos
para esas redes, y esos deben proporcionar las pautas de
seguridad y control de dichas redes incorporando el uso del
cifrado de de datos y la autenticación de la red inalámbrica.
El auditor de TI debe revisar la configuración de las redes
inalámbricas conocidas para asegurar que cumplen con las
políticas y procedimientos desarrollados, y para detectar la
existencia de redes no autorizadas a fin de que se adopte la
acción correctiva correspondiente.
A.2 Dispositivos móviles
La mayoría de las organizaciones reconocen el valor de los
dispositivos inalámbricos, como los teléfonos Blackberry, los
dispositivos PDA, Smart Phones o las unidades TELXON,
que han proliferado para dar respaldo a los objetivos de nego-
cio. Sin embargo, muchas organizaciones no comprenden el
riesgo que conlleva su utilización.
Los riesgos asociados a la utilización de
dispositivos móviles
Muchos de estos dispositivos almacenan datos críticos para
el negocio. Si el dispositivo no ha sido configurado de man-
era segura, la confidencialidad de los datos puede verse afec-
tada en caso de extravío o robo. Asimismo, puede que la
transmisión de los datos al dispositivo no se haga de forma
segura, y esto puede afectar la confidencialidad o integridad
de los datos. Como estos dispositivos suelen ser utilizados por
la alta dirección, los datos de la empresa pueden verse afec-
tados. Además, en algunos casos, permiten el acceso remoto
a las redes de la empresa, y en el caso de los TEXLON u otros
dispositivos similares, hasta incluso se puede iniciar el proce-
so de transacciones. Consideremos por ejemplo el caso de
una empresa distribuidora de bebidas que equipa a los con-
ductores de ruta con dispositivos inalámbricos para contabi-
lizar las transacciones de inventario a medida que se realizan
las entregas al cliente.
Recomendaciones con respecto a los dispositivos móviles
El auditor de TI debe revisar la gestión de los dispositivos
móviles, y como mínimo considerar los siguientes aspectos:
Aprovisionamiento: Se refiere al proceso de aprovision-
amiento de los dispositivos
Estandarización: ¿Se han estandarizado los dispositivos?
Configuración de la seguridad: Que tipo de políticas y
 GTAG — Apéndice A — Temas emergentes
procedimientos se han establecido para definir las
líneas de base de seguridad de los dispositivos?
Transmisión de datos: ¿Cómo se controla la transmisión
de datos?
Acceso a las redes corporativas: ¿Permiten los disposi-
tivos el acceso a la red corporativa, y en tal caso, cómo
se controla?
Extravío o robo del dispositivo ¿Cómo se identifican los
dispositivos ante extravíos o robos para discontinuar el
servicio?
Software de interfaz: ¿Si los dispositivos permiten iniciar
transacciones de negocio, cómo se conectan con las
aplicaciones de la empresa?
A.3 Interfaces
Los entornos más complejos de TI a menudo requieren inter-
faces complejas para integrar sus aplicaciones críticas de
negocio. Muchas veces, incluso los entornos ERP de gran
tamaño requieren interfaces complejas para comunicarse
con otras aplicaciones, como los sistemas de Internet. Dichas
interfaces pueden funcionar con tecnología middleware que
actúa como punto central de comunicación y coordinación
de las interfaces. Aunque su papel es importante en el proce-
so completo de las transacciones, a menudo no se incluye en
los planes de auditoría. Esto puede deberse a que las inter-
faces son difíciles de clasificar. Funcionan de manera similar
a una tecnología de infraestructuras o de soporte, pero son
aplicaciones de software que hasta pueden procesar transac-
ciones.
Los riesgos de las interfaces
Las interfaces, y la tecnología middleware en particular, for-
man un enlace crítico en el proceso completo de las transac-
ciones. Como mínimo, mueven datos de un sistema a otro.
Como máximo, pueden ser responsables de la transforma-
ción de datos, realizando algunos cálculos o modificando los
datos en base a algún algoritmo. También, pueden represen-
tar un único punto de fallo para la organización. En el caso
de la empresa XYZ que opera un sistema ERP para su consol-
idación financiera, todas las unidades distribuidas de negocio
mantienen interfaces desde una diversidad de sistemas dis-
pares hasta el sistema central de la empresa. Existen unas
200 interfaces, todas las cuales funcionan a través de un
único servidor y aplicación middleware. Si de repente dejara
de funcionar el servidor middleware, las operaciones de la
empresa se verían sustancialmente afectadas.
Recomendaciones para las interfaces
El DEA debe asegurarse de que en la evaluación de los ries-
gos de TI y el universo de auditoría se consideren las inter-
faces y el middleware, teniendo en cuenta los siguientes
aspectos específicos::
Uso de software para gestionar las interfaces:
¿Interviene el software en la transformación de datos,
o simplemente los mueve de un sitio a otro?
23
Identificación de las interfaces: Posiblemente, el soft-
ware de interfaz requiera el acceso a los sistemas
desde los cuales se extraen o hacia los cuales se
mueven datos. ¿Cómo se gestiona dicho acceso?
¿Se emplean identificaciones genéricas? ¿Qué nivel de
acceso tienen esas identificaciones, y quién tiene
acceso al uso de ellas?
Directorios de interfaces: ¿Se mueven todos los datos a
través de un único directorio de interfaces?
¿Quién tiene acceso al directorio? ¿Cómo se protege y
se controla? Por ejemplo, ¿el empleado de una de las
unidades de negocio tiene acceso al directorio para
cargar un archivo para el procesamiento de la
transacción? ¿En caso de que sea así, contiene el
directorio los datos necesarios para transferencias
o pagos electrónicos? ¿Cómo se restringe el
acceso del empleado a dichos conjuntos de datos?
¿Los datos potencialmente se pueden combinar?
Tipos de interfaces: ¿Qué tipos de interfaces se usan?
¿Se utilizan en procesos en tiempo real o en procesos
por lote? ¿Pueden iniciar el procesamiento de otras
transacciones (por ejemplo, pedidos mediante una
interfaz que inicie el envío de mercaderías)?
A.4 Gestión de datos
Cada vez más, las organizaciones realizan automáticamente
sus procesos y funciones de negocio, a la vez que se
abaratan simultáneamente los costes de almacenamiento
de datos. Las computadoras personales de hoy en día
disponen, en algunos casos, de discos duros capaces de
almacenar 250GB o más, una capacidad mucho mayor de la
que tenían los grandes servidores hace cinco años. Esto da
lugar a la proliferación de grandes soluciones para el
almacenamiento de los datos empresariales y no es inusual
que una organización de tamaño medio almacene y gestione
terabytes de datos del negocio. Surgen algunos temas al
gestionar repositorios de datos de tal magnitud.
Riesgos asociados a la gestión de datos
La carencia de gestión en cuanto a repositorios de datos,
o red de área de almacenamiento (SAN, en inglés), puede
ocasionar la pérdida de disponibilidad de datos críticos
del negocio. Las organizaciones se deben asegurar de que
la integridad de esas soluciones de almacenamiento
se mantenga de manera adecuada. Sin embargo, puede
resultar difícil respaldar o reorganizar una red de
almacenamiento de datos que contenga seis terabytes de
datos del negocio. Se deben respaldar con nuevas
tecnologías de mantenimiento y gestión, así como
definir los procesos correspondientes. Además, el
incremento en el volumen de almacenamiento de datos
también coincide con la promulgación de nuevas leyes,
regulaciones y normas sobre gestión de datos con las
que las organizaciones deben cumplir, al igual que
con las normas del sector.
GTAG — Apéndice A — Temas emergentes
Recomendaciones para la gestión de datos
Se debe realizar una revisión a fondo de la gestión de datos
que tenga en cuenta, como mínimo, los siguientes aspectos:
Clasificación de datos: ¿La organización ha realizado el
proceso de clasificar sus datos? ¿Qué tipos de categorías
se han establecido y cuáles fueron los criterios emplea-
dos para organizar los datos en esas categorías?
Propiedad de los datos: ¿Se ha asignado la propiedad de
los datos a propietarios específicos? ¿Se han documen-
tado sus responsabilidades?
Retención de datos: ¿Se ha desarrollado una estrategia
para la retención de datos? Hasta las soluciones de
almacenamiento de gran tamaño pueden saturarse, por
ello, la organización tendrá que eliminar datos o
desplazarlos a otra solución de almacenamiento, como
su archivo. ¿Cuál es la política actual para su reten-
ción/archivo, y cómo afecta o da soporte a los obje-
tivos de la organización? ¿Si se debe realizar una
auditoría, los datos estarán disponibles, o se habrán
eliminado o archivado? ¿En caso de archivarse, se
pueden recuperar con facilidad?
Herramientas de archivo y retención: Si se ha definido
una estrategia de retención de datos, posiblemente
se requiera una herramienta para su implementación,
por ejemplo, software de archivos o medios de
archivo. Es probable que se deba auditar estas her-
ramientas para evaluar si son eficaces en realizar los
procedimientos requeridos.
Gestión de datos: ¿Cómo se gestionan los datos? ¿Cuáles
son las tareas diarias, semanales u otro que deben
realizarse para asegurar la integridad de los datos?
¿Quién las realiza y cuáles son los procedimientos?
A.5 Privacidad de datos
La privacidad de datos y los derechos de los consumidores
son temas muy visibles hoy en día. Se ha promulgado una
extensa serie de leyes sobre este tema que requieren su
cumplimiento. En algunos casos, los requerimientos varían
de forma significativa y pueden incluso contradecirse. Por
ejemplo, una gran organización que realice negocios en
Europa y Norteamérica estará sujeta a la Directiva europea
sobre protección de datos, a la Ley de Protección de la
Información Personal y Documentos Electrónicos del año
2000 de Canadá, así como a un buen número de reglamen-
tos estadounidenses a nivel estatal y probablemente algunas
normas del sector industrial, tales como la Ley de
Responsabilidad y Portabilidad del Seguro Médico de EE.
UU. de 1996 o la Ley Gramm-Leach-Bliley de 1999. Todas
ellas son distintas. Si la organización desea establecer un
sitio Web con juegos o contenidos a los que posiblemente
obtenga acceso un menor, entonces también será necesario
considerar las leyes sobre protección de datos de menores.
Riesgos de la privacidad
La falta de cumplimiento de ciertas leyes sobre la privacidad
24
de datos puede originar multas y/o demandas penales.
Además puede afectar la marca corporativa de manera
significativa. Consideremos el caso de un fabricante de
cereales que inserta juegos en la Web corporativa para
promover su producto, esto da lugar a que se registre
una cantidad de menores para jugar. Luego, un pirata
informático pone en peligro la lista de usuarios registrados
que contiene los datos personales de los menores. A
continuación de ese hecho, el diario Wall Street Journal
publica un artículo sobre la manera en que la empresa
permitió que se filtren los datos personales de los menores
en Internet. ¿Cómo afectaría esa situación a la organización?
Es difícil cuantificar su impacto, pero probablemente no
sea muy positivo para su cotización en bolsa.
Recomendaciones para la privacidad
Se debe realizar una auditoría sobre la privacidad, con-
siderando, como mínimo, los siguientes aspectos:
Las leyes sobre privacidad aplicables a la organización:
¿Se han identificado todas las leyes, reglamentaciones
y normas con las que debe cumplir la organización?
Responsabilidad sobre la privacidad: ¿Se ha designado
un responsable para este tema? ¿Cuáles son las
responsabilidades de esta función? ¿Cuál es el papel
del departamento de asesoría legal en los temas de
privacidad?
Políticas y procedimientos: ¿Se han establecido proced-
imientos para la creación, almacenamiento y gestión
de los datos del negocio? ¿Cómo se han implementado
y cómo se asegura su cumplimiento?
Tareas para el cumplimiento legal y normativo: ¿Qué
tareas específicas se realizan para el cumplimiento
legal y normativo? ¿Requiere la organización que se
cifren los datos, y si es así, qué métodos se emplean?
¿Se actualizan las metodologías de desarrollo de sitios
Web para incluir temas tales como las políticas de
inclusión voluntaria?
A.6 Separación de funciones
A medida que las organizaciones integran sus entornos en
aplicaciones de mayor tamaño y complejidad, la separación
de funciones es cada vez menos una función del puesto de
trabajo y, más, una función acerca de qué tipo de transac-
ciones puede realizar un usuario en el sistema. Como conse-
cuencia de ello, la adecuada separación de funciones
depende mayoritariamente del nivel de seguridad de la apli-
cación.
Al mismo tiempo, sin embargo, la seguridad a nivel de
aplicación se vuelve cada vez más compleja, y requiere may-
ores conocimientos para su administración correcta. Por lo
tanto, muchas organizaciones presentan deficiencias rela-
cionadas con la separación de funciones. Finalmente, la
complejidad de la seguridad en las aplicaciones crea mayores
dificultades para auditar tal separación de funciones de man-
era efectiva y eficiente.
 GTAG — Apéndice A — Temas emergentes
Los riesgos de la separación de funciones
La inadecuada separación de funciones expone a la organi-
zación al robo, fraude o uso no autorizado de los recursos de
información. Además, las deficiencias de ese tipo pueden
afectar negativamente al cumplimiento de la legislación
Sarbanes-Oxley. Algunas de las deficiencias importantes de
control interno informadas por empresas que cotizan en
bolsa, en el año 2004, se relacionaban con la separación de
funciones
Recomendaciones con respecto a la
separación de funciones
Se debe realizar una auditoría sobre la separación de fun-
ciones que incluya los siguientes aspectos:
Comprender la manera en que se controla y gestiona la seg-
regación de funciones: ¿Qué procesos, recursos humanos y
herramientas se emplean para dar respaldo a la gestión de
separación de funciones?
Definir los conflictos: ¿Se ha desarrollado una lista completa
de todas las funciones de la organización que se consideran
incompatibles? ¿Cómo se ha modificado esa lista para las
unidades que poseen una nómina más reducida? ¿Quién
intervino en el desarrollo de la lista? ¿Todas las partes clave
participaron para establecer y aprobar los casos de conflicto?
Determinar las deficiencias específicas: ¿Se ha empleado la
lista de casos de conflicto para identificar funciones especí-
ficas de seguridad, o personas que tengan un tipo de acce-
so que incumpla la separación de funciones? ¿Se emplea
una herramienta para facilitar este proceso, y de ser así,
cómo se ha configurado? ¿La herramienta puede procesar y
controlar los casos de conflicto en tiempo real?
Asignación de responsabilidades: ¿Se ha asignado la
responsabilidad de la gestión y control de la separación
de funciones a una persona o función específica? ¿En
caso de ser así, cuáles son las tareas que realiza y su
periodicidad? ¿Se han establecido políticas y proced-
imientos para guiar esta función?
Realización de un análisis cruzado entre aplicaciones:
¿Se han establecido herramientas, políticas y proced-
imientos para gestionar el análisis de la separación de
funciones a través de las aplicaciones? Por ejemplo, la
empresa XYZ emplea SAP para la contabilidad
financiera y PeopleSoft para recursos humanos. Existe
un usuario que tiene acceso a ambos sistemas, y ese
acceso combinado crea un conflicto en la segregación
de funciones. El análisis individual, tanto del sistema
SAP como de PeopleSoft, no detectaría ese conflicto,
que sólo se pondría de manifiesto al realizar un análisis
cruzado entre ambos sistemas.
A.7 Acceso administrador
El personal de administración de sistemas normalmente
cuenta con un nivel alto de acceso a los recursos de TI. Esto
25
se justifica ya que se presupone que son administradores que
requieren dicho acceso para realizar su función.
Riesgos asociados al acceso de administración de sistemas
Los usuarios con acceso a nivel de administración pueden
potencialmente realizar muchas funciones que superen sus
responsabilidades principales. Un usuario con acceso com-
pleto a la aplicación de negocio, por ejemplo, potencial-
mente puede crear una factura, recibir mercaderías y realizar
un pago. El mismo usuario administrador podría eliminar
todos los registros con pistas de auditoría. Un usuario con
acceso de administración a la base de datos, podría realizar
una malversación de fondos para una sesión completa de
pagos electrónicos.
A medida que las organizaciones continúan automati-
zando e integrando sus entornos de TI, aumentan los riesgos
relacionados con los registros e imputabilidad de adminis-
tración. Un administrador de sistemas con acceso ilimitado
a un sistema SAP completo posee mucho más poder que uno
con acceso ilimitado a un sistema de almacenamiento. La
falta de restricciones adecuadas en el acceso de adminis-
tración representa un riesgo significativo, y eso puede afectar
la opinión de los auditores externos para las empresas que
cotizan en bolsa en EE. UU. en cuanto a su cumplimiento
con la Sección 404 de la Ley Sarbanes-Oxley. Para las
empresas que externalizan alguna parte o todo su entorno de
TI, el riesgo podría ser todavía mayor por dos motivos:
• En muchos casos, el proveedor externo podría dar ser-
vicio a múltiples organizaciones empleando un equipo
numeroso de personas. Normalmente esto significa
que en lugar de que haya un equipo de cinco admin-
istradores que dan soporte a una organización determi-
nada, el equipo constará de 25 administradores que
colectivamente lo hacen para cinco organizaciones.
En ese caso, los 25 administradores probablemente
tengan un nivel importante de acceso.
• A pesar de las cláusulas del contrato, siempre existirá
un riesgo mayor cuando alguien que no sea empleado
de la organización cuente con un acceso de admin-
istrador a los sistemas.
Recomendaciones con respecto al acceso de
administración de sistemas
Cada entorno requiere el acceso de administración para ges-
tionar los sistemas. No obstante, la función de auditoría de
TI debe asegurarse de que los administradores de sistemas
sólo tengan acceso a los datos y funciones que sean necesar-
ios para realizar sus responsabilidades de trabajo. Hay que
señalar que dicho acceso no debe incluir transacciones fun-
cionales. Los administradores de sistemas nunca deben con-
tabilizar operaciones, realizar pagos o mantener el registro
maestro de un proveedor, y como tal, no deben tener acceso
para realizar dichas transacciones. Otro argumento típico es
GTAG — Apéndice A — Temas emergentes
que los administradores de sistemas necesitan acceso
funcional para resolver problemas. Sin embargo, la mayor
parte de la resolución de problemas y pruebas debe realizarse
dentro de un entorno de pruebas y no en el de producción.
Si el entorno no constituye una imagen adecuada del
entorno de producción, esto significa que existe un defecto
en el proceso de desarrollo de los sistemas, y no que se
necesita mayor acceso a producción.
El auditor de TI también debe considerar:
División del acceso: Dividir el acceso para realizar una
función de tal forma que se requiera la intervención de
dos personas para su ejecución.
Identificaciones genéricas: En algunos casos un equipo
de administración podría compartir una identificación
de administración. El auditor de TI que revisa
el informe de accesos sólo detectaría un único usuario,
cuando en realidad varios usuarios hacen uso de
esa identificación. Esto aumenta el riesgo porque pone
en peligro la pista de auditoría
El número de personas con acceso de administración: El
acceso a las funciones administrativas se debe limitar
solamente a un número reducido de administradores.
No todas las personas del departamento de TI necesi-
tan accesos de administrador .
Gestión de las pistas de auditoría: Dado que los usuarios
de administración tienen un nivel alto de acceso
a los sistemas, uno de los únicos controles disponibles
que puede mitigar el riesgo es la revisión periódica e
independiente de las pistas de auditoría. Dicha
revisión, puede ser realizada por el personal de
auditoría de TI o por otros recursos independientes
(como un director de TI que cumpla otra
función de TI). Cuando sea posible, será primordial
asegurar que el personal de administración de
sistemas no pueda eliminar la información de las pistas
de auditoría. Este paso, normalmente, se puede
realizar a través de la seguridad o de la configuración
del sistema.
Empleo de identificaciones de emergencia: Este tipo
de identificaciones y contraseñas puede también
ayudar a mitigar el riesgo asociado a la concesión
de accesos de administración. Una identificación
de emergencia es una cuenta establecida con
un nivel de acceso de administrador. La cuenta se
encuentra bloqueada y su contraseña es conocida sólo
por una persona independiente dentro de la
organización. Cuando surge una situación de emergen-
cia, el personal de soporte de TI recupera la
contraseña para la identificación de emergencia, y reg-
istra esa recuperación. La persona de soporte
emplea la ID para realizar las tareas necesarias y
luego la devuelve a la persona independiente que pro-
cede a bloquear la cuenta. Existen algunas
herramientas nuevas en el mercado para realizar
este proceso automáticamente.
26
A.8 Controles configurables
Como se ha mencionado en la introducción de esta GTAG,
muchos de los controles clave de hoy en día están basados en
la tecnología o se configuran dentro de las aplicaciones de
negocio. Cuando se considera el ejemplo de la triple compro-
bación descrita en la introducción, se observa que la fun-
cionalidad de este proceso se controla a través de
determinados parámetros configurables dentro de la apli-
cación (como niveles de tolerancia, tipo de comprobación
por importe o valor, acciones a tomar para las transacciones
que no cuadran, cuentas donde se contabilizan las diferen-
cias, etc.).
En muchos casos, se trata de controles configurables que
gestionan y controlan en primer lugar el tratamiento de las
transacciones a través de un proceso determinado. Sin
embargo, a menudo se ignoran dichos controles en las audi-
torías de proceso.
Los riesgos asociados a los controles de configuración
Si no se tienen en cuenta los controles configurables de la
aplicación al realizar una auditoría de proceso, los proced-
imientos de auditoría podrían no ser efectivos y las conclu-
siones de auditoría, incorrectas. Además, muchas veces será
más rápido revisar un parámetro configurado en línea, que
obtener y revisar una muestra de 60 transacciones. Por lo
tanto, los procedimientos de auditoría pueden ser inefi-
cientes cuando no se consideran los controles configurables.
Recomendaciones con respecto a los controles configurables
La evaluación de los controles configurables no se debe
realizar solamente en una auditoría de TI, sino que todas las
auditorías de procesos deben analizar los parámetros que
controlan el proceso en cuestión, como parte de la auditoría
global. Esto puede presentar un reto con respecto a la coor-
dinación porque los auditores de TI probablemente deban
trabajar estrechamente con los auditores de proceso para
determinar cuáles son los parámetros importantes y llevar a
cabo los procedimientos técnicos requeridos.
El DEA debe revisar el plan de auditoría para todas las
auditorías de procesos planificadas. Si la planificación no
incluye ninguna prueba de los controles configurables, debe
cuestionarla para determinar por qué esos controles no se
revisan. El hecho de que no se revisen no significa necesari-
amente que sea una debilidad puesto que puede haber una
serie de motivos válidos por los cuales se haya determinado
que los controles configurables no son relevantes para esa
auditoría en cuestión.
Si los controles configurables son relevantes para esa
auditoría de proceso en particular, es importante considerar
la manera en que se realizarán las pruebas sobre dichos con-
troles. El proceso de entrar dentro de una tabla de configura-
ciones y la evaluación de los parámetros requiere habilidades
totalmente distintas a las que se necesitan para revisar una
muestra de 60 transacciones. Los DEA efectivos serán
capaces de diseñar un plan de auditoría que utilice los
 GTAG — Apéndice A — Temas emergentes
conocimientos adecuados en los sitios apropiados. Para las
auditorías de procesos, esto puede significar la coordinación
de los procedimientos de auditoría entre múltiples auditores
dentro de una misma auditoría. Este tipo de coordinación
puede dar lugar a ciertos retos de logística, pero dará lugar a
una auditoría de mejor calidad.
A.9 Piratería
Las actividades relacionadas con la piratería informática
prevalecen hoy más que nunca. A medida que las organiza-
ciones automatizan sus negocios, aumenta el número de
activos que se convierte en formato digital. La gestión de
estos activos digitales podría representar un factor más
importante para el éxito de la empresa que la protección de
los activos físicos. Internet ha dado lugar a una red de dis-
tribución global que permite la distribución de activos digi-
tales piratas de forma rápida y anónima.
Los riesgos asociados a la piratería
A medida que el valor de los activos digitales aumenta, tam-
bién lo hace el riesgo asociado a la piratería. Algunas organi-
zaciones y sectores ven esto como uno de los mayores riesgos
a que se enfrentan hoy en día. Evidentemente, las recientes-
batallas entre la industria discográfica y los diversos sitios
Web para el intercambio de música (como Napster) repre-
sentan sólo un ejemplo de esto.
El impacto financiero directo es difícil de cuantificar,
aunque muchas organizaciones estiman que la piratería tiene
un impacto en los resultados finales de decenas o cientos de
millones de dólares.
Recomendaciones con respecto a la piratería
Se debe realizar una auditoría sobre la gestión de activos dig-
itales que incluya los siguientes aspectos:
Inventario de todos los activos digitales que mantiene la
organización: ¿Dispone la organización de una lista
actualizada de sus activos digitales y de sus respectivas
ubicaciones físicas y lógicas?
Clasificación: ¿Se ha realizado un ejercicio de clasifi-
cación de los activos digitales, y de ser así, cuáles
fueron los criterios empleados, y los estratos definidos?
Almacenamiento: ¿Dónde se almacenan los activos digi-
tales y de qué manera? ¿Se mantienen copias de respal-
do adecuadas? ¿Si las copias de respaldo se almacenan
en un lugar distinto, cómo se protegen y controlan?
Cifrado de datos: ¿Los activos digitales están sujetos a
tecnologías de cifrado, y si es así, cuáles son las tec-
nologías empleadas? ¿Tienen sentido los métodos de
cifrado para el tipo de activo en cuestión?
Acceso de administración y de terceros: ¿Si se protegen
los activos digitales, qué otro personal tiene acceso a
ellos? Por ejemplo, la empresa XYZ está realizando su
última película de éxito para el verano. Ha gastado
USD200 M en el desarrollo y la publicidad. La pelícu-
27
la se almacena dentro de unos grandes servidores de
montaje, como lo haría cualquier empresa prudente.
Se hace una copia de respaldo que se almacena en un
lugar distinto, pero una de las personas en la cadena de
almacenamiento (por ejemplo, el conductor o el super-
visor de almacenamiento) hace un duplicado de la
copia de respaldo y coloca la película sin terminar en
Internet varias semanas antes de su estreno, esto da
como resultado ingresos de taquilla mucho menores
que los previstos para la película en cuestión.
Desafortunadamente, este desastre ha sido el resultado
del deseo inicial de mantener buenos controles de TI
(por ejemplo, copias de respaldo). Esta paradoja obliga
al auditor de TI a considerar nuevas formas de prote-
ger y controlar la información.
Transporte y transmisión: Los mismos temas aplicables
anteriormente también se pueden aplicar al transporte y
transmisión de los activos digitales. Está claro que
cualquier archivo digital sin cifrar enviado por correo
electrónico quedará expuesto y potencialmente podrá
ser explotado. ¿Se han desarrollado procedimientos sóli-
dos para el transporte y transmisión de los activos digi-
tales?
Otros recursos
Organizaciones profesionales
• Asociación de Auditoría y Control de Sistemas de
Información (ISACA, en inglés) www.isaca.org
– Ofrece las certificaciones de Auditor Certificado
de Sistemas de Información (CISA, en inglés) y de
Administrador Certificado de Seguridad de la
Información (CISM, en inglés).
• Instituto de Auditores Internos (IIA, en inglés) –
www.theiia.org
– Ofrece la certificación de Auditor Interno
Certificado (CIA, en inglés).
– Ofrece la publicación “IT Audit”, un boletín infor
mativo gratuito que incorpora una biblioteca de
consulta.
• Asociación de Seguridad de Sistemas de Información
(ISSA, en inglés)
– Apoya a los profesionales certificados en la seguri
dad de sistemas de información.
– La ISC2 administra el proceso de certificación,
aunque no es una organización profesional en sí
misma.
• Instituto Estadounidense de Contadores Públicos
Certificados (AICPA, en inglés) www.aicpa.org
– Patrocina la certificación estadounidense de audi
tor de cuentas. Contador Público Certificado
(CPA, en inglés).
Sitios Web útiles
• http://www.csoonline.com
– Ofrece recursos útiles tales como artículos sobre
GTAG — Apéndice A — Temas emergentes
seguridad para responsables de la seguridad.
• http://www.whatis.com
– Un sitio excelente para obtener definiciones sobre
tecnologías de forma rápida y enlaces a otros sitios
de TI.
• http://csrc.nist.gov
– Centro de Investigación sobre seguridad infor
mática patrocinado por el Instituto Nacional de
Normas y Tecnologías de EE. UU. (NIST, en
inglés).
• http://www.cyberpartnership.org
– Sociedad Nacional de Seguridad Cibernética
(NCSP), es una asociación con participación pública
y privada establecida para el desarrollo de estrategias
y programas compartidos para mejorar la seguridad y
la infraestructura de los temas de información en los
Estados Unidos.
• http://www.infosecuritymag.com/
– Publicación sobre la seguridad de sistemas de infor-
mación que trata los temas actuales de seguridad.
• http://www.itgi.org
– ITGI tiene el objetivo de ayudar a los directivos
corporativos en su responsabilidad de lograr que la TI
respalde con éxito la misión y los objetivos de la
empresa.

Grupos de usuarios y software

• Herramientas gratuitas
– Business Software Alliance promueve un mundo
digital seguro y legal–
http://www.bsa.org/usa/antipiracy/Free-Software-
Audit-Tools.cfm
– AuditNet® es una red de recursos disponibles para
los auditores
http://www.auditnet.org
• Grupos de usuarios de SAP de América
– Grupo independiente de usuarios de Oracle –
www.asug.com
– Grupo de usuarios Quest Internacional para aplica
ciones de PeopleSoft/JD dwards – www.ioug.org
– Grupo de usuarios de servidores SQL a nivel
mundial – http://www.questdirect.org
– SQL Server Worldwide Users Group –
http://www.sswug.org
– Directorio de Yahoo de los grupos de usuarios –
http://dir.yahoo.com/Computers_and_Internet/
Organizations/User_Groups

28
GTAG — Notas sobre los autores de esta guía
Michael Juergens, autor principal de esta guía, posee
más de quince años de experiencia profesional y ha trabaja-
do en la empresa Deloitte desde 1996. Actualmente lidera el
grupo de prácticas para la práctica de aseguramiento y con-
trol de Deloitte para la región estadounidense del “Pacífico-
suroeste”. Se especializa en la evaluación de los controles de
la tecnología de la información. Sus conferencias sobre con-
troles internos han sido reconocidas a nivel nacional en EE.
UU. y ha dado conferencias a muchas audiencias, incluidas
las de asociaciones como el IIA, la ISACA, el Grupo de
usuarios de SAP de América, MIS Training Institute,
además de las que han asistido a sus numerosas conferencias
a nivel nacional e internacional. Participa en el comité de
conferencias profesionales del IIA y supervisa todos los cur-
sos de formación ofrecidos por el IIA. En la actualidad,
Michael Juergens actúa como una figura rectora en controles
internos para varias multinacionales. En ese sentido, ha
supervisado la entrega de numerosos proyectos de control
interno y cumplimiento de la Ley Sarbanes-Oxley, así como
auditorías de verificación contable. Juergens posee el título
de Licenciado en Ciencias Económicas y una Maestría en
Administración de Empresas, ambos otorgados por la
Universidad de California, Irvine.
David Maberry, autor colaborador, es Gerente Superior
de la práctica de Aseguramiento de controles de los servicios
de riesgo empresarial y auditoría de Deloitte en Los Ángeles.
Posee amplia experiencia en el control de riesgos, en fun-
ciones de cumplimento y en auditoría interna; se ha espe-
cializado en las evaluaciones de cumplimiento de la Ley
Sarbanes-Oxley, análisis de riesgos de TI y revisiones de la
pre y posimplementación de una serie de sistemas y platafor-
mas. Su considerable experiencia en operaciones le propor-
ciona una habilidad especial para analizar los procesos de
prácticamente cualquier entorno, a la vez que proporciona el
máximo beneficio. Antes de incorporarse a Deloitte, ejerció
altos cargos en el sector sanitario durante más de once años.
Actualmente da apoyo a numerosas empresas Fortune 500 en
sus estrategias sobre el cumplimiento de los requerimientos
de auditoría y la evaluación del negocio.
Jeff Fisher, colaborador editorial, es Gerente Superior
de la práctica de Servicios de riesgo empresarial y auditoría
de Deloitte & Touche. Ha trabajado en dicha firma durante
más de ocho años, actúa como gerente de proyectos y desem-
peña el rol de aseguramiento de calidad técnica para algunos
de los clientes más grandes de Deloitte. Se especializa en las
auditorías y evaluaciones de la seguridad de los sistemas de
información, gestión de proyectos y evaluación de la Sección
404 de la Ley Sarbanes-Oxley. Ha ayudado a muchos de los
clientes de Deloitte en la preparación de una correcta imple-
mentación de los procesos de evaluación de esa legislación a
nivel mundial. Fisher posee el título de Licenciado en
Contabilidad y Sistemas de Información, otorgado por la
Universidad de Ferris. Cuenta además con la certificación de
29
Profesional Certificado de Seguridad de Sistemas de
Información (CISSP, en inglés) y de Auditor Certificado de
Sistemas de Información (CISA, en inglés).
Eric Ringle, Su especialidad es la auditoría y evaluación
de sistemas de información y procesos de negocio, gestión de
proyectos y evaluación de la Sección 404 de la Ley Sarbanes-
Oxley. Ha asistido a muchos de los clientes de Deloitte en su
preparación para la correcta implementación de los procesos
de evaluación de dicha legislación. Ringle posee el título de
Licenciado y la Maestría en Contabilidad de la Universidad
del Estado de Michigan. Es Contador Público Certificado
(CPA, en inglés), Profesional Certificado de TI (CITP, en
inglés) y Auditor Certificado de Sistemas de Información
(CISA, en inglés).
Revisión
Las siguientes instituciones participaron en el proceso de
revisión de este material: Comisión de Tecnología de
Avanzada del IIA, afiliados internacionales del instituto,
Instituto Estadounidense de Contadores Públicos
Certificados, Centro de Seguridad de Internet, Instituto de
Ingeniería de Software de la Universidad Carnegie-Mellon,
Asociación de Seguridad de Sistemas de información,
Instituto de Procesos de TI, Asociación Nacional de
Directores Corporativos e Instituto SANS. Las siguientes
personas y organizaciones han proporcionado sus valiosos
comentarios con respecto a esta guía:
– Instituto Estadounidense de Contadores Públicos
Certificados
– Instituto de Auditores Internos de Australia
– Instituto de Auditores Internos del Reino
Unido
– Christopher Fox, PricewaterhouseCoopers, EE, UU.
– David Bentley, Consultor, Reino Unido
– E.W. Sean Ballington, PricewaterhouseCoopers, EE.
UU.
– Jay R Taylor, General Motors Corp., EE. UU.
– Larry Brown, The Options Clearing Corporation, EE.
UU.
– Lars Erik Fjortoft, Deloitte, Noruega
– Lily Bi, Instituto de Auditores Internos
– Stig J. Sunde, Oficina del Auditor General,
Noruega
Gestión de la auditoría de tecnología de la información
La tecnología de la información (TI) está modificando la naturaleza de la función de la auditoría interna.
A medida que surgen nuevos riesgos, se requieren nuevos procedimientos para gestionarlos adecuademente.
Esta guía ha sido creada para asistir a los directores ejecutivos de auditoría (DEA) en la planificación y
gestión de la función de auditoría con mayor eficacia y eficienca. Contempla además las cuestiones funda-
mentales de las auditorías de TI y los temas emergentes.

¿Qué es la GTAG?
Las Guías de Auditoría de Tecnología Global (GTAG) preparadas por el IIA están escritas en un lenguaje
directo de negocio para abordar en forma oportuna problemas relacionados con la gestión, el control y la
seguridad de la tecnología de la información. La colección GTAG se utiliza como un recurso disponible,
para los directores ejecutivos de auditoría, sobre los distintos riesgos asociados a la tecnología y las prácticas
recomendadas. Se publicaron las siguientes guías en 2005.
Guía 1: Controles de tecnología de la información
Guía 2: Controles de gestión de parches y cambios: críticos para el éxito de la organización
Guía 3: Auditoría continua: implicancias para el aseguramiento, la supervisión y la evaluación de riesgos
Guía 4: Gestión de la auditoría de TI
Guía 5: Gestión y auditoría de riesgos de privacidad
Consulte la sección de tecnología del sitio Web del IIA en www.theiia.org/technology

www.theiia.org