Curso auditoría bancaria

Curso de auditoría empresarial y bancaria
Nuevos paradigmas – Presente y Futuro

El proceso de Auditoría
En este capítulo discutiremos las etapas básicas del proceso de auditoría, como
conducirlas de manera efectiva y lo siguiente:
1. Los distintos tipos de controles internos.
2. Como debería elegir los puntos a auditar.
3. Como conducir las fases iniciales de una auditoría.
a) Planificación
b) Trabajo de campo y documentación
c) Descubrimiento de puntos a observar y su validación.
d) Desarrollo en la solución
e) Elaboración del borrador de informe y su remisión.
4. Seguimiento a observaciones.
Controles Internos
Antes de embarcarnos en la discusión del proceso de auditoría,
necesitamos comprender uno de los conceptos básicos de la auditoría:
Los controles internos.
El concepto de controles internos es absolutamente fundamental en la
profesión de auditoría.
Hemos visto que la verdadera misión del departamento de auditoría
interna es colaborar en mejorar el estado de los controles internos en
la compañía. ¿Pero qué controles internos?
Si no sabe cómo responder esta pregunta, le será difícil cumplir con la
misión del departamento.
Controles Internos
Los controles internos, en términos sencillos, son mecanismos que
aseguran el funcionamiento apropiado de los procesos dentro de la
compañía.
Cada sistema y proceso dentro de la compañía existe por algún
propósito particular del negocio.
El auditor debe buscar la existencia de riesgos en esos procesos y
sistemas y asegurarse que los controles internos están definidos para
mitigarlos.
1. Tipos de controles internos

Los controles pueden ser:
a) preventivos, b) detectivos o c) reactivos, y ellos pueden tener
implementaciones administrativas, técnicas y físicas.
Ejemplos de implementaciones administrativas incluyen cuestiones
como políticas y procedimientos.
Implementaciones técnicas son las herramientas y software que
refuerzan lógicamente los controles (como passwords).
Implementaciones físicas incluyen controles como personal de
seguridad, puertas llaveadas, etc.
a) Controles preventivos
Estos controles detienen la ocurrencia de un evento negativo.
Por ejemplo, requerirle a un usuario su identificación y password para
acceder a un sistema es un control preventivo.
Previene (en teoría) que personas no autorizadas accedan al sistema.
Desde un punto de vista teórico, los controles preventivos son siempre
preferidos, por obvias razones.
Sin embargo, cuando está realizando auditorías, recuerde que los
controles preventivos no son siempre la mejor opción costo-efectiva, y
otros tipos de controles pueden tener más sentido desde un punto de
vista costo/beneficio.
b) Controles detectivos
Estos controles registran un evento fallido una vez ocurrido.
Por ejemplo, registrar en pistas de auditoría (logs) todas las actividades
realizadas en un sistema le permitirá revisarlos para buscar actividades
inapropiadas luego de ocurrido el evento.
c) Controles reactivos (controles correctivos)

Estos controles pueden ser clasificados entre los preventivos y los
detectivos.
Estos no previenen la ocurrencia de eventos adversos, pero proveen un
modo sistemático para detectar cuando estos ocurren y corregir la
situación, y es esto por lo que a veces son llamados controles
correctivos.
Por ejemplo, podría tener un sistema centralizado de antivirus que

detecta si cada PC de sus usuarios cuenta con la última actualización de
las firmas instalada.
Idealmente, uno podría inhabilitar el acceso a la red a cualquier
máquina que no esté en cumplimiento de este requerimiento.
Sin embargo, esto puede que no sea práctico desde el punto de vista
del negocio.
Por consiguiente, una alternativa podría ser realizar un seguimiento de
tareas tendientes a regularizar en la situación de dicho equipo y
remover su posibilidad de conectarse a la red corporativa.
Ejemplos de controles internos.

Digamos que está revisando el sistema contable de su compañía. Dicho
sistema registra, entre otras cosas, quienes le deben a su compañía y le
permite hacer un seguimiento de modo a requerirles cuando
corresponda. Los auditores financieros se preocuparan de riesgos
inherentes a este proceso, mientras que los auditores de TI necesitan
pensar en los riesgos del sistema de aplicación para cumplir con su
propósito corporativo.
A continuación citamos unos pocos ejemplos rudimentarios que
intentan ilustrar el concepto de controles internos. El auditor necesita
comprender cuál es el propósito, de lo que va a auditar, para la
compañía, pensar en los riesgos inherentes y luego identificar cualquier
control interno para mitigar esos riesgos.
• Control de cambios de programas de aplicación

Si la introducción de cambios en la codificación de programas no está
aprobada y probada adecuadamente, podría encontrarse con que la
lógica que se ejecuta en la aplicación es errónea. Esto podría significar
que no debería confiar en la integridad de los datos almacenados en el
sistema, lo que resulta en una incapacidad para determinar con certeza
de quien le ha pagado a su empresa y quién no. Entonces, ¿cuáles
pueden ser los controles internos que podrían mitigar este riesgo?
o No permita a los programadores el acceso al entorno de producción para
modificar código fuente.
o Los que tengan acceso lógico para actualizar el código de producción, no
deberían hacerlo sin evidencia de haberse realizado las pruebas y contar con
las aprobaciones correspondientes.
• Controles de acceso
Si se provee acceso al sistema a gente que no lo necesita, los datos del
sistema podrían ser cambiados, agregados o borrados
inapropiadamente. ¿Cuáles pueden ser los controles internos que
podrían mitigar este riesgo?
o Requiera un usuario y password para el acceso a los sistemas.
o Cuente con un número limitado de administradores de seguridad para
controlar la posibilidad de agregar nuevas cuentas de usuarios al sistema.
o Asegúrese que los administradores de seguridad son personas reconocidas
que conocen los perfiles que pueden tener los usuarios para acceder a los
distintos niveles de la aplicación o que la compañía cuenta con esquemas
formales de autorización de acceso por parte de los responsables de las
distintas áreas operativas de la compañía.
• Copias de respaldo y planes de recuperación de desastres

Si el sistema o sus datos se pierden, la funcionalidad del sistema no
estaría disponible, resultando en la pérdida de su habilidad de recibir
pagos o realizarlos.
¿Cuáles pueden ser los controles internos que podrían mitigar este
riesgo?
oRealice copias de seguridad del sistema y los datos de forma
periódica.
oTraslade y resguarde las copias de seguridad fuera del datacenter
oDocumente un plan de recuperación de desastres.
2. Como determinar los puntos a auditar

Una de las tareas más importantes del departamento de auditoría
interna es determinar lo que se va a auditar.
En esta sección nos enfocaremos en las auditorías tradicionales y
formales, en las que se tienen equipos de auditores trabajando en
producir papeles de trabajo, reportes de auditoría, listas de
observaciones y planes de acción para resolver esas observaciones.
Su plan de auditoría debe enfocar a sus auditores en áreas con mayor

riesgo y en áreas donde pude agregar el mayor valor a la compañía.
Debe ser eficiente y efectivo en la manera que utiliza sus recursos
limitados, asignando las horas de auditoría de TI a áreas de mayor
importancia.
Esto no debería hacerse asignándose prioridades de manera arbitraria,
por el contrario debería ser un proceso lógico y metodológico que
asegure que todas las auditorías potenciales han sido consideradas.
• Creación del universo auditable

Uno de los primeros pasos para asegurar un proceso de planificación
efectiva es crear su universo de TI auditable.
Debe ser consciente de las potenciales auditorías que podría realizar
antes de establecer un ranking.
Puede segmentar el universo de TI de muchas formas, y ninguna es
particularmente correcta o equivocada.
Lo importante es idear una forma de segmentar las áreas de modo que
pueda realizar las auditorías más efectivas.

