Informe de la auditoria

 

Informe de Auditoría

Introducción

"Es un medio formal para comunicar los objetivos de la Auditoria , 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 desfavorable: es aplicable en el caso de identificación de irregularidades 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 limitaciones 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 orientan 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 actual	Comentario	Comentario de la 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 permitan mejorar el performance del sistema	Crear los índices que correspondan de acuerdo con las aplicaciones que fueron desarrolladas.	De acuerdo (Sr. Gte de Sistemas)
Se realiza una copia diaria de resguardo (backup)	Debido al caudal de información que maneja la empresa, se sugiere realizar 2 backups diarios, uno a mitad del día y otro al final del día.	De acuerdo (Sr. Gte de Sistemas)

 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