Informe de Auditoría

Introducción

"Es un medio formal para comunicar los objetivos de la Auditoría, el cuerpo de las
normas de Auditoría, el alcance de la Auditoría, y los hallazgos y conclusiones"

"Es el documento que refleja los objetivos, alcances, observaciones,

recomendaciones y conclusiones del proceso de evaluación relacionados con las
áreas de informática"

La elaboración del informe representa el momento adecuado de separar lo

significativo de lo no significativo, debidamente evaluados por su importancia y
vinculación con el factor de riesgo, tarea eminentemente de carácter profesional y
ético, según el leal saber y entender del Auditor Informático.

No existe un formato específico. 

Existen esquemas recomendados con los requisitos mínimos aconsejables respecto
a estructura y contenido. El orden y la forma del Informe puede variar de acuerdo
con la creatividad y estilo de los AI

El Informe de Auditoría deberá ser:

- claro
- adecuado
- suficiente
- comprensible

El formato del Informe debe reflejar una presentación lógica y organizada. 

El informe debe incluir suficiente información para que sea comprendido por los
destinatarios esperados y facilitar las acciones correctivas. 

Requisitos del Informe

Los requisitos de un Informe de Auditoría son:

1- Ser veraz
2- Estar documentado formalmente
3- Mostrar las observaciones (debilidades) encontradas
4- Tener recomendaciones y soluciones para cada observación
5- Reflejar las áreas de oportunidad y cursos de acción

Desarrollo del Informe

Los puntos esenciales de un Informe de Auditoría son:

1- Identificación del Informe

El título del Informe deberá identificarse como objeto de disitnguirlo de otros
informes

2- Identificación del Cliente

Debe identificarse a los destinatarios y a las personas que efectúen el encargo

3- Identificación de la Entidad auditada

Identificación de la entidad objeto de la Auditoría Informática
4- Objetivos de la Auditoría Informática
Declaración de los objetivos de la Auditoría para identificar su propósito, señalando
los objetivos incumplidos.

5- Normativa aplicativa y excepciones

Identificación de las normas legales y profesionales utilizadas, así como las
excepciones significativas de uso y el posible impacto en los resultados de la
Auditoría

6- Alcance de la Auditoría
Concretar la naturaleza y extensión del trabajo realizado: área organizativa,
período de auditoría, sistemas de información..., señalando limitaciones del alcance
y restricciones del auditado

7- Conclusiones: Informe corto de opinión

El Informe debe contener uno de los siguientes tipos de opinión:

opinión favorable: es el resultado de un trabajo realizado sin limitaciones de

alcance y sin incertidumbre, de acuerdo con la normativa legal y profesional

opinión con salvedades: se reitera lo dicho en la opinión favorable al respecto de las

salvedades cuando sean significativas en relación con los objetivos de auditoría,
describiéndose con precisión la naturaleza y razones

opinión desfavorabe: es aplicable en el caso de identificación de irreguilaridades y

de incumplimiento de la normativa legal y profesional, que afecten
significativamente a los objetivos de la AI

opinión denegada: puede tener su origen en las limtaciones al alcance de auditoría,

irregularidades, y al incumplimiento de normativa legal y profesional

resumen: consiste en una opinión personal de lo llevado a cabo

8- Resultado: Informe largo y otros informes

Este tipo de informe permite saber más.
Las soluciones previsibles se orientam hacia un Informe por cada objetivo de la AI

9- Informe previo
Este tipo de informe permite tener información de referencia

10- Fecha del Informe

Permite conocer la magnitud del trabajo y sus implicaciones

11- Identificación y firma del Auditor

12- Distribución del Informe

Se define quienes podrán hacer uso del Informe

Conclusiones
Es un juicio de valor u opinión personal con justificación

Modelo de un Informe de Auditoría

Fecha del Informe: 

NOMBRE DE LA ENTIDAD

Auditoría de ........

Objetivo
...........

Lugar de la Auditoría
...........