Funciones centralizadas de TI
Primero, determine que funciones de TI están centralizadas y coloque cada
una de esas funciones en su lista de potenciales puntos auditables.
Por ejemplo, si una función central administra sus entornos Unix y Linux, uno
de sus puntos potenciales de revisión debe ser la administración de esos
entornos.
Esto podría incluir procesos administrativos como administración de cuentas
de acceso, administración de cambios, administración de incidentes,
administración de parches de seguridad, monitoreo de seguridad y otros
procesos similares que podrían aplicar al ambiente en su conjunto.

Otro ejemplo podría incluir una revisión de los aspectos básicos de la
seguridad utilizada en el proceso centralizado de instalación y puesta
en producción de servidores Unix y Linux.
Luego, si los planes de los auditores financieros requieren una auditoría
de una aplicación financiera en particular que reside en un servidor
Unix, su participación en dicha auditoría podría consistir solo en la
auditoría de la seguridad de ese servidor específico sin tener que gastar
tiempo comprendiendo los procesos de administración de ese servidor
(lo que ya ha podido ser cubierto en la auditoría centralizada).

Por supuesto, cada compañía centralizará este tipo de funciones
principales de TI de distintas formas.
Uno debe comprender lo suficientemente bien el entorno para
determinar cuáles funciones están centralizadas y agregar dichas
funciones a su universo auditable.
Auditorías de ese tipo de funciones forman una plataforma que
acelerará el resto de sus auditorías.
A medida que realiza otras auditorías, puede ir removiendo las
funciones centralizadas que ya han sido auditadas del ámbito
auditable.

Por ejemplo, suponga que realiza auditorías del entorno de TI en cada
sitio, pero la configuración de red y el soporte están centralizados.
Sería altamente ineficiente hablar al grupo de redes acerca de sus
procesos durante cada auditoría de sitios.
Se debería realizar una auditoría cubriendo sus procesos y luego
eliminar esa auditoría del mapa de auditorías de los sitios.

Funciones de TI descentralizadas.
Luego de crear un listado de los procesos de TI centralizados de la
compañía, puede determinar el resto del universo auditable.
Quizás pueda crear una auditoria potencial por cada sitio de la
compañía.
Estas auditorías podrían consistir en la revisión de controles de TI
descentralizados que son realizados en cada sitio, como la seguridad
física del datacenter y controles ambientales.

Soportes a servidores y computadoras personales también pueden ser
descentralizados en la compañía.
La clave podría ser entender que controles de TI son realizados en el
sitio de la compañía y revisarlos.
Puede que sea necesario ser más granular en este análisis y tener más
puntos de auditoría potenciales en cada sitio.
Todo de pende de la complejidad del entorno, la estructura jerárquica
de la compañía y los niveles de personal con que disponga.
Tendrá que determinar lo que sea más efectivo en su entorno.
• Aplicaciones de negocio
Podría incluso determinar que cada aplicación de negocio sea un objeto
auditable. Necesitará determinar si es más efectivo conducir esas auditorías
en el universo auditable de TI o en el universo auditable financiero. En
muchos aspectos, es más sensato que estas auditorías sean conducidas por
los auditores financieros, quienes estén probablemente en mejor posición de
determinar cuándo es el momento adecuado de realizar una auditoría de
determinados procesos de negocio.
Si ellos toman la decisión, ellos pueden solicitarle determinar los aspectos
relevantes del sistema que deberían ser incluidos en el requerimiento de
auditoría (como una revisión del servidor en donde reside la aplicación, los
controles de cambio del sistema, el plan de recuperación de desastres del
sistema, y así sucesivamente).
• Cumplimiento regulatorio
Dependiendo de los servicios o bienes que su negocio proporcione,
puede que sea responsable de asegurar el cumplimiento de ciertas
normativas.
Ejemplos comunes incluyen la auditoría de cumplimiento con
Sarbanes-Oxley, Health Insurance Portability and Accountability Act
(HIPPA), y regulaciones y estándares de la Industria de Medios de Pago
o Payment Card Industry (PCI).
Puede que tenga una auditoría separada en el universo auditable para
verificar el cumplimiento con cada regulación relevante.
Nota: una buena fuente para asegurase que ha

considerado todas las áreas significativas del gobierno
de TI es remitirse como referencia al Control Objectives
for Information and Related Technology (COBIT), el cual
define los objetivos de control de alto nivel para TI.
Aunque su planificación siempre debería ser diseñada

a la medida del entorno de su compañía, COBIT puede
ser una buena referencia para crear su universo
auditable.
• Elaboración de un ranking del universo auditable

Una vez creado el universo auditable de TI, debe desarrollar una
metodología para clasificar las potenciales auditorías para determinar
su plan para el año, trimestre, cuatrimestre, mes, etc. Uno puede
incluir todo tipo de factores en esta metodología, pero las siguientes
son algunas de las esenciales:
oProblemas conocidos en el área: Si conoce de problemas existentes
en el área, debería considerar la realización de una auditoría de esa
área.

oRiesgos inherentes en el área: Puede que no esté al tanto de
problemas específicos en el área, pero su experiencia le indica que
esa área es proclive a problemas, de modo que debería considerar la
realización de una auditoría. Por ejemplo, quizás Ud. encuentra
consistentemente problemas significativos cuando audita controles
de TI a nivel del sitio que dan soporte a una actividad manufacturera
en particular. Esta experiencia debería indicar un riesgo inherente
mayor en esa área, indicándole que debe realizar auditorías similares
en otros sitios, aún si no está al tanto de algún problema específico
en esos sitios.

oBeneficios de realizar auditoría en el área: Considere los beneficios
de realizar una auditoría en el área, enfocándose particularmente en
si una auditoría agregaría valor a la compañía.
oPor ejemplo podría conocer de problemas existentes, pero de los que
la administración ya está al tanto y los está atendiendo.
oEn este caso, el que le informe a la administración acerca de todos los
problemas sobre los que ya está en proceso de solución, no agrega
valor a la compañía. En vez de auditarlos, considere la posibilidad de
servir como parte del equipo que está desarrollando soluciones para
reparar el problema.

oBeneficios de realizar auditoría en el área: También debería
considerar la importancia de un área de la compañía.
Por ejemplo, puede que sepa que existen problemas con el sistema
utilizado para ordenar alimentos para una reunión interna.
Su modelo de ranking necesita considerar el hecho que este sistema no
es realmente muy importante para el éxito de la compañía.

oIndicaciones de la Gerencia: En el capítulo anterior hemos señalado
la importancia de desarrollar y mantener buenos relacionamientos
con la administración de TI.
oCuando esos relacionamientos son saludables, las recomendaciones
de la administración de TI debería ser un factor preponderante en sus
decisiones relacionadas con el universo auditable. Si el CIO y o
miembros clave del equipo de líderes de TI están preocupados sobre
un área y desean que se lo audite, luego esa señal debería pesar
mucho en su proceso de decisión. De hecho, si esos relacionamientos
son saludables, y Ud. está haciendo un buen trabajo en mantener
contacto durante el año, su plan de auditoría, prácticamente, debería
crearse solo.

oIndicaciones de la Gerencia: Se enterará de los cambios importantes en el
entorno y de preocupación significativa, de modo que su proceso de
planificación puede ser una confirmación de las discusiones que han
estado manteniendo a través del año. Note que este factor puede influir
otros también. Por ejemplo, si la administración le está alentando a realizar
una auditoría, probablemente ellos conozcan de problemas en el área, lo
cual podría llevarlo a incrementar su calificación del primer factor a
considerar en su calendario (problemas conocidos en el sector). También
podría llevarlo a creer que Ud. puede agregar valor realizando la auditoría,
de modo que puede incrementar potencialmente su calificación del tercer
factor (beneficios de realizar una auditoría en el área). Otros factores
pueden ser incluidos en un modelo de calificación, pero los cuatro
precedentes son absolutamente esenciales.

oIndicaciones de la Gerencia: Como ejemplo de como el modelo de
ranking funcionaría, puede que Ud. decida clasificar cada factor de 1 a
10. Si el CIO y todo el equipo que lidera le alienta a realizar una
auditoría, el input del administrador de TI puede obtener un 10.
oSin embargo, si no ve mucho riesgo inherente en esa área, podría dar
a ese factor una calificación de 5. Y esto sigue así hasta que haya
asignado un valor a cada factor por cada auditoría potencial y su
universo auditable.

• Indicaciones de la Gerencia: Uno puede incluso decidir que los
problemas conocidos deben tener mayor peso y por tanto asignarle
doble valor a dicho factor. La clave es tener su universo de auditable
potencial definido y luego crear algún proceso que le ayude a definir
un ranking de la importancia relativa de realizar cada una de las
auditorías potenciales.
Algunas compañías enfatizan la rotación de las auditorías, donde cada
auditoría es realizada en un determinado calendario. Esto puede ser un
modo válido de asegurar que todos los sistemas críticos y sitios son
auditados regularmente; sin embargo, el esquema de rotación debería
ser una guía y no una regla firme.

• Indicaciones de la Gerencia: Un esquema de rotación no debería ser
una excusa para ignorar problemas conocidos y el input de gerente de
TI. Es crítico que se reserve el derecho de ignorar el esquema de
rotación para asegurar que está enfocando las áreas donde puede
agregar el mayor valor a la compañía. Si el esquema de rotación es la
forma primaria en la que agenda sus revisiones, debería considerar
incluir el esquema de rotación en su modelo de ranking de auditoría.
Por supuesto, puede que se lo requiera realizar algunas auditorias
anualmente por requerimientos regulatorios (como cumplimiento a la
ley Sarbanes-Oxley). Dichas auditorías, obviamente, no necesitan
tener un ranking.
• Determinar que auditar: discusiones finales
Una vez que ha elaborado su ranking, necesitará estimar los recursos
necesarios para cada auditoría potencial para determinar el universo de su
plan de auditoría (ya que debería saber cuáles son los recursos disponibles).
Esto también le permitirá exponer a los administradores cuales auditorías no
tendrá tiempo para realizarlas, lo que podría conducir a discusiones
saludables a cerca del nivel apropiado de auditores o de la necesidad de
solicitar una tercerización.
En resumen, antes que se sienta cómodo porque está auditando las cosas
correctas, primero debe determinar el universo de las auditorías potenciales
y luego desarrollar una metodología para establecer un ranking de esas
auditorías.
Una vez que haya determinado lo que auditará, puede ejecutar cada
auditoría que figura en el plan.
3. Las etapas de una auditoría.

Ahora que comprende el proceso de seleccionar lo que se va a auditar, discutamos
las varias etapas para realizar cada una de las auditorías que figuran en el plan.
Discutiremos las siguientes seis mayores fases de auditoría:
a) Planificación
b) Trabajo de campo y documentación.
c) Descubrimiento de debilidades y validación.
d) Desarrollo de soluciones.
e) Generación del borrador de reporte y su remisión.
f) Seguimiento de observaciones.
a) Planificación
Antes de iniciar un trabajo de auditoría, debe determinar lo que planea
revisar. Si el proceso de planificación es ejecutado efectivamente,
preparará al equipo de auditoría para el éxito. Por el contrario, si se lo
realiza pobremente y el trabajo comienza sin un plan y sin una
dirección clara, los esfuerzos del equipo de auditoría podrían resultar
en un fracaso.
El objetivo de un proceso de planificación es determinar los objetivos,
el alcance de la auditoría. Necesita determinar qué es lo que necesita
cumplir con la revisión. Como parte de este proceso, debería
desarrollar una serie de pasos para ser ejecutados en orden para
cumplir con los objetivos de la auditoría. Este proceso de planificación
requerirá una investigación cuidadosa, pensada sobre cada auditoría.
a) Planificación
A continuación se presentan algunas fuentes básicas que deberían ser
referenciadas como parte de cada proceso de planificación de
auditorías:
I. Manos libres de parte del Gerente de Auditoría
II. Encuesta preliminar
III. Requerimientos de los clientes
IV. Checklists estándares
V. Investigación
a) Planificación
I) Manos libres por parte de la Gerencia de Auditoría
Si la auditoría está incluida en el plan de auditoría, debe haber una
razón para ello.
El gerente de auditoría debería transferir al equipo de auditoría la
información que llevó a que dicha auditoría sea agendada. Esto podría
incluir comentarios del gerente de TI y o preocupaciones conocidas en
el área. Los factores que llevan a que la auditoría sea agendada
necesita ser abarcado en el plan de auditoría. Además, el gerente de
auditoría debería ser capaz de proveer al equipo de auditoría los
contactos claves para la auditoría.
a) Planificación
II) Encuesta preliminar
El equipo de auditoría debería pasar algún tiempo, antes de cada
auditoría, realizando una encuesta preliminar del área a ser auditada
para comprender lo que implicará la auditoría. Esto incluiría entrevistas
con los clientes a ser auditados para comprender la función del sistema
o procesos a ser revisados, así como también la revisión de cualquier
documentación pertinente. El objetivo es obtener un conocimiento
básico previo y una comprensión del área a ser revisada.
Es necesario realizar una evaluación preliminar de los riesgos en el
área.
a) Planificación
III) Requerimiento de los clientes
En el capítulo anterior mencionamos la importancia de hacer de la
auditoría un proceso colaborativo y cooperativo. Como parte del
cumplimiento de este objetivo, los clientes de la auditoría deberían
sentir que tienen alguna influencia, un sentido de pertenencia en la
auditoría. El equipo de auditoría debería consultar a los clientes qué
áreas piensan que deberían ser revisadas y cuáles son las áreas de
preocupación. Esta información debería ser consolidada con la
evaluación objetiva de riesgos del auditor para determinar el alcance
de la auditoria.
a) Planificación
Por supuesto, a veces los auditores no utilizaran la información
proporcionada por los clientes.
Por ejemplo, a veces los clientes de la auditoría estarán más
preocupados acerca de áreas que son más operacionales en su
naturaleza y no tienen impacto en los controles internos.
En tales casos, es perfectamente legítimo que el equipo de auditoría
desestime ese requerimiento del universo auditable con una
explicación a los clientes del porqué el equipo de auditoría no ejecutará
lo solicitado.
a) Planificación
También es importante no permitir al cliente desviar la atención de los
auditores de las áreas de revisión importantes.
Los auditores deben, en última instancia, aplicar su juicio profesional.
Sin embargo, obtener información de los clientes e incorporarlo al plan
de auditoría cuando fuera posible hará que los clientes se sientan
dueños del proyecto de auditoría y se optimice la apertura y la
comunicación honesta entre las partes.
a) Planificación
IV) Checklists estándares
Checklists estándares para el área a ser auditada puede que existan a
menudo.
Los checklist que veremos en este material pueden servir como un
excelente punto de partida para muchas auditorías.
Además, el departamento de auditoría podría tener sus propios
checklists para sistemas y procesos estándares en la compañía.
Contar con checklists de auditoría estándares y repetibles para áreas
comunes puede proporcionar elementos de inicio útiles para muchas
auditorías.
a) Planificación
IV) Checklists estándares
Sin embargo esos checklists deberían ser evaluados y alterados según
necesidad para cada auditoría específica.
Contar con un checklist estándar no libera al auditor de realizar una
evaluación de riesgos previa a cada auditoría.
V) Investigación
Finalmente, Internet, Libros y materiales de entrenamiento deberían
ser referenciados y utilizados apropiadamente para que cada auditoría
obtenga información adicional acerca del área que está siendo
auditada.
a) Planificación
Programa de auditoría.
Un elemento importante del proceso de planificación es el programa
de auditoría (esto es, determinar cuándo se realizará la auditoría).
En lugar de determinar cuándo se realizará una auditoría, basado
únicamente en la conveniencia del equipo de auditoría, la
programación de las auditorías debería ser realizada en cooperación
con los clientes internos.
Esto permitirá al equipo de auditoría considerar ausencias de personal
y periodos de alta actividad, durante los cuales el equipo de auditoría
puede que no cuente con el tiempo adecuado y la atención requerida
de la organización que están auditando.
a) Planificación
Programa de auditoría.
Programar las auditorías en cooperación con los clientes internos no
solo posibilita una auditoría más efectiva, sino que posibilita iniciar con
el pie derecho las auditorías, estableciendo una atmósfera de
flexibilidad y cooperación.
Los clientes internos valorarán el hecho que sus limitaciones y agendas
hayan sido consideradas y tendrá un sentido de mutuo
empoderamiento respecto al programa de auditoría.
a) Planificación
Reunión de inicio de tareas
Cerca del final del proceso de planificación, una reunión de inicio de
tareas debería realizarse con los clientes internos de modo que pueda
comunicarles lo que está y lo que no está en el alcance del proyecto de
auditoría y también recibir sus comentarios finales.
Durante esta reunión, debería continuar con su apertura hacia los
comentarios que realicen sus clientes y ser flexible respecto del alcance
de la auditoría.
a) Planificación
Reunión de inicio de tareas
De nuevo, si los clientes sienten que son dueños del proceso de la
auditoría, es más probable que cooperen plenamente cuando trabajen
con los auditores.
La reunión de inicio es también un gran momento para solicitar los
puntos de contacto para cada paso de auditoría y para determinar un
calendario y metodología (como reuniones o correos electrónicos) para
mantener informados a los clientes sobre el estado de la auditoría.
Una vez concluida la reunión de inicio, los pasos de auditoría deberían
ser asignados a los miembros del equipo de auditoría y puede
comenzar el siguiente paso de la auditoría.