Grupo de Trabajo de Auditoría

...........

Fecha de Inicio de la Auditoría

...........

Tiempo estimado del proceso de revisión

X hs

Fecha de Finalización de la Auditoría

...........

Herramientas utilizadas
...........

Alcance
...........

Procedimientos a aplicar
...........

Informe de debilidades detectadas

Situación Comentario Comentario de la

actual  Gcia
     
     
     

CONCLUSIONES
...........

Ejemplo de un Informe de Auditoría

Situación planteada

En una “Compañía de Seguros” se llevó a cabo la “Auditoría de una Base de Datos”.

Esta BD operativa es utilizada por todos los sistemas existentes en la empresa.

Se cuenta con una BD Oracle 7.3 instalada en un Server, al cual tienen acceso 40
terminales. Existen desarrolladores y usuarios finales que acceden a la misma por
medio de la autorización otorgada por el DBA (Administrador de la BD). 
Se observa que:
- la BD tiene los siguientes objetos definidos: tablas, views (vistas) y sequence
-  el personal a cargo del  mantenimiento de la BD realiza 1 copia de resguardo al
final del día.
- hasta el momento, la BD cuenta con más de 2 millones de registros.

INFORME  DE  AUDITORIA

 Fecha del Informe:   12 / 06 / 2000 

 Nombre de la Entidad:   Seguros S.A 

 AUDITORIA  DE  UNA  BASE  DE  DATOS 

Objetivo

Controlar la definición y existencia de los objetos necesarios para la normal

utilización de una BD y para mejorar su performance. 

Lugar de la Auditoría:  Area de Sistemas 

Grupo de Trabajo de Auditoría:  Lic. Jorge Gorostiza

                                                    Lic. Gustavo Barrientos 

Fecha de Inicio de la Auditoría:  12 / 05 / 2000 

Tiempo estimado del proceso de revisión:  30 hs 

Fecha de Finalización de la Auditoría:  19 / 05 / 2000

Herramientas utilizadas

-  Metodología de auditoría de objetivos de control

-  Utilitarios estándar 

Alcance

Controlar la definición y existencia de todos los objetos que son necesarios en la BD

y que son utilizados por los distintos sistemas de la empresa. 

Procedimientos a aplicar: 

Objetos

     -  ¿Las tablas definidas en el diseño coinciden con las fueron

creadas en la BD teniendo en cuenta nombres de las tablas,
columnas y tipos de datos de las columnas?
- ¿Están definidas las claves primarias (PK) y claves externas (FK)
de c/ tabla existente?
- ¿Existen las secuencias (sequences) correspondientes a la clave
primaria (PK) de c/ tabla definida?
- ¿La BD tiene vistas (views) respecto de algunas tablas?
 - Para mejorar el performance del sistema, ¿el DBA definió que
sean necesarios según los casos?
- ¿Existe documentación actualizada respecto del diseño e
implementación de la BD?

 Datos 

      - ¿Con qué frecuencia se realiza una copia de resguardo (backup)

respecto de la BD?
- ¿Cada cuánto tiempo se realiza una actualización de los datos
existentes?

 Usuarios

      -  ¿Cuántos usuarios tienen acceso a la BD?

- ¿Cuántos usuarios actúan como desarrolladores respecto de la
BD?
- ¿Cuántos usuarios son usuarios finales de la BD?
-  ¿Cuáles son los roles y privilegios establecidos por el DBA?
-  ¿Todos los usuarios tienen definido un rol determinado?

 Informe de las debilidades detectadas 

Situación Actual Recomendación Comentario de la

Gcia de Sistemas

 
No existen índices que Crear los índices que De acuerdo
permitan mejorar el correspondan de acuerdo con las (Sr. Gte de
performance del sistema aplicaciones que fueron Sistemas)
desarrolladas.
 
Se realiza una copia Debido al caudal de información De acuerdo
diaria de resguardo que maneja la empresa, se (Sr. Gte de
(backup) sugiere realizar 2 backups diarios, Sistemas)
uno a mitad del día y otro al final
del día.

 CONCLUSIONES