El grueso de la auditoría ocurre durante esta fase, cuando los pasos de
auditoría creados durante la etapa precedente son ejecutados por el
equipo de auditoría. Ahora, el equipo está recabando datos y
realizando entrevistas que ayudarán a los miembros del equipo a
analizar los riesgos potenciales y determinar los riesgos que no han
sido mitigados apropiadamente.
Es importante que comprenda el valor del escepticismo sano. Cuando y
donde sea posible, los auditores deberían buscar maneras de validar
independientemente la información proporcionada y la efectividad del
ambiente de control. Aunque puede que esto no siempre sea posible,
el auditor siempre debería pensar creativamente para probar ciertas
cosas.

Por ejemplo, si el cliente de un auditor describe un proceso de aprobación de
solicitud de nueva cuenta de usuario, el auditor debería intentar obtener una
muestra de los usuarios recientemente dados de alta para verificar si ellos
contaban con las aprobaciones adecuadas. Esto nos proporcionará más
evidencia que el proceso está siendo seguido adecuadamente antes que la
entrevista con el cliente.
La documentación es también una parte importante del trabajo de campo.
Los auditores deben realizar un trabajo adecuado de documentación de sus
tareas de modo que las conclusiones puedan ser sustanciadas.
El objetivo debería ser documentar el trabajo en un detalle suficiente de
modo que una persona razonablemente informada pueda comprender lo
que fue hecho y llegar a las mismas conclusiones que el auditor.

El auditor, básicamente, debería estar contando una historia: “Aquí está
lo que he realizado.
Aquí está lo que he hallado. Aquí está mi conclusión”. Si lo que se
revisó fue un proceso, entonces el proceso debería ser descripto, y los
puntos clave de control dentro del proceso, deberían ser destacados.
Si un sistema o tecnología fue revisado, las configuraciones específicas
y datos revisados deberían ser descriptos (junto con cómo fue obtenida
la información) e interpretados.
El proceso de documentación puede ser visto tedioso, pero es importante.
Primero, es necesario cumplir con los estándares de la profesión.
Segundo, es posible que en el futuro los hallazgos de la auditoría pudieran
ser cuestionados o cambiados, y el auditor que realizó el trabajo puede que
ya no esté empleado por la compañía o departamento en ese entonces (o
puede que haya olvidado los detalles de la auditoría).
Será crítico que exista esa documentación para explicar el proceso de
auditoría y substanciar las conclusiones.
Tercero, si la auditoría es realizada de vuelta algún día, el retener
documentación detallada le permitirá al equipo de auditoría aprender de las
experiencias del equipo de auditoría previo, permitiendo por consiguiente
una mejora continua y eficiencia.

Una nota final sobre el trabajo de campo: Durante la fase de
planificación, se desarrollará un checklist con lo que se planea revisar
durante la auditoría.
Asegúrese que esos checklists no anulen el buen juicio de los miembros
del equipo de a auditores.
El equipo necesita permanecer flexible durante la auditoría y estar
preparados para explorar nuevos caminos que no fueron considerados
durante la fase de planificación.
Los miembros del equipo siempre necesitan tener en mente el objetivo
general de la auditoría y no convertirse en simples autómatas siguiendo
un guion preestablecido.
Nota: El propósito de la auditoría no es

ejecutar los pasos de auditoría, sino evaluar
el estado de los controles internos en el área
que está siendo revisada.
c) Hallazgos y validación
Cuando ejecuta trabajo de campo, los auditores desarrollarán una lista
de potenciales preocupaciones.
Esta es obviamente una de las fases más importantes de la auditoría, y
el auditor debe tener cuidado de depurar la lista de potenciales
problemas para asegurarse que todos los problemas son válidos y
relevantes.
En el espíritu de colaboración, los auditores deberían discutir
problemas potenciales con los clientes tan pronto como sea posible.
Nadie disfruta esperar que los auditores culminen con su trabajo para
enfrentarnos con una lista interminable de problemas.
No solo es incómodo para los clientes, sino también incómodo para el
auditor, porque puede encontrarse con que no toda la información es
correcta y no todos sus problemas detectados son válidos.
En vez de hacer un caso policiaco de cada problema potencial, aplique
un procedimiento informal con el cliente: “Creo que he descubierto
algo preocupante. ¿Podemos discutirlo para asegurarme que tengo los
hechos correctos y estoy comprendiendo los riesgos apropiadamente?
Esto permite que el cliente trabaje con el auditor para validar el
problema y también anima al cliente a tener sentido de propiedad
sobre el problema.
Además de validar que los hechos recogidos son correctos, necesita
validar que el riesgo presentado por el problema es suficientemente
significativo para que valga la pena reportarlo y solucionarlo.
No recoja problemas u observaciones por el simple hecho de levantar
observaciones.
Por el contrario, registre los problemas que pudieran presentar riesgos
significativos para la compañía.
Considere los controles mitigantes y asegúrese de tener una visión de
conjunto antes de determinar si el problema detectado merece la pena
ser reportado.
Además de validar que los hechos recogidos son correctos, necesita
validar que el riesgo presentado por el problema es suficientemente
significativo para que valga la pena reportarlo y solucionarlo.
No recoja problemas u observaciones por el simple hecho de levantar
observaciones.
Por el contrario, registre los problemas que pudieran presentar riesgos
significativos para la compañía.
Considere los controles mitigantes y asegúrese de tener una visión de
conjunto antes de determinar si el problema detectado merece la pena
ser reportado.
d) Desarrollo de la solución
Después de haber identificado los problemas potenciales en el área que está
auditando y haber validado los hechos y riesgos, puede trabajar con los
clientes en desarrollar un plan de acción para abordar cada problema.
Obviamente, solo con levantar observaciones no se hace mucho bien a la
compañía, a menos que esas observaciones sean adecuadamente atendidas.
Tres procedimientos comunes son utilizados para desarrollar y atacar los
problemas levantados:
I. El método de seguir recomendaciones
II. El método de respuesta de la administración
III. El método de solución de las observaciones
I) El método de seguir recomendaciones
Utilizando este método común, los auditores levantan observaciones y
proveen recomendaciones para solucionarlos. Luego consultan con los
clientes si ellos están de acuerdo con las recomendaciones, si lo están,
consultan cuando lo tendrían solucionado.
El siguiente es un escenario común para este tipo de metodología.
• El equipo de auditores descubre que no existe ningún procedimiento para
asegurar que los usuarios cuenten con los últimos parches de seguridad en
sus PCs antes de conectarla a la red corporativa.
• Ellos presentan el problema a los clientes, junto con recomendaciones que
dicen, “Recomendamos que exista un proceso para asegurar que los
usuarios tienen el último parche de seguridad en sus PCs antes que sean
permitidos a conectarse a la red”, o algo igualmente brillante y útil.
• Luego los auditores consultan con los clientes cuando podrían concluir con
dicho proceso.
• Los clientes lanzan una fecha para sacarse de encima a los auditores,
generalmente sin pensar en lo que realmente implica el trabajo.
• Los auditores se marchan contentos porque su recomendación fue
aceptada y cuentan con una fecha de vencimiento del compromiso.
¿A quién le importa que los clientes no tengan un empoderamiento del
plan de acción y que probablemente no cumplirán con la fecha
comprometida?
Nos preocuparemos de eso en unos cuantos meses cuando la fecha
caduque, ¿no?
Este ejemplo, obviamente es un poco exagerado, pero, desafortunadamente,
no está tan alejado de la realidad.
El método de seguir recomendaciones puede funcionar si se lo maneja bien
por parte del equipo de auditoría con conocimiento y experiencia. Sin
embargo, generalmente resulta que los clientes no sienten un sentido de
pertenencia sobre el plan de acción recomendado, porque ellos solo están
haciendo lo que los auditores les dijeron que hagan. Además, los clientes
que están siendo auditados están más capacitados para tener un
conocimiento más detallado del área que está siendo auditada que los
auditores, lo que significa que ellos están en mejor posición para desarrollar
una solución al problema.
Exhibiéndoles una recomendación y consultándoles si la aceptan hará
que los clientes estén menos motivados a pensar sobre el problema
observado y desarrollar un plan de acción realista y trabajable.
Por el contrario, ellos pueden tender a “aceptar” la recomendación
para deshacerse de los auditores, solo para descubrir las complejidades
cuando el cronograma de cumplimiento esté por vencer y los auditores
están haciendo el seguimiento.
Esto conduce a que los auditores informen el incumplimiento del
cronograma o la extensión de la solución del problema, lo cual no es un
proceso eficiente.
II) El método de respuesta del administrador
Con esta aproximación, los auditores desarrollan un listado de
observaciones y luego se las exponen a los clientes para que respondan
con sus planes de acción.
A veces los auditores enviarán sus recomendaciones para las soluciones
junto con los puntos observados, y a veces solo enviarán las
observaciones sin recomendación alguna.
De cualquier modo, los clientes, se supone, que enviarán su respuesta a
las observaciones del reporte de auditoría.
Esto se presta a un elegante “señalar con el dedo” o nombrar los culpables.
El auditor escribe, “Existe un problema.
Nosotros recomendamos que ellos lo reparen.” Los administradores
responden, “Nosotros pensamos que es una estupidez, pero aceptamos e
implementaremos una solución “a medio cocinar” que no creemos que
agregue valor, solo para sacarnos a los auditores de encima”.
O aún peor, la respuesta del administrador puede ser algo así: “Pensamos
que esto es una estupidez y no vamos a hacer nada al respecto. Los
auditores se pueden arrojar al pozo”. En dichos casos, los auditores pueden
redactar su respuesta, diciendo algo así:
“¿Pueden creerle a esta gente?, Obviamente no les importan los controles.
Se lo haremos saber al CEO para meterlos en problemas”.
De nuevo, este es un ejemplo exagerado, pero no está muy alejado de la
realidad.
El método de respuesta del administrador no busca por sí mismo alcanzar el
consenso pero básicamente permite que los auditores se laven las manos de
la responsabilidad que significa reportar los problemas y sus soluciones.
En vez de desarrollar una solución consensuada, ellos simplemente dicen lo
que desean y luego permiten que los clientes de la auditoría digan lo que
desean, teniendo los auditores la última palabra en el reporte.
Si éste método es el utilizado por su compañía, trate de cambiarlo.
Si no lo puede cambiar, trate de trabajar extraoficialmente para lograr
consenso con los clientes.
Antes de enviar las observaciones y sus recomendaciones a los clientes,
trate de idear una solución en la que se sientan cómodos todas las
partes involucradas.
Su recomendación reflejará lo que ya lo han acordado, permitiendo
que la respuesta de los administradores sean algo como esto:”
Estamos de acuerdo e implementaremos sus sugerencias al final del
presente ejercicio”.
El método de respuesta del administrador no evita que coordine con
sus clientes soluciones mutuamente aceptables
III) El método de solución de las observaciones
Utilizando este método, los auditores trabajan con los clientes para
desarrollar una solución que representa un plan de acción desarrollado
conjuntamente y consensuado para solucionar los problemas levantados
durante la auditoría.
Es una combinación de los dos métodos precedentes, logrando lo mejor de
ambos.
Al igual que con el método de seguir las recomendaciones, los auditores
proveen ideas para la solución basados en su conocimiento de control.
Al igual que con el método de respuesta del administrador, los clientes
proveen ideas para resolución de los problemas basados en sus
conocimientos operacionales de la vida real.
El resultado es una solución que los clientes “poseen” y que es satisfactoria
para los auditores. Debido a que los clientes tienen un sentido de
pertenencia sobre los problemas reportados, los clientes están más
predispuestos a remediarlos.
Bajo este método, el reporte de auditoría refleja sutilmente el cambio en el
sentido de pertenencia. Con el método de recomendación, los auditores
podrían escribir algo así: “Recomendamos que sean habilitadas pistas de
auditoría” o “Deberían ser habilitadas las pistas de auditoría”. Estas
oraciones enfatizan los deseos de los auditores y a menudo son
interpretadas por los clientes como pesadas y mandonas (y a menudo sin
sentido).
En este método, el desarrollo de la solución debe ser verdaderamente
colaborativa.
Aunque los auditores deben permitir que los clientes desarrollen las ideas
iniciales, deben tener preparadas algunas soluciones potenciales bajo la
manga en caso que los clientes no puedan salir con respuestas aceptables.
Además los auditores deberían tener alguna idea de con cuanta medida de
mitigación se sentirían satisfechos.
Necesitan estar preparados para permitir a los clientes conocer si las
soluciones propuestas no reúnen los mínimos requisitos de mitigación de
riesgos.
Guías para el desarrollo de soluciones
Sin importar el método utilizado, necesita establecer quién es responsable
por la ejecución de los planes de acción y las fechas de vencimiento en las
que deberían concluir los planes de acción. Esto asigna responsabilidad a los
clientes y una base para el seguimiento de los auditores. En la medida que
estos planes de acción son desarrollados, los auditores deberían ser flexibles
con relación a cuan finalizados deben estar los planes de acción en el reporte
de auditoría.
Algunas observaciones permiten soluciones inmediatas, como cambiar las
configuraciones de un sistema o bloquear permisos de archivos. En estas
instancias esperaría que los clientes indiquen la fecha exacta en que la
solución será implementada.
Sin embargo, otras observaciones requerirán soluciones complejas y
requerirán el involucramiento de múltiples organizaciones y el
desarrollo de procesos complejos o la adquisición de nueva tecnología.
En estas instancias, no es realista esperar que los clientes conozcan
inmediatamente lo que deben hacer y cuando lo concluirán.
Por el contrario, se requerirán periodos de evaluación en los cuales se
examinarán las alternativas y un cronograma detallado será
desarrollado.
En vez de presionar a los clientes para proveer información cuando no
es realista esperar que lo hagan, puede definir una fecha intermedia en
la que ellos habrán elegido una solución y desarrollado un cronograma.
Una vez que dicha fecha sea alcanzada, si han desarrollado un plan de
acción detallado, se puede establecer una nueva fecha de compromiso
basada en dicho plan.
Nota: Cuando desarrolla soluciones, el auditor debería tener en mente que no
siempre es práctico que pueda ser mitigado el 100% del riesgo. A veces la
mitigación del total de riesgo sería prohibitivo en costos, pero en 80% del riesgo
podría ser mitigado por un costo razonable.
Esto es conocido como el concepto de Pareto, en el cual los primeros
80% del riesgo pueden ser solucionados por el 20% del costo.
Si el auditor se empecina en requerir el 100% de solución, la credibilidad y
relacionamiento del auditor con el cliente se verá dañada y los clientes puede que
no hagan nada para mitigar el riesgo. Haber solucionado el 80% del riesgo es mejor
que 0% del riesgo solucionado. El auditor debe recordar que él es un empleado de
la compañía y debería impulsar soluciones que sean razonables y costo –
beneficiosas. Por supuesto, el auditor debe ser objetivo y asegurar que el riesgo no
mitigado no es razonable. Sin embargo, los auditores que siempre insisten en el
100% de las soluciones se convierten en auditores que son evitados y quienes no
tienen sentido del negocio.
También es importante que trabaje con los clientes para ser flexible
cuando establece fechas de cumplimiento de las soluciones a las
observaciones. Recuerde que mucha de la actividad dentro de las
organizaciones de los clientes no tiene que ver con auditoría interna.
Ponga las observaciones de auditoría en contexto con las otras
presiones y prioridades del grupo de TI.
Algunas veces sus puntos de auditoría no serán la máxima prioridad, y
está bien. Establecer fechas de vencimiento realistas con las que los
clientes se sentirán cómodos promoverá confianza mutua haciendo
más probable que las observaciones sean levantadas a tiempo y
ayudándole a evitar recalendarización y escalamientos.
Además, a veces los clientes están de acuerdo con los auditores pero
no piense que tendrán los recursos para solucionarlos.
¿De modo que como resolvería estas situaciones?
¿Se debatirá en un duelo de gritos e improperios?
¿Les amenazará a sus clientes, recordándoles que Ud. reporta al comité
de auditoría y que los puede meter en problemas por no solucionar las
observaciones?
¡Absolutamente no!
Estas situaciones pueden ser manejadas con respeto y
cooperativamente.
Recuerde que el concepto de requerimientos de auditoría es una
expresión equivocada o inexistente.
El departamento de auditoría no es un cuerpo en el que se definen
requerimientos y por consiguiente no debería estar en el negocio de
tratar de forzar las acciones de los clientes.
Por el contrario el trabajo del auditor es identificar los riesgos y
asegurarse que el nivel adecuado de gerencia es advertido de esos
riesgos de modo que puedan ser tomadas las decisiones para
mitigarlos o no.
Aceptar un riesgo es una opción legítima para los administradores.
El auditor debe utilizar su juicio para determinar qué nivel de administración
debe estar al tanto del riesgo.
Algunas de las observaciones de auditoría representan solo una pequeña
porción de riesgo.
En cuyos casos, si un administrador indica que el comprende y acepta el
riesgo el auditor puede documentarlo y continuar.
En otros casos, el riesgo es más severo, y el auditor cree que el CIO debería
ser advertido del problema.
Sin embargo, si el CIO comprende el riesgo y decide aceptarlo, de nuevo, el
auditor ha realizado su trabajo y no es necesaria ninguna acción adicional.
Pero si otras observaciones representan un riesgo tan severo que el auditor
se sentirá confortable solo con la firma del CEO o aún del comité de
auditoría.
Incluso si cree que debe ir por encima de la cabeza de alguien para hacer que
el nivel apropiado de gerenciamiento esté consciente de un riesgo dado, no
debería ser considerado como un evento adverso.
Puede explicar de manera calmada a sus clientes que comprende sus razones
para evitar intentar la solución del problema y que su trabajo requiere
informar a niveles superiores de administración acerca del riesgo para
asegurar que ellos también se sienten confortables en aceparlos.
Incluso puede invitar al cliente a participar en cualquier reunión para discutir
el riesgo y o mantenerlos informados por correo electrónico.
Esta tarea no se debería convertir en un juego de “él o ella dijo” sino por el
contrario puede ser una relación abierta y respetuosa en la que los auditores
expliquen los puntos de vista de los clientes así como sus propios puntos de
vista durante las comunicaciones con los administradores.
Escalar una observación a menudo resultará en un resultado positivo para
los clientes, como recursos adicionales asignados para permitir la solución de
problemas, de modo que el proceso de escalamiento no tiene que ser un
proceso traumático.
Y a veces los clientes desean que los auditores escalen una observación para
obtener respaldo adicional para solucionar problemas conocidos que quizás
no recibieron la atención adecuada previa a la auditoría.
Cuando se escala las observaciones a la administración, asegúrese de que
todos en la cadena estén informados, de modo que ninguno sienta que está
siendo evitado o no está siendo tenido en cuenta.
Por ejemplo, si piensa que un problema necesita ser escalado al mismo CIO,
converse con cada nivel de gerentes entre el cliente del auditor hasta el CIO
en orden. Esto ayuda a evitar traumas en el proceso de escalamiento.
e) Borrador de reporte y su remisión