El equipo de auditores considera que la empresa NO realiza las tareas de

actualización y mantenimiento necesarias, las cuales son esenciales para el normal
funcionamiento de la misma y para el cumplimiento de los objetivos establecidos en
las distintas áreas de la empresa.

Casos Prácticos

Estos casos tienen como finalidad, la elaboración de un "Informe de Auditoría"

teniendo en cuenta las situaciones planteadas.

Caso 1
En una “Empresa alimenticia”  se llevó a cabo la “Auditoría de una Planificación”, la
cual es utilizada por el Director del proyecto para evaluar el desarrollo del mismo.  
Se cuenta con un equipo de desarrollo formado por 32 personas, el cual está
dividido por proyectos.

La empresa, en este momento, está desarrollando 4 proyectos. Cada proyecto está

formado por 4 programadores, 2 analistas programadores, 1 analista funcional y 1
líder de proyecto.  
Cada profesional actualiza diariamente la planificación requerida por la empresa. 

Se observa que:
- no todos los miembros del equipo de desarrollo están informados de sus roles,
responsabilidades respectivas y del tiempo asignado a c/u de ellos
- existen pocos hitos o puntos de control en el desarrollo de los proyectos
- los tiempos estimados no se corresponden con los costos calculados

Caso 2

En un “Banco”  se llevó a cabo la “Auditoría de una Etapa de Análisis”, la cual es

utilizada por el Director del proyecto para evaluar el desarrollo del mismo. 
Un equipo de 10 analistas funcionales se ocupa de llevar a cabo lo siguiente:
1-       Análisis de requisitos del sistema
2-       Especificación funcional del sistema 

En el “Análisis de requisitos del sistema” se identificarán los requisitos del nuevo

sistema. Se incluirán tanto los requisitos funcionales como los no funcionales,
distinguiendo para c/u de ellos su importancia y prioridad. Luego, se determinarán
las posibles soluciones alternativas que satisfagan esos requisitos y se elegirá la
más adecuada. 

En la “Especificación funcional del sistema” se elaborará una especificación

funcional detallada del sistema que sea coherente con lo que se espera de él. 

Se observa que:
- no todas las especificaciones funcionales  y análisis de requisitos del sistema
tienen un formato determinado
- existen especificaciones funcionales que no fueron actualizadas y otras están
incompletas
- no todo el equipo de desarrollo está actualizado de los cambios efectuados

Caso 3

En una “Empresa petrolera”  se llevó a cabo la “Auditoría de una Etapa de Diseño”,

la cual es utilizada por el Líder del proyecto para evaluar el desarrollo del mismo.  

Un equipo de 12 analistas funcionales se ocupa de llevar a cabo el  “Diseño técnico”

y las “Especificaciones técnicas” de los sistemas. La empresa cuenta con un formato
determinado respecto de las especificaciones, es decir cómo se deben
documentar.  

Se observa que:
- no todas las especificaciones técnicas del sistema tienen un formato determinado
- existen especificaciones técnicas que no fueron actualizadas y otras están
incompletas
- no existe una vinculación entre lo llevado a cabo en la etapa de análisis y lo
realizado en la etapa de diseño
- no todo el equipo de desarrollo está actualizado de los cambios efectuados

Caso 4

En una “Empresa de Telefonía”  se llevó a cabo la “Auditoría de una Etapa de

Construcción”, la cual es utilizada por el Director del proyecto para evaluar el
desarrollo del mismo. 

Un equipo de 30 programadores se ocupa de llevar a cabo la codificación de los

sistemas en desarrollo. Cada programador tiene asignado un tiempo de desarrollo y
un módulo de un determinado componente, el cual será visto y probado por el
Analista funcional que corresponda.