Una vez que ha descubierto los problemas en el ambiente que esté
siendo auditado, los haya validado con los clientes y desarrollado una
solución para atacarlos, puede redactar el borrador de reporte de
auditoría. El reporte de auditoría es el vehículo por el cual el auditor
documenta los resultados de la auditoría.
El reporte sirve para dos funciones principales:
• Para el auditor y sus clientes, sirve como un registro de la auditoría,
sus resultados y los planes de acción resultantes.
• Para la administración superior y el comité de auditoría, sirve como
un registro sobre el área auditada.

Elementos esenciales de un reporte de auditoría.
Existen tantos formatos de reportes de auditoría como departamentos
de auditoría interna.
Sin embargo, los siguientes son elementos esenciales de un reporte de
auditoría:
I. Explicación del ámbito de la auditoría
II. Resumen ejecutivo
III. Lista de observaciones, junto con los planes de acción para
resolverlos.

I) Explicación del ámbito de la auditoría
Deje bien claro en el reporte lo que fue incluido en la auditoría y si es
necesario lo que no fue incluido en la auditoría.
Si un área o tópico fue dejada fuera del alcance de la auditoría, es
importante que se lo mencione en el reporte para evitar malos
entendidos.

II) Resumen ejecutivo
Además de detallar todas las observaciones y los planes de acción, debe
escribir un resumen ejecutivo de modo que alguien que no tiene el tiempo o
la inclinación para leer todos los detalles pueda comprender el estado
general de los controles en el ambiente.
Este resumen debería servir por si solo como un documento informativo, aún
si fuera removido del resto del reporte. No debería listar o discutir cada
problema encontrado, sino solo los más significativos. No debería ser un
listado tedioso de resultados de cada área revisada, Por el contrario, debería
reflejar información relevante acerca de los resultados de la auditoría,
asumiendo que el lector no lee ninguna otra parte del reporte.