Se observa que:
- no se desarrollaron todos los componentes de la aplicación
- que no se probaron todos los componentes y que no existen los informes de
prueba correspondientes
- los usuarios no participaron en la prueba de los componentes
- no existen los objetos necesarios en la BD para la ejecución de los componentes 

Caso 5

En una “Empresa de Telefonía Celular”  se llevó a cabo la “Auditoría de una Etapa

de Implantación”, la cual es utilizada por el Director del proyecto para evaluar el
desarrollo del mismo.  

Un equipo de 20 programadores se ocupa de llevar a cabo la prueba de los

sistemas en desarrollo. Cada programador se ocupa, entre otras cosas, de probar
aplicaciones y de emitir un informe en base a los resultados obtenidos de la prueba.
En caso de encontrar fallas, el programador informará en qué sistema existen los
inconvenientes. El Analista funcional decidirá quién resuelve las fallas encontradas.
La aprobación final de una aplicación se registra en un documento. 

Se observa que:
- no todas las componentes cumplen las especificaciones funcionales llevadas a
cabo
- los resultados de las pruebas no son los correctos 
- no existe un documento de conformidad de los usuarios hacia el equipo de
desarrollo respecto de lo realizado hasta el momento
- la BD no cuenta con todos los objetos necesarios para la prueba de los sistemas 

Caso 6

En una “Empresa Proveedora de Internet”  se llevó a cabo la “Auditoría del

Mantenimiento de Software”, la cual es utilizada por el equipo del proyecto para
evaluar el desarrollo y/o mantenimiento del mismo.  

Un equipo de 10 programadores se ocupa de llevar a cabo las siguientes tareas:

detección y corrección de errores, actualización / cambio del software desarrollado
y actualización / cambio de los paquetes de software. 

Se observa que:
- este equipo no documenta las modificaciones llevadas a cabo ni los cambios
realizados
- la detección de errores no es dada a conocer para así prevenir futuros problemas

Caso 7

En una “Empresa siderúrgica”  se llevó a cabo la “Auditoría de Calidad de

Software”, la cual es utilizada por el equipo del proyecto para evaluar el software
existente en la empresa. 
Un equipo de 12 profesionales de sistemas utiliza el modelo ISO 9126 para llevar a
cabo la auditoría. 

Se evaluarán los siguientes aspectos:

1-       Funcionalidad  (aptitud, precisión, interoperatividad, conformidad y seguridad)
2-       fiabilidad  (madurez, tolerante a fallos y recuperabilidad)
3-       usabilidad (comprensibilidad, facilidad de aprendizaje y operatividad)
4-       eficiencia  (respecto al tiempo y respecto a los recursos)
5-       mantenibilidad  (facilidad de análisis, facilidad de cambio, estabilidad y
facilidad de prueba)
6-       portabilidad  (adaptabilidad, facilidad de instalación, conformidad y
reemplazabilidad)

Se auditará la aplicación correspondiente al “Proceso de Elaboración del Acero”

Caso 8

En una “Editorial”  se llevó a cabo la “Auditoría de la Seguridad Física del Software”,

la cual es utilizada por el equipo del proyecto para evaluar las diversas amenazas
que se pueden producir y sus respectivas consecuencias a nivel software.

Un equipo de profesionales de sistemas evaluará los siguientes aspectos:

1-   amenazas que pueden provocar un daño o pérdida en el software existente
(incendio, inundación, derrumbamiento, accidentes de distinto tipo, explosiones,
averías, etc)
2-   protección de los soportes magnéticos en cuanto a acceso, almacenamiento y
transporte

 Se observa que:

-   La empresa cuenta con pocos matafuegos y el personal, en general, no realiza
copias de resguardo de los sistemas existentes.
- Algunos objetos de esta “Editorial” no están asegurados.

Caso  9

En una “Empresa de Capacitación Ejecutiva”  se llevó a cabo la “Auditoría de la

Seguridad Física del Hardware”, la cual es utilizada por el equipo del proyecto para
evaluar las diversas amenazas que se pueden producir y sus respectivas
consecuencias a nivel hardware. 