No debería incluir vaguedades, no diga simplemente “El área estaba
generalmente bien controlada, pero existen oportunidades de mejora”
¿Qué significa esto? Sea claro y esgrima una opinión. Mejor escriba
esto:
Se observaron fuertes controles sobre la administración de cuentas, pero un
número de preocupaciones de control fueron halladas relacionadas con el
control de cambios de aplicaciones. Los problemas más significativos son el
hecho que desarrolladores tienen acceso directo para actualizar códigos en
producción.

Esto significa que estos programadores pueden alterar la funcionalidad del
código de producción sin pasar por las fases de aprobación y autorización. El
equipo de desarrollo ha desarrollado planes de acción para atacar esta
preocupación, la cual resultará en la remoción de sus privilegios de acceso del
entorno de producción. Mayores detalles serán encontrados en la sección
“Observaciones”.

III) Lista de observaciones y planes de acción
Este es el corazón del reporte porque provee detalles de todos los problemas
significativos descubiertos durante la auditoría y lo que se va a hacer para
solucionarlos.
Calidad y claridad en la escritura son esenciales, porque cada observación
debe ser documentada de modo tal que múltiples niveles de lectores puedan
comprenderlo.
Gente que lidia con el área a diario debería poder comprender sus
observaciones y planes, así como la alta gerencia debería también poder
comprender el riesgo y porque necesita ser mitigado.

Explique los conceptos en términos generales y explique cada riesgo. Por
ejemplo, si tiene una preocupación acerca de la configuración por defecto
umask en un servidor, podría escribir una observación que diga, “Los valores
por defecto de umask en el servidor están codificados en 000.”
Aunque los administradores Unix entenderán su preocupación
inmediatamente, esta observación carece por completo de significado para
cualquier otro que lo lea.
Alternativamente se podría redactar la observación de esta manera: “Los
permisos de archivos en el servidor necesitan ser mejorados”

En este caso el lector lego en la materia comprenderá la observación, pero el
administrador Unix podría interpretar esto de muchas maneras y necesita
más detalles acerca de a qué aspecto de permisos de archivos se está
refiriendo.
Una mejor alternativa es redactar la observación de la siguiente manera:
El valor por defecto umask en el servidor está codificado en 000. Esto significa que, por
defecto, cuando un nuevo archivo es creado, sus permisos están configurados de modo
que cualquiera con acceso al servidor podrá leer y escribir en el archivo. Como este
servidor contiene archivos de datos financieros críticos, esto podría facilitar accesos
indebidos al dato o cambios son autorizados a los mismos.

En este caso el lector lego en la materia comprenderá la observación, pero el
administrador Unix podría interpretar esto de muchas maneras y necesita
más detalles acerca de a qué aspecto de permisos de archivos se está
refiriendo.
Una mejor alternativa es redactar la observación de la siguiente manera:
El valor por defecto umask en el servidor está codificado en 000. Esto significa que, por
defecto, cuando un nuevo archivo es creado, sus permisos están configurados de modo
que cualquiera con acceso al servidor podrá leer y escribir en el archivo. Como este
servidor contiene archivos de datos financieros críticos, esto podría facilitar accesos
indebidos al dato o cambios son autorizados a los mismos.

A continuación se presenta un ejemplo simplificado de un reporte de
auditoría, utilizando los elementos descritos en la sección precedente.
Ámbito de la auditoría
Durante esta auditoría, hemos revisado los controles internos dentro del
sistema de aplicación de la compañía. Esto incluyó la revisión de controles
dentro de la aplicación, su base de datos relacionada y su sistema operativo.
Controles de Seguridad física del servidor del sistema de aplicación no fueron
realizados en esta revisión porque los mismos fueron verificados durante una
reciente auditoría del centro de procesamiento de datos.

Resumen ejecutivo
Se verificó que existen fuertes controles sobre las cuentas administradoras,
pero hallaron observaciones sobre aspectos de control, relacionadas con el
control de cambios en el software. Lo más significativo de esta observación es
el hecho que los desarrolladores tienen acceso directo al código de producción.
Esto significa que esos programadores pueden alterar la funcionalidad del
código de producción sin pasar por una adecuada validación / prueba ni circuito
alguno de aprobación. El equipo de desarrollo ha desarrollado un plan de
acción para solucionar esta preocupación, lo cual resultará en la remoción de
sus privilegios de acceso del entorno de producción. Más detalles pueden ser
encontrados en la sección de Observaciones.

Observaciones de la auditoría
Los desarrolladores tienen acceso directo para modificar código de
producción.
No se detectaron controles técnicos ni de procedimientos para prevenir que el
personal de soporte técnico realice cambios no autorizados al sistema.
Riesgo: Sin adecuados controles de cambios de programas, los cambios podrían
ser realizados a la aplicación, ya sea sin intención o maliciosamente, sin que
hayan sido probados adecuadamente o peor aún, sin ser autorizados.
Estos cambios de código podrían resultar en el procesamiento inadecuado del
sistema, la posibilidad que un empleado ejecute transacciones fraudulentas y
inhabilite el sistema.

Solución: Se implementará una herramienta para proteger el código de
producción. La posibilidad de registrar un nuevo código en esta herramienta
estará limitara al grupo administrador y un respaldo, ninguno e los cuales
tendrá autorización para realizar cambio en el código. Una vez que esté
implementada esta herramienta, el equipo documentará los procedimientos
requiriendo aprobación y pruebas antes de remitir nuevos códigos a
producción.
Responsable: Juan Pérez
Fecha de implementación: xx/xx/xx

Elementos adicionales de un reporte de auditoría
Además de las tres secciones básicas que acabamos de mencionar, podría
considerar agregar unos cuantos elementos adicionales a sus reportes.
Controles claves: Además de los problemas que ha encontrado,
indudablemente habrá encontrado aspectos positivos que están siendo
realizados. Algunos controles importantes están siendo realizados y en los
cuales se basó durante su evaluación. Si estos controles no estuvieron
implementados o fueron cambiados, cambiaría su evaluación general del
entorno. ¿Acaso no es tan importante para sus clientes saber lo que están
haciendo bien, como saber lo que necesita ser mejorado? Si no les dice que
considera que un control en particular es importante, puede que tomen la
decisión de dejar de realizarlo.

Observaciones levantadas: Si sus clientes resuelven las observaciones
durante el curso de la auditoría, deles crédito por ello.
Liste las observaciones que ya han sido resueltas en una sección
separada.
Esto hace que las observaciones levantadas no abulte la sección de
“Observaciones”, y da crédito a los clientes por haber sido proactivos, y
además asegura que el reporte de auditoría refleja toda la película de
los problemas detectados en el momento de la revisión.