Un equipo de profesionales de sistemas evaluará los siguientes aspectos:

1-       amenazas que pueden provocar un daño o pérdida en el hardware existente
(incendio, inundación, derrumbamiento, accidentes de distinto tipo, explosiones,
averías, etc)
2-       ubicación del centro de procesos, de los servidores locales y de las terminales
 Se observa que:
-    La empresa cuenta con matafuegos y salidas de emergencia.
- Algunos productos de hardware de esta “Empresa de Capacitación Ejecutiva” no
están asegurados.

Caso 10

En un “Shopping”  se llevó a cabo la “Auditoría de la Seguridad Lógica”, la cual es

utilizada por el equipo del proyecto para evaluar el acceso de los usuarios al
“Sistema de Facturación”. 

Un equipo de profesionales de sistemas evaluará el acceso a los recursos por medio

de una matriz de accesos tridimensional que abarca los siguientes aspectos:
1-       grupos de usuarios que acceden al “Sistema de Facturación”
2-       las tablas que se utilizan en dicho sistema
3-       las operaciones que se realizan en dichas tablas (lectura, modificación,
borrado, ejecución, etc) 

Se observa que:
-    La empresa, periódicamente, lleva a cabo un proceso de autenticación, en el cual
se revisa cómo se identifican y autentican los usuarios, cómo han sido autorizados
y por quién, y qué ocurre cuando se producen intentos o transgresiones: quién se
entera y cuándo y qué se hace.
- El sistema de vigencia de usuarios esta al día

Caso 11

En una “Empresa Textil”  se llevó a cabo la “Auditoría de un Plan de Contingencia”,

la cual es utilizada por el equipo del proyecto para que exista una continuidad en
las operaciones que se realizan por medio del “Sistema de Producción”.

 Se observa que:

-  El equipo de sistemas cuenta con algunas copias actualizadas de las aplicaciones y
de la base de datos correspondientes al Sistema de Producción
- Se tiene el software necesario para una posible re-instalación de los productos
- La empresa, hasta el momento, no puso en marcha ningún “Plan de Contingencia”.   

Caso 12

En una “Empresa de Medicina prepaga”  se llevó a cabo la “Auditoría de una Red

Fïsica”, la cual es utilizada por el área de sistemas para evaluar la red que posee la
empresa, ya que se tienen terminales conectadas a los principales laboratorios
proveedores que suministran los medicamentos. 

Se observa lo siguiente:
-   en c/ centro de atención, los servidores están al acceso de cualquier persona
perteneciente al área de sistemas
- las líneas de comunicaciones están a la vista de todos, y en algunos casos,
impiden el normal transitar de las personas 

Caso 13

En una “Agencia de Turismo”  se llevó a cabo la “Auditoría de una WEB”, la cual es

utilizada por el área de sistemas  para evaluar la situación de la empresa teniendo
en cuenta la cantidad de usuarios que visitaron la página, cómo influyó eso en la
facturación y en determinar si se debe o no cambiar la estrategia de marketing
existente en la empresa.

Se observa lo siguiente:
-  parte del contenido de la página cambia cada 15 días
-   se puede acceder sin ningún tipo de restricción
- el diseño navegacional de la página es amigable al usuario 

Caso 14

En una “Línea Aerea”  se llevó a cabo la “Auditoría de un Datawarehousing”, el cual

es utilizado por las Gerencias Intermedias y la Alta Dirección para la toma de
decisiones. Esta BD analítica cuenta con información resumida (datos mensuales,
semestrales y/o anuales) referente a “Facturación”, “Clientes” y “Viajes” 

Se observa lo siguiente:
- es muy lenta la migración de los datos que se realiza de la BD operativa a la BD
analítica 
-   no existe información sobre los “Competidores”. Esta información ayudaría a la
mejora de los procesos de negocio de la empresa
- no existe documentación referente a cuándo y quién llevó a cabo la migración de
datos  

Caso 15