Problemas menores: A veces encuentra problemas menores durante el
proyecto, los que no representan un gran riesgo. NO tiene interés en
hacer un seguimiento de las soluciones de los mismos porque no es
importante saber si los clientes los solucionan o no. Simplemente
desea que los clientes estén informados de sus observaciones de modo
que puedan tomar acción si lo desean. Los problemas menores pueden
ser listados en una sección especial, donde aclara que están siendo
reportados a modo de información meramente y que no requiere
planes de acción o seguimiento de sus resoluciones.
Distribución del reporte de auditoría
Una vez culminado el borrador de reporte, debería permitir que sus clientes
lo revisen y realicen comentarios antes de remitirlos formalmente.
Muéstrese dispuesto a realizar cambios menores de palabras mientras que
no cambien el contexto de lo que está observando.
El objetivo debería ser que los clientes se sientan cómodos con el reporte y
concuerden con él.
Después que el borrador de reporte ha sido revisado por los clientes, es
tiempo de remitirlo formalmente. Muchos departamentos de auditoría
remiten todos los reportes de auditoría a la alta gerencia (incluyendo al CIO,
CFO y al CEO) y a veces incluso al comité de auditoría.
4. Seguimiento de observaciones
Es común que los auditores sientan que el trabajo está hecho cuando
remiten el informe de auditoría.
Sin embargo, como se discutiera anteriormente, remitir un reporte de
auditoría no agrega valor a la compañía a menos que resulte en acciones
concretas para su solución.
La auditoría no está verdaderamente completa hasta que las observaciones
levantadas en la auditoría son resueltas, ya sea solucionando el problema (la
solución preferida) o aceptando el riesgo por parte del nivel adecuado de
gerenciamiento.
El departamento de auditoría debe desarrollar un proceso donde sus
miembros sean capaces de hacer un seguimiento de los problemas hasta que
sean resueltos.
Esto involucraría el mantenimiento de una base de datos conteniendo

todos los puntos de auditoría y sus fechas de vencimiento, junto con un
mecanismo para levantar la observación, alertar sus vencimientos y
cosas por el estilo.
Es inteligente que el auditor que realizó o lideró la auditoría, sea el
responsable por el seguimiento de los puntos observados con el
responsable de los clientes a medida que se aproximan las fechas de
vencimiento de los compromisos.
El auditor no debería esperar hasta que venzan o luego que venzan
para contactar con los clientes, sino que debería estar regularmente en
contacto con ellos para consultar sobre el estado de las observaciones.
Esto sirve para un sinnúmero de propósitos:

• Primero permite que el auditor consulte con los clientes mientras
están siendo tomadas las decisiones.
• Segundo, permite al auditor estar alerta de manera temprana si la
solución que está siendo implementada no se ajusta a las
expectativas. En este caso, el auditor puede tratar de redirigir las
actividades antes que las tareas finalicen.
• Tercero, si el problema no está siendo resuelto, permite que el
departamento de auditoría trate de gestionar la solución antes que
llegue al punto de vencimiento de plazos.
Si sucede que la observación no está siendo encarada como se acordó,

los auditores son responsables de iniciar el procedimiento de
escalamiento a la instancia que corresponda.
Los auditores deben determinar cuán importante es el riesgo y tomar
una decisión acerca de mitigarlo o no.
Un problema debería ser escalado a este nivel de gerenciamiento solo
si es necesario.
Cada pequeño problema no necesita ser escalado al comité de
auditoría, porque los riesgos asociados con algunos problemas no los
necesitan. No necesita informar al comité de auditoría acerca de un
usuario que tiene una mala contraseña, por ejemplo.
Escalar un reporte debería ser un último recurso y no debería ser un

proceso mecánico.
Se debe mantener el juicio durante el proceso de seguimiento de
observaciones.
Si un punto está vencido, el primer paso debería ser pasar un tiempo
con el responsable de los clientes para comprender el porqué.
Si están trabajando en el problema, pero otras prioridades se han
interpuesto en el camino, resultando en la demora, o si ocurrió que la
implementación de la solución es más complicada que lo esperado
inicialmente, el punto no necesita ser escalado.
Por el contrario, considere extender la fecha de vencimiento mientras
se diseña una solución que no se demore indefinidamente.
Finalmente, se debe tomar una decisión con respecto a la validación de

las soluciones implementadas para solucionar las observaciones de la
auditoría.
¿Qué tanto énfasis se debe poner en la revalidación del área para
asegurar que los nuevos controles están funcionando efectivamente?
Aunque sería bueno volver a probar todos los puntos observados,
probablemente no sea práctico desde el punto de vista de los recursos.
En algunos casos se requerirá una completa re auditoría del área para
validar la solución. La respuesta práctica es realizar el “mejor esfuerzo”
para validar que el control fue efectivamente implementado.
Si la solución fue modificar la configuración del sistema, por ejemplo, el

auditor valida la configuración.
Si la solución fue crear un plan de recuperación de desastre, el auditor
puede revisar el plan, sin embargo, a veces la respuesta práctica es
hacer que el cliente explique y recorra el proceso y sistema que ha
estado implementado sin realizar pruebas efectivas.
Esta es otra área donde el juicio del auditor y el sentido común
necesitan ser aplicados.
• Estándares
Existen estándares para la profesión de auditoría y deberían ser
adheridos a ellos en la medida que las compañías desarrollan sus
procesos de auditoría.
En el sitio web del Instituto de Auditores Internos (IIA) www.theiia.org,
puede encontrar los estándares internacionales para la práctica
profesional de auditoría interna.
Estos estándares deberían ser revisados e incorporados en su proceso
de auditoría.
Además, en el mismo sitio web encontrará el código de ética para la
profesión, el que explica los requerimientos de integridad, objetividad,
confidencialidad y competencia que aplican a la auditoría.

Curso auditoría bancaria

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Curso auditoría bancaria

Cargado por

Copyright:

Formatos disponibles

Curso de auditoría empresarial y bancaria

Nuevos paradigmas – Presente y Futuro

1. Tipos de controles internos

c) Controles reactivos (controles correctivos)

Por ejemplo, podría tener un sistema centralizado de antivirus que

Ejemplos de controles internos.

• Control de cambios de programas de aplicación

• Copias de respaldo y planes de recuperación de desastres

2. Como determinar los puntos a auditar

Su plan de auditoría debe enfocar a sus auditores en áreas con mayor

• Creación del universo auditable

• Creación del universo auditable

• Creación del universo auditable

• Creación del universo auditable

• Creación del universo auditable

• Creación del universo auditable

• Creación del universo auditable

Nota: una buena fuente para asegurase que ha

Aunque su planificación siempre debería ser diseñada

• Elaboración de un ranking del universo auditable

• Elaboración de un ranking del universo auditable

• Elaboración de un ranking del universo auditable

• Elaboración de un ranking del universo auditable

• Elaboración de un ranking del universo auditable

• Elaboración de un ranking del universo auditable

• Elaboración de un ranking del universo auditable

• Elaboración de un ranking del universo auditable

• Elaboración de un ranking del universo auditable

3. Las etapas de una auditoría.

b) Trabajo de campo y documentación

b) Trabajo de campo y documentación

b) Trabajo de campo y documentación

b) Trabajo de campo y documentación

b) Trabajo de campo y documentación

Nota: El propósito de la auditoría no es

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

e) Borrador de reporte y su remisión

Esto involucraría el mantenimiento de una base de datos conteniendo

Esto sirve para un sinnúmero de propósitos:

Si sucede que la observación no está siendo encarada como se acordó,

Escalar un reporte debería ser un último recurso y no debería ser un

Finalmente, se debe tomar una decisión con respecto a la validación de

Si la solución fue modificar la configuración del sistema, por ejemplo, el

También podría gustarte