En un “Laboratorio de Medicamentos”  se llevó a cabo la “Auditoría de la

Documentación”, la cual es utilizada por el área de Sistemas para controlar el
cumplimiento del desarrollo de los sistemas.

 Se observa lo siguiente:

-  en las distintas etapas de desarrollo, la documentación está incompleta  
-  ciertos datos de los documentos no se corresponden con la realidad, es decir que
la documentación no fue actualizada 
- no se especifica quién llevó a cabo la documentación
-   no existe un lugar o acceso directo en el que cualquier persona autorizada pueda
acceder a la documentación de un sistema determinado
- no hay un formato determinado de documentación para cada etapa de
desarrollo   

Caso 16

En una “Empresa de Publicidad”  se llevó a cabo la “Auditoría de los Tiempos y

Costos”, la cual es utilizada por el área de Sistemas para controlar el cumplimiento
de los tiempos y costos estimados para el desarrollo de los sistemas. 

Se observa lo siguiente:
-   no existe información detallada por etapa respecto a los costos y tiempos
respectivos   
- no se detalla quién es el responsable de ciertos gastos extras llevados a cabo en
algunas etapas  
-   el tiempo planificado de cada etapa no coincide con los hechos sucedidos 
- el tiempo asignado a c/ miembro del equipo de desarrollo no se corresponde a la tarea llevada a cabo 

Caso 17
En una “Empresa Automotriz”  se llevó a cabo la “Auditoría de una BPR”, la cual es
utilizada por el área de Sistemas y por la Alta Dirección para controlar el
cumplimiento de este tipo de proyecto. La empresa cuenta con equipos
mainframes, los cuales serán reemplazados por Servers que estarán distribuidos
según las distintas áreas de la empresa. Se realizará un nuevo planteo de todas las
aplicaciones existentes.

Se observa lo siguiente:
- determinados procesos de negocio de la empresa no fueron cambiados en un
100%    
- el personal, en su totalidad, no estaba capacitado para llevar a cabo este cambio
tecnológico
- sería necesario re-definir los roles y responsabilidades de todas las personas que
intervienen en el proyecto

Caso 18

En una “Consultora de Sistemas”  se llevó a cabo la “Auditoría de una Gestión”, la

cual es utilizada por las Gerencias Intermedias y por la Alta Dirección para la toma
de decisiones. 

 Se observa lo siguiente:

- no se especifican los objetivos particulares que se alcanzaron
- casi no existe documentación de las distintas cosas que se realizaron
- no está bien especificado quién es responsable de c/ objetivo particular que se
cumplió

Caso 19

En una “Empresa textil”  se llevó a cabo la “Auditoría de un Relevamiento”,

perteneciente al “Sistema de Proveedores”,  la cual es utilizada por la  Gerencia de
Sistemas para el control del proceso de desarrollo de software.  

Se observa lo siguiente:
- No son claras las preguntas que se formulan
- No se establece ninguna vinculación entre el Sistema de Proveedores y el resto de
los sistemas existentes
- No está especificado quién y cuándo se llevó a cabo la entrevista
- No existen informes respecto de las entrevistas  realizadas

Caso 20

En una AFJP  se llevó a cabo la “Auditoría de un CASE”, el cual es utilizado por el

equipo de desarrollo solamente en las etapas de análisis y diseño de sistemas. 

Se tiene una Base de Datos SyBase que no guarda ninguna relación con la
herramienta, ya que no se posee un repositorio que almacene los objetos que se
generan en las etapas mencionadas anteriormente. Esta herramienta permite
definir, lógicamente, todo lo que se necesita en el análisis y diseño de un sistema;
y generar la documentación correspondiente. 

Se observa que:
- el personal no fue capacitado en el uso de la herramienta
- esta herramienta no es utilizada por todos los equipos de desarrollo de la empresa
-la herramienta no es utilizada en un 100% para así obtener mejores resultados
- en algunos casos, la herramienta no se ajusta a las necesidades de la empresa