Auditoria Informatica Modulo 2 %28pdf%29

2. DESARROLLO GENERAL DE UNA AUDITORÍA.

PROCESOS, METODOLOGÍAS,

TÉCNICAS Y TECNOLOGÍAS

Objetivos

El objetivo principal del tema es el estudio de los conceptos fundamentales asocia-dos al desarrollo general de una auditoría, las descripción de sus etapas, puntos de decisión y resultados finales de cada etapa de la auditoría.

El objetivo principal del capítulo es la presentación de las herramientas que tiene a su alcance el auditor para facilitarle su trabajo. Como el examen de los sistemas de control y de información que realiza el auditor tiene muchos aspectos y de distinta naturaleza, así las herramientas que utiliza pueden ser de distinto tipo. La obtención de información fiable y que proporcione confianza al auditor es una de las premisas para que cada una de las herramientas sea útil.

2

2 AUDITORÍA INFORMÁTICA (ITIG)

2.1 Introducción

En primer lugar estudiaremos los aspectos relacionados con la dirección de auditorías. Después abordaremos el proceso general de una auditoría. Y luego trata-remos los resultados de la auditoria.

En la Auditoría tenemos, por orden de mayor importancia y generalidad, las nor-mas, los procedimientos, las técnicas y las herramientas. El auditor, en el desarrollo de su labor, ha de realizar su examen conforme a las normas técnicas, oficiales o generalmente reconocidas, como reglas técnicas y éticas. En el estudio de los dis-tintos aspectos del sistema que está auditando, tiene que aplicar los procedimientos de auditoría, que son las descripciones de los pasos que tiene que seguir para llevar a cabo con éxito su investigación. Según la naturaleza del sistema o de la auditoría, el auditor tiene a su disposición una serie de técnicas, que le ofrecen diversas alter-nativas contrastadas en la evaluación de elementos específicos del sistema a audi-tar. Sin embargo, el auditor, solamente con su intelecto y sus manos, no puede lle-gar muy lejos en la obtención y elaboración de la información, y sobre todo cuando el entorno es muy especializado. Entonces, le hace falta un conjunto de herramien-tas que le facilite su labor y le ayude a obtener datos con mayor precisión y fiabili-dad.

Los métodos es el conjunto de principios, reglas y prácticas que suministran la forma de desarrollar técnicamente (el cómo) la auditoría

Las metodologías son los sistemas estructurados y organizados de principios, reglas y prácticas que se aplican a ramas del conocimiento específicas.

Las herramientas es el conjunto de los el elementos que, mediante la estruc-turación, clasificación y automatización de determinados procedimientos de inge-niería y diseño, facilitan el trabajo del ingeniero al descargarle de tareas rutinarias, repetitivas o extremadamente exhaustivas, y permitirle centrarse en aspectos cuali-tativos o fundamentales. Suministran en resumen un soporte automático o semiau-tomático a los métodos.

Los procedimientos es el conjunto de facilidades que integran métodos y herramientas en unidades metodológicas operativas. Entre otras cosas, estas unida-des definen las secuencias de aplicación de los métodos; describen y establecen los resultados de la culminación de cada etapa de aplicación de los métodos, denomi-nadas entregas (documentos, informes, diagramas, etc.); definen los controles para asegurar la calidad y gestionar los cambios; y establecen las directrices que ayudan a los gestores del ámbito técnico en particular en la evaluación del progreso en el desarrollo de sus actividades.

CAPÍTULO 2 3

Una herramienta de auditoría, se puede definir como el elemento que, median-

te la estructuración, clasificación y automatización de determinados procedimien-tos de auditoría, facilita el trabajo del auditor al descargarle de tareas rutinarias, repetitivas o extremadamente exhaustivas, y permitirle centrarse en aspectos cuali-tativos o fundamentales.

Las herramientas de auditoría pueden ser de muchos tipos y presentarse en di-versos soportes materiales, así como ser muy sencillas o bastante complicadas en su utilización. También hay herramientas más tradicionales y herramientas alta-mente innovadoras y especializadas, según el grado de tecnología introducido en el sistema auditado. Sea cual sea la naturaleza de la herramienta, el auditor que la necesite debe conocer a fondo su manejo y aplicación. Esto significa que, para cualquier herramienta, el auditor debe recibir la formación pertinente antes de po-der utilizarla.

Por otra parte, hay herramientas que son generales, es decir, que se pueden aplicar en otro tipo de actividades distintas de la auditoría, y hay herramientas que son específicas de la auditoría.

3.2 Proceso y Dirección de una Auditoría de Sistemas de Informa-ción

Resulta una experiencia incomparable el llevar a cabo la Auditoría de Sistemas de Información de una instalación que tenga más de 100 programadores y analistas, un gran ordenador, y miles de ficheros o tablas de Base de Datos. Obviamente, no todas las instalaciones de proceso de datos son de este tamaño. Sin embargo, inclu-so en la instalación más pequeña, es normalmente imposible para el auditor llevar a cabo una revisión detallada de todo el proceso de datos que se lleva a cabo en la instalación. De modo que: ¿ Cómo puede la Auditoría de Sistemas de Información realizarse de modo que el Auditor obtenga una garantía razonable de que la instala-ción tiene salvaguardados sus activos de proceso de datos, mantiene la integridad de datos y de que los sistemas alcanzan la efectividad y eficiencia esperados ?.

En esta sección proporcionaremos una visión global del enfoque utilizado para llevar a cabo una Auditoría de Sistemas de Información. En primer lugar, describi-remos algunas técnicas para simplificar y poner en orden la complejidad a la que se enfrentan los auditores cuando realizan juicios de evaluación sobre sistemas.

A continuación examinaremos los efectos de un sistema de control interno en el entorno de auditoría, después discutiremos la relación entre las pérdidas espera-


das, errores e irregularidades. También discutiremos la naturaleza de los controles informáticos, para a continuación dar una visión de los pasos en una ASI, y final-mente describir algunas de las decisiones más importantes al llevar a cabo una ASI.

3.2.1 La gestión y organización de la Función de Auditoría de Sistemas de Información

El auditor es un profesional que realiza su trabajo de forma muy distinta a otras profesiones u otros oficios que son individualistas y poco formalizados. Las auditorías no se realizan por inspiración divina ni terrena, ni se crean de la nada. El auditor es una persona que tiene tras de sí un conjunto de personas que le supervi-san, asesoran, organizan, dirigen o ayudan, así como puede, a su vez, ejercer estas funciones sobre otros empleados. Para realizar una auditoría necesita de una serie de recursos y que le proporcionen un conjunto de informaciones y documentación. El auditor, en resumen, materializa e instancia la función de auditoría.

La función de auditoría, como tal función, debe estar apoyada por una estruc-tura organizada de profesionales y, además, gestionada por los mismos profesiona-les. También puede estar inmersa en el conjunto de funciones de una empresa, co-mo función de auditoría interna.

Por otra parte, la función de auditoría del Proceso Electrónico de Datos es una parte integral de la función de auditoría global [31], aunque ha emergido con tal fuerza que se diferencia sensiblemente del resto de funciones de auditoría.

En esta sección vamos a tratar de varios aspectos relacionados con la función de auditoría de Proceso Electrónico de Datos: Necesidad e Independencia, Organi-zación, Composición, Relaciones con la dirección y otras organizaciones, Equipo de auditoría y Gestión.

3.2.1.1 Consideraciones iniciales

La necesidad de tener una sección de auditoría de Proceso Electrónico de Datos en las empresas de auditoría, dentro de la organización general pero con entidad pro-pia, se justifica por razones de competencia técnica, incremento de independencia basado en la competencia técnica informática, y mejores y más fluidas relaciones entre la dirección de auditoría y la dirección de proceso de datos en base a la com-petencia técnica.

La agrupación de auditores especialistas en Proceso Electrónico de Datos en una unidad con entidad propia, proporciona un nivel de independencia mayor con

CAPÍTULO 2 5

respecto del grupo de auditoría en base al mayor conocimiento técnico en Proceso Electrónico de Datos, tanto de cada uno de los componentes, como del grupo como unidad funcional.

3.2.1.2 Organización de la Función de Auditoría

La unidad funcional de auditoría de Proceso Electrónico de Datos puede integrarse en la organización de auditoría de dos formas distintas, en función de la naturaleza de las auditorías realizadas y de otras consideraciones postuladas por los teóricos: puede estar como función de staff, asesorando a la dirección de auditoría en mate-rias técnicas de su competencia (ver la Figura 3.1); o puede estar como función en línea, como parte integral del equipo de auditoría y con las responsabilidades técni-cas correspondientes en la realización de la auditoría (ver la Figura 3.2).

Jefe deAuditoría

1

Jefe Aud.Equipo 1

2

Jefe Aud.Equipo 2

3

Jefe Aud.PED

4

AuditorStaff Gral

5

AuditorStaff Gral

6

Auditor InfEspecialista

7


8

Figura 3.1. La auditoría de PED como función de Staff [Weber]


Jefe deAuditoría

1

Jefe Aud.Equipo 1

2

Jefe Aud.Equipo 2

3

AuditorStaff Gral

5

AuditorStaff Gral

6


7


8

Jefe Aud.Equipo3

3

AuditorStaff Gral

5

Figura 3.2. La auditoría de PEd como función de línea [Weber]

Los argumentos que justifican la función de auditoría como función de staff son los siguientes:

1) Utilización más eficiente de los recursos de auditoría de Proceso Electrónico de Datos.

2) Mayor satisfacción laboral del auditor de Proceso Electrónico de Datos.

3) Mayor compromiso de la organización hacia la función de auditoría de Proceso Electrónico de Datos.

4) Facilidad de coordinación y control.

5) Permite el incremento de la especialización para cubrir las tecnologías complejas.

Los argumentos que justifican la función de auditoría como función en línea son los siguientes:

1) Mayor congruencia en los objetivos.

2) Facilidad en la comunicación.

3) Mejora el conocimiento y experiencia en Proceso Electrónico de Datos de la dirección de auditoría en cada equipo.

CAPÍTULO 2 7

3.2.1.3 Composición y gestión de la Función de Auditoría de Sistemas de Información

No hay ninguna fórmula que determine cuantos auditores de sistemas de informa-ción deben componer una unidad funcional. Además, este número puede variar en función de las necesidades temporales de la organización de auditoría.

En grupos de auditoría interna, el número de auditores de sistemas de infor-mación se puede fijar en base a los factores siguientes: tamaño de la organización, naturaleza de la organización, extensión del uso de sistemas de información, tipos de sistemas informáticos instalados, y estabilidad del entorno de Proceso Electróni-co de Datos.

En grupos de auditoría externa, el número de auditores de sistemas de infor-mación está en función del número de clientes con instalaciones informáticas y de la complejidad del proceso de datos realizado en las mismas.

El origen de los auditores de sistemas de información suele ser de dos tipos: auditores de empresa o profesionales de proceso de datos. La elección de uno de los tipos y su posterior formación puede realizarse en función de qué tipo de cono-cimiento es más difícil de adquirir (auditoría o proceso de datos) a la hora de abor-dar determinado tipo de auditorías. La formación de los auditores de Sistemas de información la hemos tratado con bastante extensión en una sección anterior.

Por otra parte, se puede producir una evolución del auditor de Sistemas de in-formación hacia otras funciones por diversos caminos: función de especialista en el Sistemas de información, función de auditor, función operativa[10].

3.2.1.4 Relaciones con la dirección y con otros grupos

Uno de los objetivos fundamentales de la unidad funcional de auditoría de Sistemas de información es el establecimiento de relaciones cordiales con los diversos esta-mentos de gestión dentro de la organización, sobre todo cuando se trata de audito-ría interna. Sin embargo, dada la naturaleza de la auditoría interna, que ejerce un control de las actividades y gestiones llevadas a cabo por sus interlocutores, surgen a menudo problemas en las relaciones con dichos estamentos de gestión: presiones de la dirección para actuar con demasiada rapidez, problemas de comunicación con la organización y fricciones con otros grupos.

Se puede aplicar algunas soluciones para paliar dichos problemas: promoción de comunicaciones abiertas entre las partes en conflicto, auditoría en base a la ca-pacitación técnica, asignación de prioridad a las tareas que se pueden cumplir, y gestión adecuada de la función de auditoría de Sistemas de información.


3.2.1.5 El equipo de auditoría

El equipo de auditoría se debe crear en base a los perfiles de auditor requeridos para cada tipo de misión y en base a la naturaleza de las tareas que debe realizar este equipo. La organización del equipo de auditoría debe atender a las capacidades técnicas y experiencia de cada uno de los miembros. La dirección del equipo es asumida por el auditor con más experiencia y más preparado en tareas de organiza-ción y gestión. Las tareas complejas y sofisticadas las pueden asumir auditores especialistas con experiencia. Y finalmente, los auditores principiantes o con poca experiencia, desarrollan las tareas de más baja responsabilidad. Estas posiciones pueden variar a medida que los auditores van adquiriendo conocimientos y expe-riencia en su entorno profesional.

En el control de los equipos se aplican las metodologías y técnicas de gestión necesarias, así como las herramientas hardware y software especializadas. En gene-ral, no hay que confundir el equipo de auditoría de Sistemas de información con la unidad funcional de auditoría de Sistemas de información. En el equipo de audito-ría se integran los miembros en función de su perfil y de la misión concreta a reali-zar, con una duración temporal determinada por el cumplimiento de la misión. En la unidad funcional se integran los miembros en función de su especialización y con un cariz de permanencia.

3.2.2 Técnicas

Se describen algunas técnicas para simplificar y prevenir de la complejidad con la que se enfrentan los auditores al evaluar y juzgar un sistema informático.

3.2.2.1 El tratamiento de la complejidad

La dirección de una ASI es un ejercicio complicado. Han de seguirse unos pasos:

1. Dados los objetivos de la Auditoría, dividir el sistema a ser evaluado en subsistemas.

2. Identificar los componentes que desarrollan las actividades básicas en cada subsistema.

3. Evaluar la fiabilidad con la que cada componente ejecuta sus actividades.

CAPÍTULO 2 9

4. Determinar la corrección con la que cada subsistema se ejecuta y

las implicaciones de cada uno de ellos sobre los demás niveles en el sistema.

3.2.2.2 Descomposición del subsistema

El primer paso a dar es descomponer el sistema a evaluar en subsistemas. Un sub-sistema es una unidad con la que el sistema que lleva a cabo esa función básica, necesita de todo el sistema para conseguir sus objetivos fundamentales.

El proceso de descomponer un sistema en subsistemas se denomina factoriza-ción ("factoring"). Es un proceso iterativo que finaliza cuando los auditores creen que el sistema está lo suficientemente dividido como para poder ser entendido y evaluado. Es decir, cada subsistema está descompuesto en sus subsistemas consti-tuyentes, los cuales a su vez están descompuestos hasta que los auditores entienden suficientemente el subsistema que están tratando.

Deben tenerse en cuenta algunos aspectos antes de comenzar el proceso de descomposición:

• La función que realiza: Las diferentes funciones determinan subsistemas. Los auditores deben fijarse en las funciones fundamentales que ha de desarrollar el sistema para conseguir sus objetivos. En base a esto, debemos tener en cuenta que:

• Cada subsistema debe ser independiente de los demás.

• Cada subsistema debe ser internamente cohesivo en el que todas las actividades que desarrolla el subsistema están diseñadas pa-ra esa función.

Desde el punto de vista de una auditoría, los subsistemas son difíciles de entender y su corrección es complicada de evaluar a menos que presenten estas características.

• Se deben evaluar además el grado de relación y cohesión de los subsistemas entre ellos.

• Al menos conceptualmente, los auditores deben factorizar los sistemas en diferentes modos. Se han utilizado generalmente en la dirección de una ASI dos formas diferentes:

1. Una de ellas relacionada con las funciones administrativas ne-cesarias para cumplir el proceso de información.


2. La segunda está en relación con las funciones de aplicación ne-cesarias para cumplir el proceso de información.

3.2.2.3 El subsistema de dirección

La ASI trata de conseguir que el desarrollo, la implementación, la ejecución, y el mantenimiento de los sistemas informáticos se lleve a cabo de manera planificada y de forma controlada.

Se ocupa de dotar de un entorno estable, en el cual se construyen y se ejecutan los sistemas de información sobre las bases del día a día. Algunos niveles del sub-sistema de dirección se han identificado correspondiéndose con la jerarquía de la organización y las principales funciones que se llevan a cabo dentro de la instala-ción de proceso de datos. (ver Figura 3.3)

CAPÍTULO 2 11

Tala 2.3. Descomposición del Subsistema de Dirección

SUBSISTEMA DE DIRECCIÓN DESCRIPCIÓN DEL SUBSISTEMA

Alta Dirección La alta dirección de la organización debe asegurarse de que la instalación de proceso de datos está correc-tamente dirigida. Es el responsable de una política de decisiones a largo plazo sobre cómo van a utilizarse los ordenadores y sistemas de información en la orga-nización.

Dirección de Proceso de Datos. La dirección de Proceso de Datos tiene la responsabi-lidad global de planificar y controlar todas las activi-dades informáticas. Además proporciona las “entra-das” de la política de decisiones a largo plazo de la alta dirección y traduce las políticas a largo plazo en obje-tivos a corto plazo.

Desarrollo de sistemas (Systems Devel-opment Management)

Responsable del diseño , de la implementación y del mantenimiento de las aplicaciones y de los sistemas de información.

Programadores Responsables de programar nuevos sistemas mante-niendo los actuales y proporcionando a los sistemas el adecuado soporte software.

Administración de datos Responsable del control y uso de la información, incluyendo Bases de Datos y sistemas de ficheros.

Dirección de seguridad Responsable de la seguridad física de la instalación de proceso de datos.

Dirección de explotación Controla diariamente las operaciones del sistema de proceso de datos. Responsable de preparar la informa-ción, de la información que fluye a través de la insta-lación, de los sistemas de producción, del manteni-miento del hardware y en algunos casos del manteni-miento de programas y librerías de facilidades.


ALTA DIRECCIÓN DIRECCIÓN EDP

Dirección de desarrollo de sistemasDirección de Programación

Administración de Información

Administración de SeguridadDirección de Explotación

APLICACIÓN CONTROL SISTEMA

Figura 3.5. Estructura de Control del Subsistema de Dirección

El control es como las capas de una cebolla, cuyas capas están alrededor de las aplicaciones de control:

El subsistema de aplicación es a su vez dividido en subsistemas que incluyen:

Tabla 3.6. Niveles del Sistema en un proceso de transacciones

SUBSISTEMAS DE APLICACIÓN

DESCRIPCIÓN DE LOS SUBSISTEMAS

Frontera Comprende los componentes que establecen la interface entre el usuario y el sistema.

Entrada Comprende los componentes que captura, prepara e intro-ducen información en el sistema.

Comunicación Comprende los componentes que trasmiten información a todos los subsistemas en el sistema y entre un sistema y otro sistema.

Proceso. Comprende los componentes que llevan a cabo la compu-tación, la clasificación, la ordenación y la conclusión de la información en el sistema.

Base de Datos. Comprende los componentes que definen, añaden, acce-den, modifican y borran información en el sistema.

Salida Comprende los componentes que recuperan y presentan la información a los usuarios del sistema.

CAPÍTULO 2 13

P r

Subs i s t ema de ap l i cac ión

Apl i cac ión de l s i s t ema

C i c l o

P r o c e s o d e d a t o s

Figura 3.7. Niveles del Sistema en un proceso de transacciones

3.2.2.4 Identificación de componentes

Las funciones del subsistema son ejecutadas vía componentes, que serían las uni-dades físicas que llevan a cabo las actividades básicas. Los auditores “deducen” como funciona un subsistema determinando sus componentes, las actividades que realiza cada componente y las relaciones entre los componentes.

La identificación de componentes suele ir acompañada de una identificación del subsistema. Hay dos razones:

1. Mientras los subsistemas se mantienen o suelen mantenerse, los componentes cambian continuamente.

2. Los auditores parecen entender mejor los sistemas si inicialmente se centran en los subsistemas antes que en los componentes para tener una visión global del sistema.

Los subsistemas presentan tres características:

1. Han de estar organizados jerárquicamente.

2. Han de ser independientes (frente a otros subsistemas).

3. Han de ser coherentes.


Pero identificar claramente los componentes en un subsistema no es fácil, por-que no está clara la diferencia entre subsistemas y componentes. Un subsistema puede usar varios componentes, y un componente puede servir a varios sistemas. Sin embargo los auditores deben diferenciar entre componentes y subsistemas en cada caso ya que finalmente tendrán que enjuiciar el correcto funcionamiento de los componentes de un subsistema para comprobar que realizan correctamente la función de dicho subsistema.

3.2.2.3 Fiabilidad de los componentes

Un sistema alcanza sus objetivos de la salvaguarda de activos, de mantener la inte-gridad de los datos, y de tener un sistema eficaz y eficiente si cada uno de sus sub-sistemas es fiable. Un subsistema es fiable si los componentes que desarrollan las actividades en el subsistema lo son. Una vez los componentes han sido identifica-dos, los auditores deben evaluar su fiabilidad respecto a cada tipo de error o irregu-laridad que suele ocurrir.

La fiabilidad de un componente es una función de los controles que actúan en dicho componente. Un control es una muestra de actividades o acciones ejecuta-das por más de un componente para prevenir, detectar o corregir errores o irregula-ridades que afectan a la fiabilidad de un componente. Además los componentes deben controlarse ellos mismos o sobre otros componentes. El conjunto de todas las actividades de control llevadas a cabo en un sistema constituyen el subsistema de control dentro del sistema. Su función es establecer, ejecutar, modificar y man-tener actividades de control de modo que la fiabilidad global del sistema sea acep-table.

Algunos de los controles más importantes que deben evaluarse son los si-guientes:

1. Controles de autenticidad: Para verificar la identidad de un usuario o proceso que quiera tomar alguna acción en el sistema. Ejemplo: passwords, números de identificación personal (PIN: Personal Identification Number), etc.

2. Controles de precisión: Para asegurar la corrección de la información y procesos en el sistema. Ejemplo: un programa o rutina que valide que el contenido de un campo contiene únicamente números.

CAPÍTULO 2 15

3. Controles de completitud: Asegurarse de que no hay pérdida de

información y que todo proceso llega a su adecuada conclusión. Ejemplo: no hay dos campos vacíos, etc.

4. Controles de redundancia: Para asegurar que la información es procesada una sola vez.

5. Controles de privacidad: La información está protegida contra accesos no autorizados.

6. Controles de auditoría (Audit trail controls): Tratan de asegurar que queden registrados cronológicamente todos los eventos que ocurren en el sistema. Este registro es muy importante para responder preguntas, determinar irregularidades, detectar las consecuencias de un error etc. Deben mantenerse dos tipos de auditoría, la auditoría de cuentas y la auditoría de operaciones.

7. Controles de existencia: Que aseguren la continua disponibilidad de todos los recursos y datos del sistema.

8. Controles de salvaguarda de activos: Para asegurar que todos los recursos dentro del sistema están protegidos de la destrucción o corrupción. Ejemplo: extintores, contraseñas, etc.

9. Controles de eficacia: Asegurar que el sistema alcanza sus objetivos.

10. Controles de eficiencia: Asegurar que el sistema utiliza el mínimo número de recursos para conseguir sus objetivos.

Cada tipo de control normalmente aparece en cada subsistema. Además estos tipos de control no son mutuamente excluyentes. Un control puede partic ipar en varias categorías.

Al evaluarse los efectos de un control sobre la fiabilidad de un componente, se consideran varios atributos del control:

• La búsqueda del tipo de control adecuado, dada la naturaleza del proceso de actividades depende del sistema. Además algunas veces el controlar algún tipo de error o irregularidad es mucho más caro que las pérdidas que estos producen.

• Un atributo a considerar cuando se evalúa la efectividad del control es si el control previene, detecta o corrige errores.


• Otro atributo a tener en cuenta es el número de componentes necesarias para realizar el control.

• Finalmente han de considerarse el número de subsistemas afectados por el control. Esta función comprueba si se trata de una componente compartida, es decir, que realiza actividades en varios subsistemas. Generalmente el control sobre componentes compartidos necesita ser más fiable y consecuentemente más complicado.

3.2.2.4 Evaluación de la fiabilidad del sistema

Es el proceso de emitir juicios fiables a medida que el auditor evalúa la jerarquía del sistema partiendo de los niveles inferiores hacia los niveles superiores.

Si el Auditor participa en la fase de diseño produce los efectos siguientes (ver la Figura 3.8):

1. Aumenta el conocimiento técnico de proceso de datos.

2. Asigna auditores diferentes para diseñar la fase de auditoría y revisión posterior.

3. Reunir a los auditores con más experiencia en proceso de datos.

4. Establecer una sección de proceso de datos en el departamento de auditoría interna, especializado en ASI.

5. Alcanzar un elevado nivel de soporte de la alta dirección.

CAPÍTULO 2 17

ANÁLISIS DISEÑO IMPLEMENTACIÓN EJECUCIÓN REVISIÓN

Tiempo

Posible participación del auditor

Figura 3.8. Participación del auditor en el ciclo de vida de los sistemas

3.3.2.5 Utilización de computadores en una auditoría

Es otra de las decisiones que deben tomarse al planificar una auditoría.

Auditoría alrededor del computador (Auditing around the computer)

Se ve al ordenador como una caja negra. Este enfoque es tanto más habitual cuanto más se dan las siguientes premisas:

1. El sistema es simple y el procesamiento es orientado por lotes.

2. El sistema utiliza software general que se utiliza en muchas instalaciones.

Como vemos, este tipo de sistemas informáticos donde puede aplicarse este enfoque es muy restrictivo.

Auditoría a través del ordenador (Auditing through the computer)

Puede utilizarse el ordenador para realizar pruebas.

1. A la lógica y controles existentes en el sistema.


2. A los registros producidos por el sistema.

Dependiendo de la complejidad del sistema de aplicación que está siendo au-ditado, el enfoque puede ser simple o necesitar competencias y conocimientos téc-nicos por parte del auditor.

Normalmente este tipo se utiliza en las circunstancias y sistemas siguientes:

1. Sistemas de aplicación que procesan un gran volumen de información (entradas) y producen una gran cantidad de resultados (salidas), lo que hace que sea muy complicada la validación de entrada y salida de datos.

2. Cuando partes significativas del sistema de control interno están incluidas en el sistema informático.

3. Cuando la lógica del sistema es complicada y hay grandes partes que facilitan el uso del sistema.

4. Cuando a causa de consideraciones de coste-beneficio, hay huecos importantes en el transcurso de la auditoría.

Cuando se aplica este enfoque requiere expertos técnicos e implica alto coste. Sin embargo estas desventajas son aparentes cuando este enfoque es el único méto-do viable para realizar la auditoría.

3.3.2.6 Selección de los sistemas de aplicación para la auditoría (Selecting Applica-tion Systems for Audit)

Por regla general deben seleccionarse para la auditoría aquellos sistemas de aplica-ción más críticos para la continuidad de la existencia de la organización. Han de seleccionarse aquellos sistemas de aplicación de los cuales se obtienen mejores resultados para la organización auditada y que, consecuentemente, la pondrían en graves aprietos si fallaran o funcionasen incorrectamente.

A menudo, una forma de descubrir en qué sistemas de aplicación existen pro-blemas, es realizando una auditoría de usuario. Cuando un sistema de aplicación no funciona bien, son los usuarios los afectados. Los usuarios aportan información sobre los problemas que les han ocurrido. Es necesario investigar el entorno del usuario. Algunas veces un problema en el sistema de aplicación puede transmitir sus efectos sobre la calidad del trabajo cotidiano de los usuarios. Esto conduce a unos problemas que influyen en la integridad de los datos, en la eficacia y eficien-cia del sistema.

CAPÍTULO 2 19

La auditoría de usuario puede realizarse formal o informalmente. Sin embargo,

en ambos casos, necesita estar planificada y los resultados bien documentados.

3.3.2.7 Conclusión

Tanto el proceso como la dirección de una ASI son complicados. Para enfrentarse con esta complejidad es necesario factorizar el sistema que va a ser evaluado en subsistemas, identificar los componentes que desarrollan las actividades básicas en cada subsistema, evaluar la fiabilidad de cada componente, evaluar la fiabilidad de los subsistemas y progresivamente emitir juicios sobre cada subsistema para llegar a emitir una valoración global acerca de la fiabilidad del sistema.

Las fases de que consta una Auditoría de Sistemas de Información son simila-res a las fases que componen una auditoría de un sistema manual.

Primero, se realiza un análisis preliminar de la instalación informática para ob-tener una idea de cómo está administrada la instalación y cómo se procesan los principales sistemas de aplicación.

En segundo lugar, si se cuenta con un sistema de control interno, se realiza un análisis detallado. Seguidamente se realizan pruebas de fiabilidad a controles que la auditoría considera críticos, a continuación se llevan a cabo las pruebas substanti-vas. Finalmente debe emitirse una valoración. Después de todos los pasos el audi-tor evalúa el sistema de control interno y decide si sigue con la auditoría o seguir por otro camino.

Desde el principio la ASI debe asumir y tomar varias decisiones complicadas. Cada evaluación de la fiabilidad de un sistema de control interno requiere una compleja evaluación por etapas. Debe decidirse sobre la fase de diseño. Debe reali-zarse una evaluación cuidadosa. Deben seleccionarse los sistemas críticos en los cuales debe centrarse la auditoría.

3.2.3 Pautas de selección para la elección de un sistema de aplicación específico para una auditoría

En la Figura 3.9 podemos apreciar las pautas de selección para la elección de un sistema de aplicación específico para una auditoría.


Tabla 3.9. Pautas de selección para la elección de un sistema de aplicación específico para una auditoría

PAUTAS DE SELECCIÓN DESCRIPCIÓN

Sistema financiero Debe prestarse mayor atención en aquellos sistemas que poseen un control financiero sobre los activos de la corpora-ción. Ejemplo: Cobros totales y desembolsos, nóminas, cuentas a pagar y cobrar, etc.

Sistema de alto-riesgo Algunos sistemas de aplicación son más arriesgados que otros: 1. Porque son susceptibles de varios tipos de pérdidas. Ej.: fraude, malversación, etc. 2. Su pérdida puede paralizar la organización. Ej.: Pérdidas en el proceso de nóminas debidas a huelgas.

3. Su interferencia con otros sistemas y los errores genera-dos se propagan a esos otros sistemas.

Alta capacidad para la com-petencia peligrosa

Algunos sistemas dan a la organización una buena situación en el mercado. Ej.: Patentes, Copyright, un plan estratégico, etc.

Sistema avanzado tecnológi-camente

Si un sistema utiliza tecnología avanzada. Ej.: Un sistema de Bases de Datos, hardware y software distribuido, etc.

Sistemas de alto-coste Los sistemas que son caros de desarrollar, a menudo son sistemas complejos que presentan muchos problemas de control.

3.2.4 Herramientas para la dirección y desarrollo de auditorías

Vamos a tratar, en primer lugar, del diseño y aplicación de una entrevista. En se-gundo lugar, trataremos el diseño y uso de los cuestionarios. En tercer lugar, consi-deraremos los aspectos de fiabilidad y validez de los cuestionarios. A continuación, trataremos de la construcción de un diagrama de flujos de control. Finalmente, consideraremos las ventajas y desventajas de un diagrama de flujo de control.

Vamos a estudiar tres técnicas manuales utilizadas para recoger pruebas y/o evidencias de la calidad de los sistemas informáticos : entrevistas, cuestionarios y diagramas de flujo de control. Las entrevistas y los cuestionarios han sido usados generalmente en técnicas de recogida de evidencias en los sistemas manuales. Su importancia no ha disminuido en los sistemas informáticos. Particularmente duran-te la evaluación de la estructura de control de dirección, las entrevistas y los cues-tionarios constituyen un medio importante para comprobar la conformidad. Los diagramas de flujo de control también se han utilizado en los sistemas manuales:

CAPÍTULO 2 21

sin embargo, en la actualidad, además, su uso está mucho más difundido debido a la popularidad general de las técnicas de diagrama de flujo, como una ayuda de análisis y documentación en los sistemas informáticos

3.2.4.1 Entrevistas

Las entrevistas se suelen utilizar para obtener información tanto cualitativa como cuantitativa. Su objetivo es obtener respuestas francas, completas y honestas de un entrevistado que tiene más información sobre el tema de la entrevista que el propio auditor. Una entrevista no es un interrogatorio, en el sentido de que no se plantea de antemano ningún tipo de antagonismo entre el entrevistador (el auditor) y el entrevistado. Las entrevistas constan de tres fases principales:

1. La preparación de la entrevista.

2. La realización de la entrevista.

3. El análisis de la entrevista ya realizada.

Las entrevistas reducen el tiempo requerido para encontrar información si conseguimos que el entrevistado proporcione las respuestas adecuadamente. Sin embargo, como veremos, una encuesta efectiva requiere seguir cuidadosamente varias reglas de protocolo.

3.4.1.1 Preparación de la entrevista

Algunos de los pasos más importantes durante esta fase son:

1. Realizar una investigación previa: el auditor debe asegurarse de que la información que pretende conseguir mediante la entrevista no está disponible de forma sencilla de alguna otra fuente.

2. Identificación de los entrevistados: Puesto que ocupa, horario y lugar idóneos para la entrevista, datos profesionales completos, etc.

3. Preparar el contenido de la entrevista: Deben quedar claros previamente los objetivos de la entrevista, y debe realizarse una lista de la información que se desea obtener con la misma. Por supuesto, las preguntas deben estar preparadas y escritas. Las preguntas iniciales no deben tratar de temas controvertidos o problemáticos, y las últimas deben permitir al entrevistado expresar su opinión. Deben evitarse en lo posible las preguntas "abiertas" del tipo: ¿ Qué tipos de controles implanta usted en la preparación


de trabajos? y sustituirlas por preguntas de respuesta cerrada (del tipo "si" ó "no") : ¿ Preparan ustedes "hash totals" sobre los números de documento ?.

4. Planificar fecha, hora y lugar de la entrevista: La planificación previa y cuidadosa permite al entrevistado preparar material si fuera necesario, y genera un mejor ambiente. Se deben evitar las horas posteriores a las comidas. Dentro de lo posible, se debe realizar la entrevista en el propio lugar de trabajo del entrevistado, de modo que el ambiente le sea familiar, que éste pueda localizar fácilmente documentación adicional, etc. , siempre y cuando no sea motivo de interrupciones, llamadas telefónicas, u otras distracciones.

3.4.1.2 Realización de la entrevista

La entrevista debe seguir básicamente la estructura que hemos diseñado previamente en la fase de preparación. Es conveniente aplicar ciertas reglas de protocolo:

1. Minimizar las disgresiones que nos aparten del objetivo principal de la entrevista.

2. Intentar escuchar la mayor parte del tiempo.

3. Permitir al entrevistado suficiente tiempo para pensar.

4. Ser educado: evitar tanto la condescendencia como la crítica.

5. Evitar los sarcasmos y los recursos humorísticos.

6. Evitar la utilización de jergas: Formular preguntas concisas y claras.

7. Permanecer atento e interesado durante el transcurso de la entrevista.

8. Evitar las confrontaciones.

9. Responder cortésmente a las preguntas que nos pueda a su vez realizar el entrevistado.

10. Evitar las familiaridades, aunque conozcamos personalmente al entrevistado.

CAPÍTULO 2 23

En todo caso, durante la entrevista, el auditor debe tomar notas continuamen-

te; debe evitarse en lo posible la utilización de grabadoras de cinta, que podrían poner nervioso al entrevistado. También debe permitirse, como norma general, que el entrevistado consulte o pueda revisar las anotaciones escritas que hemos realiza-do nosotros.

3.4.1.3 Análisis de la entrevista

Tan pronto como sea posible tras la realización de la entrevista, el auditor debe analizar y preparar un informe sobre la misma. En dicho informe, se debe:

1. Intentar separar los hechos de la opinión.

2. Intentar asimilar toda la información obtenida durante la entrevista, y determinar lo que aporta cada contestación al objetivo global de la misma.

3.2.4.2 Cuestionarios

Los cuestionarios pueden usarse para obtener información factual u opiniones. La mayor dificultad aparece cuando debe obtenerse una opinión. El auditor debe ser prudente para utilizar cuestionarios que sean válidos y fidedignos. En el anexo a esta publicación figuran algunos formatos de cuestionarios sobre diversas áreas de Auditoría y de diversos autores y procedencias.

3.2.4.3 Diagramas de Control

Los diagramas de flujos de control muestran qué controles existen y dónde están en un sistema.

Un auditor con experiencia puede utilizar los diagramas de flujo de control pa-ra identificar los controles de debilidades y puntos fuertes que existen en un siste-ma. No obstante los diagramas de flujo de control son a menudo costosos (en cues-tión de tiempo) y difíciles de mantener y modificar. Existe software que soporta dibujos y gráficos de este tipo, y su utilización mitiga algunas de las tradicionales dificultades asociadas con el uso de los diagramas de flujo de control.


3.3 Planificacion del trabajo de auditoria

3.3.1 Introducción

Las normas básicas de Auditoria sobre la realización del trabajo se pueden resumir en los siguientes principios:

1. Necesidad de planificación del trabajo con anterioridad al comienzo de éste.

2. Necesidad de analizar y evaluar el sistema de control interno de la organización auditada con el fin de determinar el grado de confianza que puede depositarse en dicho control, de manera que pueda establecerse la naturaleza, el momento de realización y la amplitud de los procedimientos de la auditoria de los estados financieros de la entidad.

3. Actitud mental independiente.

4. Adecuada evidencia del trabajo realizado y documentación de las conclusiones alcanzadas.

3.3.2 Normas para la ejecución del trabajo

El conjunto de Normas de Auditoría Generalmente Aceptadas, promulgadas por la AICPA, se puede clasificar en tres grupos distintos: Normas Generales, Normas para la Ejecución del Trabajo y Normas para la Emisión del Informe. Según la AICPA, estas normas son las siguientes:

Norma 1ª. El trabajo se planificará apropiadamente y se supervisará adecuadamente la labor de los colaboradores.

Norma 2ª. Deberá llevarse a cabo un adecuado estudio y evolución del control interno existente, como base para determinar la confianza que se puede depositar en el mismo y, consecuentemente, la extensión de las pruebas de Auditoría.

Norma 3ª. Deberá obtenerse evidencia comprobatoria suficiente y competente, mediante inspecciones, observaciones, preguntas y confirmaciones, para tener una base razonable para emitir una opinión sobre los Registros sujetos a examen.

CAPÍTULO 2 25

Estas normas deben presidir la preparación y ejecución efectivas del trabajo

del auditor, tanto en los ámbitos tradicionales, como en el ámbito del Sistemas de información, donde son igualmente aplicables.

La planificación, además de ser una norma, es una fase esencial de la Audito-ría, pues del éxito o fracaso de la planificación dependerá en gran medida el éxito o fracaso del resto del trabajo. Es básica para garantizar que la auditoría se va a llevar a cabo en la forma menos costosa para el cliente y más eficaz para el auditor.

En la fase de planificación deben quedar totalmente aclaradas las siguientes cuestiones:

1. ¿ Dónde se va a realizar el trabajo ?.

2. Cuándo o en qué periodo de tiempo se va a realizar ?.

3. ¿ Qué tipo de informe se va a emitir ?. (Auditoría, revisión limitada, examen diagnóstico ...)

4. ¿ En qué fecha es necesario que esté terminado el trabajo ?.

5. ¿ Cuándo estará terminado el informe ?.

6. Determinación de la composición del "Comité de Auditoria". En ciertos casos, cuando la complejidad del trabajo así lo requiera, es conveniente la creación de un "Comité de Auditoría", formado por el personal del cliente y los auditores.

3.3.3 Reglas basicas en la realizacion de una auditoría

1. Fomentar la cooperación de los elementos auditados. Hay que convencer de que el auditor busca mejoras y soluciones, para evitar la postura defensiva y de desconfianza.

2. Contar con el apoyo de la Dirección, ya que se deberán realizar entrevistas y solicitar documentación y posiblemente trabajos de los elementos auditados.

3. Cuidar aspectos protocolarios. Explicar primero al jefe qué se desea obtener de su subordinado.

4. Realizar una presentación o entrevista inicial en la que se cuenta el objetivo, su justificación y se aclaran dudas.

5. Solicitar, con la antelación precisa, la información inicial a obtener.


6. No adelantar resultados parciales. Pueden causar impresiones falsas.

7. Comentar con los interesados los resultados obtenidos, antes de presentarlos a niveles superiores.

8. En caso de que se investiguen posibles fraudes o irregularidades maliciosas, hay que cuidar que se realicen los trabajos pertinentes con el mayor sigilo posible. Y tampoco hay que comentar con los interesados los resultados obtenidos.

3.4 Metodología y Fases de la Auditoría Informática

Las fases del desarrollo de una auditoría informático son las siguientes:

1. Toma de Contacto

2. Validación de la Información

3. Desarrollo de la Auditoría

4. Fase de Diagnóstico

5. Presentación de Conclusiones

6. Formacion del Plan de Mejoras

A continuación vamos a descricbir cada una de ellas.

3.4.1 Pasos en una Auditoría de Sistemas de Información

La realización de una ASI la podemos desglosar en varias fases o pasos:

3.4.1.1 Fase de análisis preliminar

Objetivo: Obtener la información necesaria para tomar la decisión sobre como proceder con la auditoría. Pueden seguirse tres caminos.

1. Renunciar a la auditoría: El auditor carece de la competencia técnica para realizar la auditoría.

2. Realizar un análisis detallado del sistema de control interno.

CAPÍTULO 2 27

3. Desconfiar del sistema de control interno. Existen dos razones para

tomar esta decisión

• Quizá sea más rentable realizar directamente las pruebas subs-tantivas.

• El control de proceso de datos duplicará los controles existentes en el área de usuario.

Esta fase incluye un análisis de los controles directivos y los controles de apli-cación. Durante el análisis de los primeros se trata de comprender la organización y las “prácticas directivas” utilizadas en cada nivel de la jerarquía de la instalación. Durante el segundo análisis deben comprenderse los controles realizados sobre las transacciones más importantes que fluyen a través de los sistemas de aplicación en la instalación.

En primer lugar, durante esta fase, se realizan entrevistas con el personal de la instalación, se observan las actividades de la instalación y se analiza la documenta-ción de la instalación. Las evidencias han de documentarse completando cuestiona-rios, construyendo diagramas de flujo y tablas de decisión y preparando informes.

El análisis preliminar realizado por los auditores internos difiere del realizado por los auditores externos en tres aspectos:

1. Los auditores internos requieren menos tiempo para realizar el análisis, sobre todo en temas de control de dirección, ya que están familiarizados con el tema.

2. Los auditores internos poseen una amplia perspectiva que incluye consideraciones de eficacia y eficiencia al sistema.

3. Si los auditores internos piensan que existen debilidades en el sistema de control interno cuando completan la fase de análisis preliminar, antes de proceder directamente con las pruebas substantivas, siguen realizando unas pruebas detalladas del sistema de control interno en vista de hacer recomendaciones específicas para mejorar.

3.4.1.2 Fase de análisis detallado

Objetivo: Obtener información necesaria para que el auditor tenga un conocimien-to profundo de los controles usados en la instalación informática. De nuevo debe decidir si la auditoría se lleva a cabo o se rechaza, o se procede conforme a la fase


de pruebas con la expectativa de que la “dependencia” puede estar situada sobre el sistema de control interno, o proceder directamente al análisis de los controles de usuario o procedimiento de pruebas substantivas.

Tanto los controles de dirección, como los controles de aplicación han de ana-lizarse y a ser posible en este orden. Es importante identificar las causas de pérdida y riesgos existentes en la instalación y establecer los controles para reducir los efectos de las causas de pérdida.

Al final ha de comprobarse si los controles reducen las pérdidas a un nivel aceptable. Aún dentro de esta fase no se sabe con certeza si los controles son efica-ces, la evaluación supone la fiabilidad de las funciones a menos que haya una clara evidencia de lo contrario.

3.4.1.3 Fase de pruebas (The compliance testing phase)

El objetivo de esta fase es determinar si el sistema de control interno opera del modo que le corresponde. Trata de determinar si existen de hecho los controles y si trabajan correctamente. A menudo deben utilizarse técnicas asistidas por ordenador que determinan la existencia y la fiabilidad de los controles.

Al final de esta fase, deben ser evaluados los sistemas de control interno para ratificar la fiabilidad de los controles individuales.

3.4.1.4 Fase de análisis y controles de pruebas de usuario

Los usuarios realizan controles que compensan cualquier debilidad en el sistema de control interno de proceso de datos. Estos controles no deben estar duplicados, es decir, en algunos casos será útil eliminar cualquiera de los dos, tanto los controles de usuario como los controles informatizados.

3.4.1.5 Fase de pruebas substantivas

El objetivo de esta fase es conseguir evidencias suficientes para poder emitir una valoración final sobre la existencia o no de pérdidas o la posibilidad de que ocurran durante el proceso de datos. El auditor externo emite esta valoración como una opinión.

Según Davis [1983] existen cinco tipos de pruebas substantivas que se reali-zan en una instalación de proceso de datos.

1. Pruebas que identifican los procesos erróneos.

CAPÍTULO 2 29

2. Pruebas para asegurar la calidad de la información.

3. Pruebas para identificar información inconsistente.

4. Pruebas para comparar información con cómputos físicos.

5. Confirmación de información con fuentes externas.

Algunas de estas pruebas requieren soporte informático.

3.4.2 Decisiones importantes en una Auditoría

Cuando se realiza una ASI aparecen ciertas dificultades a la hora de tomar decisio-nes. Vamos a ver los aspectos más importantes que afectan a la toma de decisiones.

3.4.2.1 Evaluación de una decisión (The evaluation judgment)

Es una de las decisiones más difíciles al hacer una Auditoría de Sistemas. Debe hacerse al final de la fase de análisis preliminar, al final de la fase de análisis deta-llado, al terminar la fase de pruebas (compliance testing phase), y al final de la fase de pruebas substantivas (the substantive testing phase).

Influye en la continuación de la auditoría, si se puede contar con el sistema de control interno, qué controles son críticos para la auditoría y cómo deben probarse, qué pruebas deben realizarse y finalmente si el sistema está protegido físicamente, mantiene la integridad de los datos y si el sistema es eficaz y eficiente. No existe una metodología para tomar este tipo de decisiones.

3.4.2.2 Escoger el instante del proceso de auditoría

Al planificar una ASI, es importante decidir cuándo va a llevarse a cabo la audito-ría. Algunos piensan que son necesarios algunos cambios en el trabajo habitual, ya que probablemente se deba compartir el “tiempo de ordenador” para los propósitos de la auditoría. Otros opinan que deben hacerse cambios fundamentales al evaluar-se un sistema informático. Estos insisten en la participación del diseño de las fases de un sistema de proceso de datos. Si se acepta esta última visión, las auditorías se desarrollarán en tres etapas de la vida del sistema : Fase de diseño, fase de ejecu-ción y fase de revisión.


3.4.3 Toma de Contacto

Objetivos

Principalmente es una fase para lo que podríamos llamar auditores externos y como objetivos principales tendríamos la puesta en contacto con todos aquellos elemen-tos informativos que puedan ser interesantes para la consecución del trabajo.

Realización

Aquí habrá que tener en cuenta inicialmente dos visiones:

- Organizativa: La propia estructura organizativa de la empresa, su organigrama, volumen , líneas de producto, situación en el mercado...

- Recursos informáticos: Estructura del departamento, relaciones funcionales y jerárquicas, recursos humanos, materiales (SGBD, SO, comunicaciones...), aplicaciones de desarrollo en sistemas de explotación.

En definitiva lograr alcanzar un profundo conocimiento de la idiosincrasia or-ganizativa a todos los niveles para poder desenvolverte en el ámbito de la empresa con total comodidad y conocimiento del funcionamiento interno de ésta.

Para poder asegurarnos de que las conclusiones obtenidas en nuestro análisis preliminar son las correctas sería interesante que se pudieran contrastar con la emi-tidas con el grupo de auditores internos.

Es también en esta fase donde se da el visto bueno a la viabilidad de la reali-zación de la auditoría, puede que por diversas razones como, por ejemplo, la caren-cia de capacidad para auditar el sistema, ya que excede el campo de actuación del auditor, o la necesidad de realizar otro tipo de auditoría, ya que auditando informá-ticamente no se alcanzarán a resolver los problemas que la empresa tenga.

Herramientas y Documentación

En la fase de toma de contacto se utilizan principalmente dos herramientas intangi-bles que son:

CAPÍTULO 2 31

- La experiencia propia: el auditor con la experiencia

adquirida en la realización de otras auditorías interpreta de una forma más efectiva toda aquella información.

- Implicación de Directivos y usuarios: para que el auditor pueda realizar las labores de aproximación al problema de una forma óptima necesita la cooperación de todos y cada uno de los integrantes de la estructura organizativa de la empresa, porque quién mejor que los propios implicados en la empresa son capaces de transmitir cuáles son los puntos clave a ser auditados, haciendo partícipes a éstos en todo el proceso de ejecución de la auditoría.

Además de los dos puntos enumerados anteriormente el auditor tiene que ayu-darse de todo tipo de formularios que pueda rellenar el personal y que después puedan ser de interés a la hora de extraer conclusiones. También podríamos utilizar todo tipo de material informático como programas de interpretación de datos obte-nidos, estadísticos..., pero nunca perdiendo de vista las interpretaciones más subje-tivas, que no por ello erróneas, de todos los aspectos interesantes.

Por último cabría remarcar la importancia que se le tiene que dar a esta fase, ya que sobre todas las conclusiones extraídas se basarán todas las otras fases, es decir, una mala interpretación de la filosofía de la empresa podría repercutir en una mala realización de la auditoría.

3.4.4 Validación de la Información

Objetivos

Una vez finalizada la fase de toma de contacto el auditor tiene que estar seguro de que toda la información recogida es válida, precisa, eficiente y de real importancia para su trabajo. Lo que pretende esta fase es validar toda la información obtenida anteriormente, así como definir los resultados esperados en la fase de operación.

Realización

Con toda la información deberemos ser capaces de tratar los siguientes temas que son de importancia vital:


• Concentración de objetivos: fijar los objetivos a nivel global que esperamos obtener en nuestro trabajo, hasta dónde llegaremos y cómo lo queremos hacer.

• Las áreas que cubrirá: qué partes exactas de la empresa y, en este caso del sistema, serán objeto de ser auditadas.

• Personas de la organización que deberán colaborar directa e indirectamente y en qué momento concreto.

• Plan de trabajo: - Tareas que se deberán realizar.

- Calendario, tanto de todas las fases así como de la consecución del trabajo.

- Presupuesto, partir de la base de las inevitables limitaciones presupuestarias, si existen, aspecto que es bueno tener siempre presente.

- Equipo auditor necesario: una vez obtenido todo el material de partida el encargado tiene que ser capaz de realizar una estima-ción lo más exacta posible del equipo de auditores necesario, en cuanto a número y especialidades, o áreas de conocimiento.


Llegados a este punto, el auditor debe disponer de todo tipo de manuales de los diferentes sistemas informáticos tanto SW como HW. Por otro lado, el grado de conocimiento de las personas en el ámbito laboral tiene que ser alto y la movilidad en la organización tiene que ser máxima. el auditor también debe estar familiariza-do con los controles directivos y con los de aplicación para ser capaz más adelante de determinar dónde puede haber fallos en la utilización o si, por otro lado, son los propios controles los que no funcionan adecuadamente. Y por último se tendrá que utilizar constantemente la documentación obtenida de los cuestionarios realizados en la fase anterior.

CAPÍTULO 2 33

3.4.5 Desarrollo de la Auditoría

Objetivos

Es en esta fase donde realmente se llevarán a cabo las tareas propias de la realiza-ción de la auditoría. Es aquí donde se profundizará en todo aquello que es suscepti-ble de ser revisado, modificado o cambiado.

Realización

Es el momento de ejecutar todas aquellas tareas explicitadas en la fase anterior. Esta fase la podríamos calificar de fase de observación, no en el sentido que se le daba a la primera en la que observábamos el funcionamiento de la empresa así como todos aquellos aspectos que nos ayudasen a conocerla mejor. Sin embargo, aquí recogeremos datos, situaciones, deficiencias del propio sistema informático objeto de la auditoría. Será un periodo en el que se efectuarán los siguientes traba-jos :

• Se efectuaran las entrevistas previstas en la fase de planificación.

• Se completarán los cuestionarios que conlleva el auditar: cuestionarios que nos ayudarán a observar problemas en el sistema, basándonos en la información facilitada por los usuarios directos del sistema que son los perfectos conocedores de éste.

• Se observarán las situaciones deficientes, no sólo las aparentes sino las que hasta ahora no hayan sido detectadas, por lo que se podrá llegar a simular situaciones límite.

• Se observarán los procedimientos, tanto en los informáticos como en los usuarios.

• Se ejecutarán, por tanto, todas las previsiones efectuadas en la fase anterior con el objetivo de llegar a la siguiente etapa en condiciones de diagnosticar la situación que se ha encontrado.


En lo que respecta a la documentación, el auditor tiene que apoyarse en la expe-riencia que ha obtenido de otros sistemas para poder comparar resultados de ren-dimientos anteriores con los que le presta el sistema actual.


En cuanto a las herramientas, puede ser interesante que se utilice algún tipo de herramienta mecanizada que le ayude a interpretar los cuestionarios realizados por los usuarios. A menudo, también deben utilizarse técnicas asistidas por ordenador que determinen la existencia y la fiabilidad de los controles. Además, se puede disponer de:

• Los juegos de ensayo que son una herramienta eficiente y significativa que se utiliza para probar programas enrevesados, aunque la realización de buenos juegos de ensayo no siempre sea una tarea fácil.

• Los programas de auditoría desarrollados por las principales firmas auditoras.

• Las técnicas de ejecución en paralelo para verificar el correcto funcionamiento de los programas que se tienen que revisar.

3.4.6 Fase de Diagnóstico

Objetivo

El objetivo será analizar e interpretar todos los datos obtenidos en el punto anterior y ser capaces de concluir con un diagnóstico de la situación real encontrada.

Realización

Para ello se servirán de su propia experiencia en situaciones anteriores, así como de los modelos que tengan establecidos con los que poder contrastar los resultados de las observaciones, pudiendo comparar cantidades cuantificables, ratios, índices, etc. con los óptimos (en apariencia) para proceder a una instalación con las caracte-rísticas de la observada.

Como resultado de esta etapa, deben quedar claramente definidos los puntos débiles y por contrapartida los fuertes, los riesgos eventuales y en primera instancia unos posibles tipos de solución o mejora.

La finalidad de esta fase es conseguir evidencias suficientes para emitir una valoración sobre la existencia o no de pérdidas o la posibilidad de que ocurran du-rante el proceso de datos. El auditor externo emite esta valoración como una opi-nión.

CAPÍTULO 2 35

Para diagnosticar correctamente la eficacia del sistema informático, existen

cinco tipos de pruebas substantivas que se realizan en una instalación de proceso de datos:

1. Pruebas que identifican los procesos erróneos.

2. Pruebas para asegurar la calidad de la información.

3. Pruebas para identificar información inconsistente.

4. Pruebas para comparar información con cómputos físicos.

5. Confirmación de información con fuentes externas.


En lo referente a la documentación, la información no tiene porqué ser útil sólo para los auditores sino, en general, para cualquier consultor informático. Entre esta documentación cabe destacar:

• Organigrama de la empresa y en especial del servicio informático.

• Documentos de organización interna.

• Aspectos económicos como gastos, presupuestos, costes humanos y materiales, etc.

• Estudios informáticos realizados y en curso.

• Actividades desarrolladas por el propio personal o por terceros.

• Configuraciones de máquina: ordenadores, unidades de disco, comunicaciones, etc.

• Documentos de input de datos.

• Listado de operación de consola.

• Plannings.

• Y por último, para las aplicaciones existentes se pueden citar: el análisis funcional y orgánico, los cuadernos de carga, el diseño de ficheros, los juegos de ensayo, las pruebas de programa, etc.


En cuanto a las herramientas, hay que decir que se debe continuar con las uti-lizadas hasta ahora, pero siempre teniendo en cuenta su utilización en cada fase, ya que ésta es diferente.

3.4.7 Presentación de Conclusiones

Es el momento de que los responsables conozcan las conclusiones obtenidas por los auditores en la realización de la fase anterior.

Por supuesto que estas conclusiones se discutirán con las personas afectadas, por lo que deben estar bien argumentadas, probadas y documentadas para que no se puedan refutar en las primeras discusiones.

Esta fase es claramente delicada porque es el momento en el que se presentan deficiencias, situaciones anómalas o por lo menos mejorables. Por eso es recomen-dable que los auditores tengan el suficiente tacto como para presentar estas conclu-siones como un plan de mejoras en beneficio de todos, más que como una reproba-ción de los afectados, excepto en los casos en que esto último sea necesario, pues hay situaciones en las que “alguien puede ser sustituible” y es aconsejable que el auditor (como consultor al servicio de una Dirección) tenga la obligación de hacer conocer estas situaciones.

Y por último, resaltar la importancia de la forma que debe tener la presenta-ción de conclusiones, es decir, tiene que ser clara, precisa, relevante y que no de lugar a la ambigüedad.

3.4.8 Formación del Plan de Mejoras

Llegamos a este último punto, la dirección ya conoce las deficiencias que el equipo auditor ha observado en su departamento informático; éstas han sido discutidas. Pero no basta con quedarse ahí, ahora es cuando los auditores deben demostrar sus experiencias anteriores lo suficientemente contrastadas y exitosas como para ser capaces de adjuntar junto con el informe de auditoría, el plan de mejoras que per-mitirá solventar las deficiencias encontradas.

El informe comprenderá las deficiencias encontradas en los pasos anteriores abordando los puntos relativos a auditoría funcional, como son la gestión de recur-sos humanos, la seguridad física, los costes, etc., abordando también aspectos de auditoría operativa, tales como el cumplimiento de plazos, los procedimientos de control, la calidad i fiabilidad.

CAPÍTULO 2 37

El plan de mejoras abarcará todas las recomendaciones que intenten soslayar

las deficiencias detectadas en la realización de la auditoría. Para ello se tendrán en cuenta los recursos disponibles, o al menos potencialmente disponibles, por parte de la empresa objeto de la auditoría.

De cara a la ejecución de las recomendaciones contenidas en el plan, es posi-ble distinguir entre las medidas que se pueden realizar a corto plazo, de las que son a medio y por último, de las ejecutables a largo plazo.

Entre las primeras se incluirán aquellas mejores puntuales y de fácil realiza-ción como son las mejoras en plazo, calidad, planificación o formación. Las medi-das a medio plazo necesitarán de uno a dos años para poderse concretar. Aquí pues, caben ya mejoras algo más profundas y con mayor necesidad de recursos, como la optimización de programas, o de la documentación, e incluso algunos aspectos de diseño del sistema.

Para concluir, las consideraciones a largo plazo, como cabe pensar fácilmente, pueden llevar a cambios sustanciales en las políticas, medios o incluso estructuras de servicio de informática. Lógicamente con más tiempo y más medios es posible afrontar profundas modificaciones si con ello se consiguen las mejoras redactadas por el equipo auditor. Estas mejores pueden pasar por la reconsideración de los sistemas en uso o de los medios humanos y materia les con que se cuenta, llegando si es preciso a una seria reconsideración del plan informático. Todo esto comporta un riesgo adicional, por lo que se requiere una profunda reflexión por parte de la empresa, así como un considerable grado de confianza en el equipo auditor.

3.5 El Informe de Auditoría

El informe final en una auditoría de Sistemas de información tiene las mismas con-sideraciones que en cualquier tipo de auditoría tradicional: es la expresión docu-mental del juicio emitido por el auditor y la única referencia oficial o, por lo me-nos, constatable, de la auditoría [1].

La estructura y contenido del informe final debe seguir las pautas dadas en el capítulo anterior para el informe de auditoría en general, con las adaptaciones ne-cesarias a este entorno de trabajo diferenciado.

En esta sección vamos a desarrollar la estructura y contenido de la Carta de Presentación del Informe, y la estructura formal, el modelo conceptual y expositi-vo, y las guías de lenguaje y redacción del informe final.


3.5.1 La Carta de Presentación del Informe Final

Constituye una especie de resumen de la auditoría realizada, cuyo contenido se ampliará en el informe final. El destinatario de este documento es única y exclu-sivamente la persona que realizó el encargo de auditoría, sea la dirección general de la empresa, sea el cliente contratante o la persona delegada directamente por el cliente. Es obvio que el auditor debe poseer también una copia para guardarla en el expediente de la auditoría realizada y de uso absolutamente privado.

La estructura y contenido de este documento debe atenerse a las recomenda-ciones siguientes:

1. Independientemente de la extensión del informe final, no debe superar las cuatro páginas.

2. Tiene que incluir datos como la fecha y la naturaleza de la auditoría, así como los objetivos generales y alcance de la misma.

3. Tiene que cuantificar el peso de las áreas analizadas.

4. Debe presentar una conclusión general, concretando las áreas de gran debilidad.

5. Tiene que presentar las debilidades detectadas en orden de mayor a menor importancia y gravedad.

6. Evitar la inclusión de recomendaciones, que solamente se expresan en el informe.

La Carta de Presentación, como resumen del Informe Final, normalmente se redacta una vez finalizada la redacción del propio informe.

3.5.2 Estructura formal del Informe Final

La estructura del informe final debe constar de las secciones siguientes:

1. Identificación e introducción.

2. Definición de objetivos y alcance de la auditoría.

3. Enumeración exhaustiva de los temas objeto de la auditoría.

4. Cuerpo expositivo.

CAPÍTULO 2 39

En la sección de Identificación e introducción, debe constar la fecha de inicio

de la auditoría y la fecha de redacción del informe, así como la identificación del equipo de auditoría, y de las personas entrevistadas, con los datos de su puesto de trabajo, responsabilidad y departamento al que están adscritas.

En la sección de Definición de objetivos y alcance de la auditoría, se debe aplicar las mismas pautas que en el modelo general de informe, vistas en el capítu-lo anterior.

En la sección de Cuerpo expositivo, se debe tratar en profundidad cada uno de los temas enumerados en la sección anterior, siguiendo un orden determinado, que expresamos a continuación:

* Situación actual.

* Tendencias de situación futura.

* Puntos débiles y amenazas.

* Recomendaciones y planes de acción.

* Redacción de la Carta de Presentación.

A diferencia de la Carta de Presentación, el auditor puede proporcionar cuan-tas copias indique el cliente, siempre y cuando estén personalizadas y se entreguen directamente a sus destinatarios. Recordemos el carácter privado de una auditoría.

3.5.3 El modelo conceptual y expositivo del Informe Final

No existe un modelo normalizado de Informe Final de Auditoría, de la misma for-ma que no existe una auditoría que sea exactamente igual a otra. Sin embargo, hay modelos elaborados por las empresas o los profesionales de auditoría que aplican habitualmente y que se han perfeccionado en base a la experiencia.

Podemos hablar de un modelo estándar que se basa en los principios de Inclu-sión y de Consolidación de hechos relevantes: solamente se debe incluir los hechos importantes, que se puedan verificar objetivamente, que estén probados y respalda-dos documentalmente, y que las recomendaciones sobre los mismos mantengan o mejoren las normas y estándares del sistema.

Los hechos que cumplen estos principios se pasan al informe, lo que significa que existe una debilidad objetivo de corrección. El modelo estándar -consensuado


por la práctica- de informe contiene unas pautas para desarrollar el flujo del hecho o de la debilidad y la secuencia de fases para eliminar esta debilidad:

1. Descripción exacta, convincente y sin repeticiones del hecho encontrado.

2. Consecuencias deducibles del hecho.

3. Repercusión del hecho sobre otros ámbitos del sistema o de la empresa auditada.

4. Conclusión del hecho en el caso de una exposición extensa y compleja.

5. Recomendación del auditor concreta, exacta en el tiempo, explícita en el texto, y dirigida expresamente a quien pueda implantarla.

3.5.4 Guías de lenguaje y redacción

Podemos distinguir tres unidades básicas en la redacción del informe: títulos, párra-fos y frases. Los títulos deben ser breves y al mismo tiempo deben expresar exac-tamente el contenido del texto que les sigue. Los párrafos deben tener un límite de unas 10 líneas y tratar solamente un asunto. Si se supera este límite, se crea otro párrafo distinto. Las frases deben tener un límite de 3 líneas y deben corresponder a una sola idea, expresada con dos tiempos verbales como máximo, y sin sustantivi-zar los verbos.

En general, hay que utilizar un lenguaje lo más exacto y sobrio posible, con los términos técnicos más extendidos y el equivalente en la propia lengua si no introduce distorsión en el sentido del texto. Hay que evitar redundancias y el uso combinado de adverbios y adjetivos y los circunloquios como "con referencia a", "consecuentemente con", etc.

2.1 Clasificación informal de las herramientas de Auditoría

Debido a la rápida expansión de las tecnologías informáticas, el auditor puede dis-poner actualmente de herramientas cuyo soporte es cualquier ordenador compatible

CAPÍTULO 2 41

PC, de sobremesa o portátil, o puede tener herramientas más tradicionales que se han "informatizado". Tampoco hay que olvidar las herramientas que confecciona el propio auditor o hace construir, que funcionan sobre el propio sistema informático a auditar. Por tanto, es difícil establecer una clasificación estricta de las herramien-tas de auditoría. Para no pecar en exceso de criterios, vamos a reducirlos solamente a dos criterios principales: 1) en cuanto a la innovación tecnológica: las herramien-tas tradicionales y las herramientas informáticas; y 2) en cuanto a su especializa-ción: las herramientas de propósito general y las específicas de auditoría.

• 1) En cuanto a innovación tecnológica:

1.1. Herramientas tradicionales: son las herramientas que ha venido utilizando el auditor tradicionalmente e, incluso, que ha heredado de la tradición de

otros tipos de auditoría ( contable):

• Cuestionarios Previos.

• Estándares.

• Entrevistas.

• Checklist.

• Matrices de Riesgos.

1.2. Herramientas informáticas: son las que funcionan con ordenador, de cual-

quier tipo:

• Trazas y/o Huellas de Auditoría.

• Software de ofimática (procesadores de textos, hojas de cálculo, gesto-res de bases de datos, procesadores de gráficos e imágenes).

• Software estadístico.

• Software de control de proyectos.

• Software de interrogación.

• Lenguajes de programación y librerías de programas.

• Simuladores y analizadores de sistemas operativos.

• Monitores.

• Software de Re-Ingeniería e Ingeniería Inversa.

• Paquetes de auditoría (CAAT).

• 2) En cuanto a su especialización:


2.1. Herramientas de propósito general: son las herramientas cuyo espectro de

aplicación trasciende el ámbito de la auditoría y sirven también para otros tipos de actividades.

• Estándares.

• Software de ofimática (procesadores de textos, hojas de cálculo, gesto-res de bases de datos, procesadores de gráficos e imágenes).

• Software estadístico.

• Software de control de proyectos.

• Software de interrogación.

• Lenguajes de programación y librerías de programas.

• Simuladores y analizadores de sistemas operativos.

• Monitores.

• Software de Re-Ingeniería e Ingeniería Inversa.

2.2. Herramientas de propósito específico: son las que t ienen solamente aplica-ción en la actividad informática.

• Cuestionarios Previos.

• Entrevistas.

• Checklist.

• Trazas y/o Huellas de Auditoría.

• Paquetes de auditoría (CAAT).

2.2 Herramientas utilizadas en la actividad de Auditoría

2.2.1 Cuestionarios previos

Para iniciar el trabajo de campo del auditor, suele ser habitual comenzar solicitando la cumplimentación de cuestionarios preimpresos que se envían a las personas con-cretas que el auditor estima adecuadas, sin que sea obligatorio que eses personas sean las responsables oficiales de las diversas áreas a auditar.

Estos preimpresos no deben ser repetidos para instalaciones distintas sino dife-rentes y muy específicos para cada situación, y muy cuidados en su fondo y en su forma.

CAPÍTULO 2 43

2.2.2 Estándares

Conjunto de normas y procedimientos de aplicación en la función informática y administrativa de la empresa. Pueden ser estándares de calidad o de otro tipo.

2.2.3 Entrevistas

Las relaciones personales con el auditado pueden ser de tres formas:

• Mediante la petición de documentación concreta sobre alguna materia de su responsabilidad.

• Mediante "entrevistas" en las que no se sigue un plan predeterminado ni un método estricto de sometimiento a un cuestionario.

• Por medio de entrevistas en las que el auditor sigue un método preestableci-do de antemano y busca unas finalidades concretas.

La entrevista es una de las actividades personales más importantes del auditor. En ellas, recoge más información y mejor matizada, que la proporcionada por me-dios propios puramente técnicos o por las respuestas escritas en los cuestionarios. La entrevista se basa fundamentalmente en el concepto de interrogatorio.

El auditor informático experto entrevista al auditado siguiendo un cuidadoso sistema previamente establecido, consistente en que, bajo la forma de una conver-sación correcta y lo menos tensa posible, el auditado conteste sencillamente y con pulcritud a una serie de preguntas variadas, también sencillas. Sin embargo, la sen-cillez es sólo aparente. Tras ella debe existir una preparación muy elaborada y sis-tematizada, y que es diferente para cada caso en particular.

2.2.4 Checklist

Las preguntas que el auditor elabora sistemáticamente para el análisis, cruza-miento de datos y síntesis posterior, que luego traduce en preguntas sencillas en las entrevistas, se denomina checklist. La checklist se recomienda que sea sólo de uso interno del auditor, y que no se dedique a recitar dichas preguntas en las entrevis-tas, sino a darles una forma coloquial para aplicarlas en la entrevista con la persona auditada.

Hay dos tipos de evaluación de checklist:


• Checklist de rango: contiene preguntas que el auditor debe puntuar dentro de un rango preestablecido ( por ejemplo, de 1 a 5, siendo 1 la respuesta más negativa y 5 el valor más positivo).

• Checklist Binaria: constituida por preguntas con respuesta única y exclu-yente: Si o No. Aritméticamente, equivalen a "1" o "0", respectivamente.

2.2.5 Matrices de riesgos

Son matrices que combinan los riesgos o amenazas con los impactos en el sistema o con las medidas de cobertura que se pueden aplicar para paliar los riesgos.

La Exposición a un suceso es la probabilidad de que se produzca ese suceso.

El Riesgo de un suceso es el producto de la exposición por el coste del suce-so.

El Riesgo es una medida en dinero del coste probable que supone para una instalación la existencia de una posible amenaza.

En la aplicación de las matrices de riesgos se aborda el estudio de las amena-zas a la función informática, el impacto que pueden producir si estas amenazas se materializarán, los recursos afectados, y el impacto de las medidas de cobertura aplicadas.

En la figura 8.1 se muestra la gráfica clásica que contempla los costes frente al grado de seguridad alcanzado cuando se aplican medidas de cobertura sobre los riesgos detectados.

CAPÍTULO 2 45

Figura 8.1. Coste y Seguridad en las curvas

de Riesgo y Medidas de Cobertura

Hay tres tipos principales de matrices de riesgos :

• Matriz (Probabilidad, amenaza, impacto), que se muestra en la Tabla 2.1.

Tabla 2.1. Matriz (Probabilidad, amenaza, impacto)

Impacto/Amenaza ai

ij Pij

Pij: Probabilidad de que la amenaza ai produzca el impacto i j.i j

• Matriz (Amenazas, medida de cobertura, efecto), que se muestra en la Tabla 2.2.


Tabla 2.2. Matriz (Amenaza, medida de cobertura, efecto)

Medida de Cobertura /Amenaza ai

mj eij

e ij: Efecto que produce, sobre la amenaza ai, la aplicación de la medida de cobertura mj

• Matriz (Amenaza, recurso, medida de cobertura), que se muestra en la Tabla 2.3.

Tabla 2.3. Matriz (Amenaza, recurso, medida de cobertura)

Recurso o acción/Amenaza o elemento amenazado

ai

rj mij1......; mijk......;

mij: medida de cobertura que puede ser aplicable

2.2.6 Trazas y/o Huellas

Las Trazas se utilizan para comprobar la ejecución de las validaciones de los datos previstas, para verificar que los programas realizan exactamente las funciones pre-vistas. Las trazas no deben modificar en absoluto el sistema.

La Auditoría Financiero-contable convencional emplea trazas con mucha fre-cuencia. Son programas encaminados a verificar la corrección de los cálculos de nóminas, primas, etc. Hay incluso programas de contabilidad que facilitan la ges-tión de librerías y registran los cambios producidos en los módulos de librería (PANVALET), para investigaciones posteriores.

CAPÍTULO 2 47

2.2.7 Software de Ofimática

Son procesadores de textos, hojas de cálculo, gestores de bases de datos, procesa-dores de gráficos e imágenes, y cualquier otro programa que se utilice en entornos de ofimática y similares.

Los procesadores de textos pueden usarse sobre todo en la elaboración de la documentación narrativa: cartas, informes, memorándums, etc.; así como en otro tipo de documentación: cuestionarios, listas, etc. Normalmente funcionan en plata-formas compatibles PC, Apple MacIntosh, o Unix. Podemos citar algunos produc-tos bastante útiles: Microsoft Word para Windows versiones 2.0 y 6.0 (PC), Mi-crosoft Word para Macintosh versiones 5.0 y 6.0, MacWrite II (MacIntosh), Word-perfect versión 6.0 -y posteriores (PC y MacIntosh), Lotus Ami Pro (PC) y LATEX (Unix).

Las hojas de cálculo tienen múltiples aplicaciones como para la elaboración de un presupuesto, el cotejo de listas de números, etc. Entre los productos más cono-cidos tenemos: Microsoft Excel versión 4.0 y posteriores (PC y MacIntosh), Lotus 1-2-3 (PC) y QuatroPro de Novell (PC).

Los gestores de bases de datos pueden servir para llevar registros de la docu-mentación manejada en los papeles de trabajo, registros de actividades realizadas, de personas contactadas, etc. Los productos más conocidos son: Microsoft Access versión 2.0 (PC), Borland dBASE IV y V (PC), y Paradox versión 4.0 y posterio-res.

Los procesadores gráficos y de imágenes pueden aplicarse en la confección de diagramas de flujo -hay productos especializados en esto-, en la captación y edi-ción de gráficos producidos por otro tipo de software, como el estadístico, para preparar presentaciones, etc. Los productos más conocidos son: Corel Draw ver-sión 3.0 y posteriores (PC), Microsoft Power Point versión 3.0 y posteriores (PC y MacIntosh) -para presentaciones-, Micrograf Designer (PC), Micrograf Graphics Works (PC), Micrograf ABC FlowCharter (PC) -para diseño de diagra-mas de flujo-, y Harvard Graphics (PC).

En los entornos de Mainframe, con sistemas operativos propios y no estándar, suele haber también herramientas que realizan funciones similares a las descritas en esta sección. El auditor debe recabar toda la información posible acerca de ellas. Por lo general, estas herramientas de Mainframe suelen ser muy potentes en el manejo de grandes volúmenes de información, pero bastante farragosas en su ma-nejo.


2.2.8 Software estadístico

Son paquetes de programas bastante extensos y que permiten el estudio estadístico de cualquier conjunto de muestras o población, aplicando diversas técnicas y enfo-ques. Permiten al auditor el muestreo de los datos y el análisis del grado de con-fianza de los mismos según el diseño de la muestra que ha confeccionado. Algunos de los módulos más comunes de estos programas, se han incorporado en otros pro-gramas de auditoría más específicos. Entre los productos más conocidos, tenemos los siguientes: BMDP (PC y Mainframe), SPSS (PC y Mainframe), Statgraphics (PC y Macintosh), y Systat (PC y Macintosh).

2.2.9 Lenguajes de programación y bibliotecas de programas

El auditor tiene a su disposición una serie de lenguajes de programación de propó-sito general, que pueden ser compilados o interpretados, para elaborar peticiones de información, en forma de programas, contra el sistema auditado. Normalmente, está obligado a utilizar el lenguaje que tiene la instalación informática. En otras ocasiones, bajo condiciones especiales o autorización previa, si las normas de la instalación lo exigen, puede aplicar programas hechos en un lenguaje distinto del de la instalación.

Los lenguajes de programación más usuales en las instalaciones informáticas son el COBOL, el FORTRAN, el C, y el RPG (exclusivamente IBM -AS/400).

Además, en las instalaciones de cierta importancia se disponen de bibliotecas de programas y subprogramas que pueden facilitar el desarrollo de los programas propios del auditor, como, por ejemplo, módulos para la conversión y cálculo de fechas, módulos para el acceso parametrizado a bases de datos, etc.

Otra posibilidad que tiene el auditor en cuanto a lenguajes de programación son los denominados lenguajes de programación visual, que funcionan sobre plata-formas con gestores de ventanas, como Microsoft Windows, IBM OS/2, OSF/MOTIF y X-Window, porque tienen facilidades gráficas para el desarrollo de un programa, además de las sentencias escritas. Entre los productos más conocidos tenemos los siguientes: Microsoft C++, Microsoft Visual Basic, Borland C++, Zor-tech C++, Watcom C++, CA Clipper Borland Turbo Pascal y Borland Delphi.

Por otra parte, existen generadores de aplicaciones cuyo propósito es la gene-ración de programas en un lenguaje de programación dado, a partir de unas especi-ficaciones iniciales. Estos productos crean los fuentes de los programas que, poste-riormente se pueden o no ampliar manualmente y se compilan para obtener los

CAPÍTULO 2 49

módulos ejecutables. Normalmente, el espectro de posibles aplicaciones de estos productos suele ser bastante reducido (programas de contabilidad, de manejo de ficheros, etc.).

2.2.10 Software de control de proyectos

Son paquetes de programas diseñados para la gestión de proyectos de cualquier índole, con facilidades para la definición de tareas, de tiempos asignados a cada tarea, de distribución de recursos, etc. con el propósito de alcanzar el objetivo fija-do de antemano. Las fases más comunes en este tipo de software son: Conceptuali-zación, Desarrollo, Monitorización, Control y Terminación de proyectos. Práctica-mente todos los productos están basados en las técnicas PERT/CPM, para el análi-sis y diseño de proyectos.

Se puede llevar a cabo un control de proyectos utilizando una hoja de cálculo, como las mencionadas en la sección 8.2.7, que tienen capacidad para crear gráficos a partir de los datos contenidos en ellas.

También se puede utilizar gestores de bases de datos como los mencionados en la sección 8.2.7, para registro de personal, presupuestos, recursos, asignación de responsabilidades, etc.

Hay, por otra parte, herramientas analíticas que efectúan el análisis de los pro-yectos, aplicando técnicas PERT/CPM y estadísticas. Estas pueden ser tan genera-les como los lenguajes de programación , vistos en la sección 8.2.9, o tan compli-cadas como los paquetes estadísticos, vistos en la sección 8.2.8.

Finalmente, las herramientas más modernas combinan las capacidades de las herramientas vistas en los párrafos anteriores, con funciones de red y comunicación para la compartición de información. Se suelen denominar Sistemas de Informa-ción de Gestión de Proyectos (Project Management Information Systems, PMIS). Entre los productos más conocidos, que pueden funcionar sobre red local de plata-formas PC, tenemos los siguientes: Harvard Project Manager 3.0, Superproject Expert 1.1, Time Line 3.0, Instaplan, Project Scheduler 4, Microsoft Project 4.0, Qwiknet Professional, y Micro Planner para Windows.

La aplicación que tiene este tipo de herramientas para el auditor, le puede ser-vir para el diseño de la planificación y programación de los procedimientos de au-ditoría, para el seguimiento de las actividades, y para la evaluación final de las desviaciones entre lo presupuestado y lo real. También puede aplicarse en las tareas de dirección de auditoría.


2.2.11 Software de interrogación

El software de interrogación son programas o conjuntos de programas que permi-ten, a través de órdenes sencillas y de pequeño formato, o a través de menús y te-clas de función, generar programas que realizan funciones típicas de muestreo al azar, muestreo según otros criterios, inspección y captura de ficheros y bases de datos, estudios estadísticos, edición de informes, etc.

El auditor también puede utilizar para estos fines los lenguajes de interroga-ción asociados a los gestores de bases de datos relacionales, como ORACLE, IN-GRES, DB2 (IBM), ADABAS, etc., para acceder a información que se mantiene en estas bases de datos.

Los lenguajes específicos para auditoría pueden ser productos como CARS, DYL AUDIT y CA-EASYTRIEVE.

2.2.12 Simuladores y analizadores de sistemas operativos

Por lo que respecta al análisis del sistema, los auditores informáticos emplean pro-ductos que comprueban los valores asignados por Técnica de Sistemas a los pará-metros variables de las Bibliotecas más importantes del mismo. Estos parámetros deben estar dentro de un intervalo marcado por el fabricante. Cuando la compleji-dad es demasiado grande para evitar la alteración del sistema, o en situaciones es-peciales, se aplica unos productos llamados simuladores, que emulan el comporta-miento de un pequeño subsistema. Hay simuladores basados en productos software, y otros que usan una mezcla de hardware y software. Por ejemplo, en el diseño de redes de comunicaciones se suele usar los productos TPNS, GPSS, SNAPSHOT, MDMS, NETPAC y SIMSCRIPT II.5. Hay otros que emplean la filosofía de orien-tación a objetos, como el MODSIM III.

2.2.13 Monitores

Son productos software, hardware o mixtos, que miden el comportamiento de un sistema o componente del sistema, en una situación e instante real. Se diferencian de los simuladores en que éstos predicen o infieren el comportamiento de un ele-mento, mientras que los monitores sólo miden, no provocan determinadas situacio-nes. Los monitores suelen ser productos muy dependientes de la instalación en que trabajan, o dependientes del sistema de base de datos, por lo que no abundan pro-ductos estándar comerciales.

CAPÍTULO 2 51

2.2.14 Software de Re-Ingeniería e Ingeniería Inversa

La Re-Ingeniería es el proceso que toma un programa en código fuente, lo introdu-ce en una herramienta CASE para su modificación y mejora, y entonces vuelve a generar el código en una forma mas comprensible y fácil de mantener. Las herra-mientas de Re-Ingeniería permiten manipular código fuente en el módulo tanto a nivel de fichero como a nivel de instrucción de lenguaje individual. Permiten rees-tructurar y transformar grandes cantidades de código con relativa facilidad, y ade-más, en la mayoría de las veces, de forma automática.

La Ingeniería Inversa es el proceso que toma un programa en código fuente, lo introduce en una herramienta CASE y reproduce toda la documentación pertinente que se puede utilizar en el análisis y diseño de dicho programa: diagramas de flujo, descripciones de registros, diccionario de datos, etc. En este caso, el producto final es la documentación de análisis, contrariamente al proceso de Re-Ingeniería.

La mayoría de los buenos productos de CASE incorporan funciones de Re-Ingeniería e Ingeniería Inversa. Entre ellos tenemos el EXCELERATOR (Index Technology Corp.), ProMod (Promod Inc.), y Teamwork (Cadre Technologies Inc.).

2.2.15 Paquetes de auditoría (CAAT)

Los paquetes de auditoría son programas o conjuntos de programas que incorporan de entrada todas las funciones básicas de auditoría, formando una unidad operativa integrada, o a través de menús gráficos y teclas de función, o a través de entornos gráficos (Microsoft Windows, X-Window, etc.). Son paquetes especializados en auditoría e, incluso, en determinados aspectos de la actividad de auditoría, o en la auditoría de entornos especializados de los Sistemas de Información.

"CAAT" es el acrónimo de "Computer Aided Auditing Techniques", que signi-fica, Técnicas de Auditoría Asistidas por Ordenador. Comprenden herramientas de auditoría que pueden ser útiles a los auditores de los distintos tipos de auditorías y no solamente a los auditores informáticos. De hecho, algunas de estas herramientas surgieron inicialmente para el ámbito de la auditoría financiero-contable.

Son productos cuyas últimas versiones funcionan sobre plataformas PC, bajo entornos DOS y Windows, e incluso sobre estaciones de trabajo UNIX. Los más conocidos son: CA-PANAUDIT (Computer Associates), AUDIT (AUDIRFOR, S.A.), LANAuditor (ECONOMIC DATA, S.L.), e IDEA (UNIAUDIT- GRANT THORNTON).


Hay otros productos de reciente aparición, o más sofisticados, o para instala-ciones de marcas específicas que no son muy conocidos todavía, y son los siguien-tes: ACL (ACL Software), WizRule for Windows (WizSoft), VSA (Vanguard Inte-grity Professionals), Consul/Audit (Consul risk management b.v.) y Audit & Con-trol Program Mentor (Angel Group).

Mención especial merece el proyecto CobiT (Control Objetives for IT), pro-movido por la Information Systems Audit and Control Foundation, cuyo producto final, del mismo nombre, es un moderno y estandarizado conjunto de Objetivos de Control de las Tecnologías de Información generalmente aceptados para la utiliza-ción diario de los ejecutivos y auditores de Sistemas de Información.

Desarrollaremos en las secciones posteriores una descripción más detallada de cada una de estas herramientas, debido a su mayor importancia en cuanto al resto de herramientas descritas anteriormente.

2.3 Técnicas de Auditoría Asistidas por Ordenador (CAAT's)

En esta sección desarrollaremos con mayor detalle las herramientas cla sificadas en el grupo de CAAT y que hemos mencionado en la sección 8.2.15.

2.3.1 IDEA. Interactive Data Extraction and Analysis (Uniaudit- Grant Thornton)

2.3.1.1 Introducción

El Instituto Canadiense de Auditores de Cuentas (CICA), anticipándose a las nece-sidades de los auditores, creó en 1987 un programa de extracción y análisis de in-formación, como respuesta a la creciente automatización informática de la contabi-lidad de las empresas. El producto en cuestión es IDEA (Interactive Data Extrac-tion and Analysis) y tuvo gran aceptación desde su primera versión.

En los últimos años el CICA ayudado por algunas multinacionales ha mejora-do el producto original hasta llegar a la versión cuarta, considerada por los audito-res y analistas (sus principales usuarios) como la más completa aplicación de inter-rogación y extracción de datos.

El atractivo de IDEA estriba en la combinación de un alto grado de funciona-lidad con la sencillez de uso. El producto IDEA, aunque complejo y potente, no

CAPÍTULO 2 53

requiere conocimientos previos, a pesar de esto, la nueva versión incorpora un cur-so de formación.

Proporciona un entorno de trabajo en modo texto, basado en menús, suscepti-bles de ser personalizados, y con posibilidad de trabajar mediante ratón o teclas rápidas. En el nuevo producto se conservan las características de sus predecesores, pero se incrementan su funcionalidad, velocidad y aplicaciones.

Constituye un apoyo en todas las labores del auditor, con una completa pista de auditoría, permitiendo clasificar los trabajos y mantener un historial de las ope-raciones realizadas, dotando a cada proyecto una clave de acceso. La aplicación permite la exportación e importación de ficheros de datos en multitud de formatos y de diferentes aplicaciones. Además admite multitud de tipos de unidades de al-macenamiento.

En general responde a las necesidades de todo auditor, ya que es una herra-mienta creada por auditores, para auditores. Dispone de miles de usuarios, incluso organismos gubernamentales. Proporciona una herramienta eficaz tanto en audito-ría interna como externa. Y su utilización es sencilla.

2.3.1.2 Auditoría Informatizada: CAAT’S y Micro CAT’S

La revolución informática se ha extendido a todos los ámbitos, incluyendo el de la auditoría y sus ámbitos de estudio o trabajo, afectando a su enfoque tradicional de trabajo.

¿Qué puede hacer el auditor ante la revolución informática en el campo de la contabilidad?

La única respuesta es la informatización de la auditoría.

El auditor se encuentra cada vez más con el problema de la reducción de las pistas de auditoría documentadas, puesto que todas las empresas se automatizan y pasan a guardar la información en medios magnéticos, y no sobre papel como vení-an haciendo.

El manipular la información con un ordenador no es todo lo fiable que se des-ea. La gran variedad de modelos de ordenador, aplicaciones y capacidad de poder manipular la información al antojo de uno, hacen que uno de los objetivos que se plantee el nuevo auditor, sea el de revisar la fiabilidad de la información.


Estos y otros muchos problemas, hacen necesaria la informatización de la au-ditoría, permitiendo un mejor reparto del tiempo del auditor y una dedicación ma-yor a tareas donde todavía no se puede operar con ordenador.

Una aplicación informática en el trabajo de auditoría supone una mejora de los métodos tradicionales. Los objetivos que se deben buscar son cuatro:

• Mejorar la eficacia y reducir los costes de auditoría.

• Incrementar la calidad y reducir el riesgo de auditoria.

• Reducir el tiempo de obtención de la información.

• Permitir que personal menos cualificado realice tareas que antes necesita-ban de un auditor con experiencia.

Los ingredientes esenciales para lograr la informatización de la auditoría son cinco:

• Objetivos claros.

• Hardware de calidad.

• Software de calidad.

• Buena predisposición del personal.

• Gestión o dirección eficiente.

Sin embargo, el soporte informático de ayuda a la auditoría no es barato. Pero, como respuesta a las necesidades urgentes del nuevo auditor, surgen las Técnicas de Auditoría Asistidas por Microordenador. Estas aplicaciones se engloban bajo el nombre de CAAT’s o MCAT’s. Constituyen métodos revolucionarios destinados a incrementar la eficacia de la auditoría y a disminuir los costes de los trabajos. Además presentan ventajas adicionales:

• Entorno familiar: En lugar de tener que utilizar los equipos de los clientes, el auditor trabaja siempre en el mismo entorno informático.

• No más retrasos de trabajo: El equipo del auditor está siempre disponible, no como ocurría con los de la empresa a ser auditada.

• Integración: Una vez se dispone de la información necesaria es posible uti-lizarla con otros programas.

• Entorno Protegido: El auditor tiene libertad de movimientos en su equipo de trabajo, no sujeto a objeciones del cliente, y con las medidas de seguri-dad necesarias.

• El final del trabajo rutinario: Se informatizan los trabajos tediosos.

CAPÍTULO 2 55

Las herramientas de extracción, análisis y muestreo de datos, que también re-

ciben el nombre de herramientas de interrogación de ficheros, son quizá el CAAT que más se utiliza, por su considerable ahorro de trabajo. Un ejemplo de estas herramienta lo constituye el paquete IDEA.

2.3.1.3 IDEA: Una herramienta de interrogación

Como ya hemos comentado anteriormente IDEA es un producto software que per-mite al auditor o al analista, automatizar tareas que resultan tediosas y fácilmente manipuladas por el ordenador, permitiendo emplear el tiempo en otras labores más delicadas.

Como en breve comentaremos, es una herramienta de apoyo en labores de análisis de información, y cubre la tarea desde el principio, extrayendo la informa-ción de la empresa a ser auditada, hasta el final, generando documentación de los resultados del estudio de la información contable.

En general, una labor de interrogación con IDEA seguirá los pasos siguientes:

• Obtener el fichero de información en formato micro.

• Ubicar el fichero dentro de un proyecto, asignándole una clave de acceso.

• Hacer reconocible la información para el programa IDEA (importarlo).

• Realizar el análisis.

• Imprimir informes de resultados.

• Exportar los resultados a otras aplicaciones.

• Hacer backups de los ficheros y de los resultados obtenidos.

• Borrar los proyectos acabados del disco.

La identificación del usuario al comenzar una sesión con IDEA es importante, ya que permite el acceso restringido a los distintos clientes y proyectos. También existe la posibilidad de manipular los menús para realizar una restricción de fun-ciones por usuarios.

La aplicación almacena automáticamente una pista de los ficheros que se hallan bajo su control y de la utilización de los mismos. Esto permite saber en todo momento el trabajo realizado sobre un fichero, manteniendo una pista de auditoría y un historial que puede ser accedido en cualquier momento, y en el que se pueden incluir comentarios.


2.3.1.4 Descripción de la versión 4.0

8.3.1.4.1Funciones de extracción y análisis

Este es el área principal de trabajo de IDEA y provee al auditor de las herramientas necesarias para realizar los análisis y producir la documentación.

• Funciones de Extracción: Permiten extraer registros de un archivo mediante algoritmos de extracción. El programa es capaz de generar los algoritmos interactivamente con el usuario, o dejar a éste la labor de confección. Una función adicional permite almacenar al-goritmos importantes en un catálogo. Virtualmente se genera un nuevo archivo con los registros de interés, pero físicamente, lo que realmente se almacena en disco, es la definición lógica y no la información. De esta forma se evita duplicar información.

• Indexación y Clasificación: Son dos formas de reorganizar la información de un archivo, que no estaba en el orden adecuado, utilizando claves de ordenación. La Clasificación genera un ar-chivo equivalente con el orden deseado. La Indexación, menos costosa, genera simplemente un archivo índice de referencias al original.

• Funciones de Análisis: Engloba un conjunto de funciones, utilizadas a menudo, en el análisis de infor-mación. A continuación se exponen estas funciones comentando las más impor-tantes:

• Estratificación de Ficheros. Permite totalizar un campo determinado en aquellos registros que cumplan unos determinados requisitos de rango de valores.

• Resumir Campos Clave. Cuando un fichero contiene numerosos registros con un campo que contiene los mismos valores, podemos resumir la in-formación, generando un nuevo archivo que contenga el campo clave, el número de registros y los totales de los campos numéricos.

• Gráficos de barras. Permite generar gráficas de la información resumida.

• Estadísticas de Campos. Permite calcular distintos estadísticos de hasta 32 campos en una sola pasada.

CAPÍTULO 2 57

• Análisis de Antigüedad. Permite averiguar la antigüedad de un registro.

• Comparar dos Archivos. Muestra si un campo particular contenido en un fichero posee el mismo valor que otro campo de otro fichero dis tinto, per-mitiendo conocer las diferencias existentes.

• Detección de Espacios Vacíos. Permite detectar cualquier salto o vacío de los valores de un determinado campo, como puede ser el número de factu-ra, que debería contener valores correlativos.

• Detección de Duplicados. Es la función contraria a la anterior y permite detectar elementos duplicados, como podría ser la contabilización de un cheque.

• Funciones de Muestreo: Permiten utilizar cinco métodos de muestreo: Sistemático, Aleatorio, Generación de Números Aleatorios, de Atributos y de Unidades Monetarias.

• Funciones de Manipulación de Campos: Permiten modificar la información una vez ésta ha sido importada. Entre otras está la posibilidad de fusionar dos archivos, modificar y eliminar campos, así como introducir campos de control virtuales (no se graban en disco, sino que se calculan cuando se necesitan).

• Visualizar/ Imprimir Ficheros: Permite lo propio con cualquier información o resultado de análisis manejados por el programa.

• Funciones de Manipulación de Informes: Permiten la confección y edición de los informes a medida que se suelen incor-porar en la documentación de los trabajos realizados. El soporte es el que pro-porcionaría cualquier procesador de texto en cuanto a encabezados, pies, títulos, etc.


8.3.1.4.2Otras opciones

• Importar y Unir Datos: Antes de que pueda ser utilizada por el programa IDEA, la información debe im-portarse en forma de archivo. Para ello se deberán especificar los parámetros re-ferentes al formato y estructura de campos que contiene el archivo fuente. Ade-más en ocasiones esto no es necesario, ya que el programa reconoce automáti-camente muchos tipos distintos de archivos.

• Funciones de Exportación de Datos: De forma parecida, la información generada por la aplicación, puede ser expor-tada a otras aplicaciones, como pueden ser procesadores de texto u hojas de cál-culo. En este área IDEA también reconoce los formatos de diferentes platafor-mas.

• Gestión de Clientes: Se puede mantener por separado la información de diferentes clientes o proyec-tos de auditoría. También se pueden asociar claves de acceso a los distintos ar-chivos.

• Funciones de Gestión de Ficheros y otras Utili-dades:

Son un conjunto de herramientas útiles para gestionar los archivos internamente por el programa, permitir ejecutar ordenes del DOS o incluir en los menús apli-caciones de uso habitual:

• Fusionar ficheros.

• Backup y Restauración de Ficheros.

• Suprimir ficheros e índices.

• Gestión de Ficheros en el DOS.

• Editar un Fichero de Texto.

• Salir Temporalmente al DOS.

• Funciones de Configuración.

• Otras Aplicaciones.

CAPÍTULO 2 59

2.3.2 CobiT. Control Objetives for IT (Information Systems Audit and

Control Foundation)

2.3.2.1 Introducción

El proyecto CobiT (Control Objetives for IT), fue promovido por la Information Systems Audit and Control Foundation con la colaboración de grupos de trabajo internacionales, para obtener un producto de auditoría, con el mismo nombre. Co-biT es un moderno y estándar conjunto de Objetivos de Control de las Tecnologías de Información generalmente aceptados para la utilización diaria de los ejecutivos y auditores de Sistemas de Información.

2.3.2.2 La Information Systems Audit and Control Foundation

La Information Systems Audit and Control Foundation es una fundación de la In-formation Systems Audit and Control Association (ISACA), organización profe-sional con 14.000 miembros en todo el mundo que están trabajando en la auditoría, el control y la seguridad de los sistemas de información. Se fundó en 1969 como la EDP Auditors Association, y actualmente la misión de ISACA es la de mejorar el reconocimiento de la profesión de auditoría y control de los sistemas de informa-ción a través de la elaboración de estándares y prácticas, formación y certificación. La Information Systems Audit and Control Foundation está encargada de trabajos de investigación para producir materiales de referencia y para establecer estándares profesionales que dirijan la práctica en las áreas tecnológicas para el beneficio de la comunidad global de Sistemas de Información.

2.3.2.3 Introducción a CobiT

CobiT está diseñado como un estándar aplicable y aceptable en general para la buena práctica de la auditoría de las tecnologías de la Información en todo el mun-do. El producto CobiT utiliza los Objetivos de Control de ISACA, mejorados con estándares específicos de tipo técnico, profesional, normativo e industrial existen-tes y emergentes. Los objetivos de control se han desarrollado para su aplicación en el amplio espectro de sistemas de información en la empresa. El término "general-mente aceptado" se utiliza explícitamente en el mismo sentido que en los PCGA (Principios Contables Generalmente Aceptados).

En las reuniones iniciales, los planificadores identificaron que el estándar de-bía ser pragmático, relativamente reducido en tamaño, y suficiente para las necesi-dades de gestión al mismo tiempo que se mantuviera independiente de las instala-ciones de TI adoptadas en una organización. Tenía que identificar cualquier indica-


dor de rendimiento. La capacidad de un marco de cualificación tenia una prioridad secundaria. El desarrollo tenía que dar lugar a un producto final comercial, segui-do de actividades de promoción y educación para asegurar la introducción y adop-ción extensas de los objetivos de control de TI mejorados. La mejora consistía en lo siguiente:

• • Adecuación a los estándares y normativas legislativos y de hecho existentes que se aplican en el marco global, así como en los objetivos de control individuales.

• • Revisión crítica de las diferentes actividades y tareas bajo los do-minios de control y posibilitando la especificación de indicadores de presta-ciones importantes (normas, reglas, etc.).

• • Establecimiento de unas directrices y fundamentos para proporcio-nar investigación consistente sobre los temas de auditoría y control de TI.

Se ha contado con la colaboración de grupos de trabajo distribuidos por todo el mundo para aportar seguridad en la calidad y revisión experta de los trabajos de investigación en el proyecto y en el desarrollo de la documentación.

Se ha contado con el asesoramiento de equipos de investigación académicos y profesionales que han coleccionado y analizado recursos en Europa (Free Universi-ty of Amsterdam), los EE.UU. (California Politechnic University) y Australia (University of New South Wales).

Después de la colección y análisis de los recursos, los investigadores examina-ron cada dominio y procedieron en profundidad y sugirieron nuevos objetivos de control aplicables a cada proceso de tecnología de la información particular. Los investigadores compilaron, revisaron, evaluaron e incorporaron estándares técnicos internacionales, códigos de conducta, estándares de calidad, estándares de auditoría profesionales, requisitos y prácticas en la industria, y requisitos específicos de la industria emergentes en la medida en que se relacionaban con los objetivos de con-trol globales e individuales. Estos esfuerzos han producido más de 300 objetivos de control nuevos y actualizados a considerar por los inspectores de calidad y grupos de expertos.

La consolidación de los resultados se realizó principalmente en el Equipo de Proyecto, compuesto por el Directos del Proyecto, el Gestor del Proyecto y el Di-rector de Investigación de la ISACA/F. La exposición, promoción y publicación de estos resultados han estado a cargo de la ISACA/F.

CAPÍTULO 2 61

2.3.2.4 La necesidad del Control en las Tecnologías de In-formación

Hay una creciente necesidad entre las administraciones de las empresas y los usua-rios de los servicios de TI de obtener confianza en la seguridad y el control a través de la acreditación y la auditoría de los servicios de TI aportadas por unidades inter-nas u organizaciones externas. En el presente, sin embargo, la implantación de un buen control de TI en los sistemas de gestión - sean comerciales, no lucrativos, gubernamentales, etc.- esta dificultada por la confusión provocada por los distintos esquemas de evaluación que existen actualmente (por ejemplo ITSEC, TCSEC, evaluaciones de ISO9000, evaluaciones de control interno del COSO emergentes, etc.). Por tanto, entendemos que se ha de establecer un fundamento general para todos.

CobiT se desarrollo para establecer un fundamento general que pudiera apli-carse en la gestión como ayuda en el balance de riesgos y en el control de la inver-sión en un entorno de TI a menudo impredecible; por auditores de SI para sustan-ciar sus opiniones sobre los controles internos y de gestión; y por las administra-ciones de las empresas y usuarios para que puedan obtener confianza en la seguri-dad y el control de los servicios de TI proporcionados por unidades internas o por terceras partes.

2.3.2.5 Definición y evolución del producto

El producto básico consiste en un sistema para el control en TI basado en criterios de gestión y documentado por objetivos de control organizados por dominios, pro-cesos y actividades de TI. Cada una de estas áreas tiene, además de un conjunto de objetivos de control, una definición y una base lógica para el control. Este producto llegará a ser el punto de partida para futuras investigaciones.

Se han identificado una segunda y tercera fases en el proyecto CobiT. Para ca-da una de estas fases, las tareas y actividades de TI que sirven como estructura para organizar los objetivos de control de TI se refinarán y publicarán durante 1996 y 1997 respectivamente.

2.3.2.6 Objetivos y Criterios de Gestión

Para satisfacer los objetivos de gestión, la información debe cumplir ciertos criterios referidos como requisitos de gestión. Al establecer la lista de requisitos, se combinan los principios contenidos en modelos existentes y conocidos:

• • Requisitos de Calidad:

• Calidad.


• Coste.

• Distribución.

• • Requisitos Fiduciarios (Informe COSO):

• Efectividad y eficiencia de las operaciones.

• Fiabilidad de los estados financieros.

• Cumplimiento con las leyes y las normas.

• • Requisitos de Seguridad:

• Confidencialidad.

• Integridad.

• Disponibilidad.

Empezando por los anteriores requisitos de Calidad, Fiduciarios y de Seguri-dad, se han identificado siete categorías distintas pero no disjuntas. Sus definicio-nes son las siguientes:

• Efectividad: maneja información que es importante y pertinente para el proceso de gestión así como la que se distribuye de una forma oportuna, correcta, consistente y manejable.

• Eficiencia: corresponde a la provisión de información en la forma menos costosa.

• Integridad: referido a la precisión y completitud de la información así como su validez de acuerdo con el conjunto de valores y presupuestos de gestión.

• Confidencialidad: corresponde a la protección de la información sensible frente a una revelación no autorizada.

• Disponibilidad: referido a la información que esté disponible cuando lo requiera el proceso de gestión, y también corresponde a la salvaguarda de los recursos.

• Cumplimiento: trata del cumplimiento con las leyes, reglas y acuerdos contractuales a los cuales se somete el proceso de gestión.

• Fiabilidad de los estados financieros: los estados financieros deben ser fiables y presentarse completamente de acuerdo con los PCGA, al mismo tiempo que debe tener en cuenta la existencia u ocurrencia, completitud, derechos y obligaciones, evaluación o localización, y presentación y reve-lación de esta información.

La información que los procesos de gestión necesitan está proporcionada por el uso de los recursos de TI. Para asegurar que los requisitos de gestión para la

CAPÍTULO 2 63

información se aplican, se tiene que definir medidas de control adecuadas, se tiene que implementarlas y monitorizarlas sobre estos recursos. Está claro que no todas las medidas de control satisfarán los requisitos de gestión en el mismo grado, así que se hace una distinción en el sistema CobiT contemplando el cumplimiento primario y secundario:

• Primario: grado en que el objetivo de control satisface completamente el requisito de información correspondiente.

• Secundario: grado en que el objetivo de control satisface solamente en menor extensión o indirectamente el requisito de información correspon-diente.

El sistema consiste en objetivos de control de TI de alto nivel y una estructura global para su clasificación y funcionamiento. La teoría subyacente para la clasifi-cación elegida, en línea con las experiencias de Re-Ingeniería, es que hay, en esen-cia tres niveles de esfuerzos en TI cuando se considera la gestión de los recursos de TI. Estos son actividades, procesos y dominios:

• • Actividades: las actividades, junto con las tareas están en el nivel inferior. Las actividades tienen el concepto de ciclo de vida mientras que las tareas se consideran discretas en el tiempo.

• • Procesos : se definen en un nivel superior como series de activida-des unidas con puntos de control naturales.

• • Dominios: correspondientes al nivel superior, son agrupaciones de procesos. CobiT distingue cuatro dominios en línea con el ciclo de gestión o el ciclo de vida aplicables a los procesos de TI:

• Planificación y Organización: conduce la estrategia y las tácticas y co-rresponde a la identificación de la forma en que la información tecnológica puede contribuir mejor a alcanzar los objetivos de gestión.

• Adquisición e Implementación: para llevar a cabo la estrategia es necesa-rio identificar, desarrollar y adquirir soluciones de TI apropiadas, así como implementarlas e integrarlas en el procesos de gestión.

• Distribución y Soporte: corresponde con la distribución normal de los servicios requeridos, que van desde las tradicionales operaciones sobre se-guridad y continuidad hasta la formación.

• Monitorización: todos los procesos de TI deben evaluarse regularmente en el tiempo para comprobar su calidad.


2.3.2.7 El manejo del sistema CobiT

El marco conceptual se enfoca desde tres puntos de vista distintos: criterios de gestión para la información, recursos de TI y procesos de TI. Estos tres puntos de vista se ensamblan en un formato cúbico y permiten que se obtengan referencias cruzadas en dicho marco y se pueda acceder a él eficientemente.

Los objetivos de control de TI están organizados inicialmente por proce-so/actividad, pero las ayudas para la navegación que se aportan, facilitan la entrada desde cualquier punto estratégico. También facilitan la adopción de enfoques com-binados o globales, tal como la instalación/implementación de un proceso, respon-sabilidades de gestión global para un proceso, y el uso de los recursos de TI por un proceso.

Con el propósito de tener documentación apta para publicar, el sistema CobiT está limitado a los objetivos de control de alto nivel en la forma de una necesidad de gestión sobre un proceso de TI particular. El requisito de gestión se alcanza a través de una instrucción de control y se puede considerar controles potencialmente aplicables.

3. El marco metodológico para la ASI

La Information Systems Audit and Control Association (ISACA), es una aso-ciación profesional de ámbito mundial (más de 40.000 asociados individuales e institucionales) para la regulación de la práctica de la Auditoría de Sistemas de Información cuya sede esta en EE. UU. (http://www.isaca.org). En algunos países la ISACA tiene reconocimiento oficial como la institución reguladora del ejercicio de sus auditores informáticos, con unas competencias similares a los organismos que controlan la actividad de auditoría de cuentas. En otros países, como España, el reconocimiento es tácito ya que no existen normas legales específicas.

Como resultado de un proceso relativamente largo, donde los miembros de la ISACA han ido aportando sus ideas, sugerencias y experiencia, se publicó en 1997 la primera versión de un marco metodológico formal denominado COBIT (Control Objectives for Information and related Technology - Objetivos de Control para la Información y Tecnologías Afines). COBIT, por tanto, está ampliamente aceptado por la comunidad internacional de auditores de sistemas de información como una norma estándar.

CAPÍTULO 2 65

3.1. Breve introducción a COBIT

La Misión de COBIT es la siguiente: “Investigar, desarrollar, publicar y pro-mover un conjunto de objetivos de controlen tecnología de información con autori-dad, actualizados, de carácter internacional y aceptados generalmente para el uso cotidiano de gerentes de empresas y auditores.” (ISACAF-EXS, 2000).

COBIT está diseñado como un estándar aplicable y aceptable en general para la buena práctica de la auditoría de las tecnologías de la Información en todo el mundo. El producto COBIT utiliza los Objetivos de Control de ISACA, mejorados con estándares específicos de tipo técnico, profesional, normativo e industrial exis-tentes y emergentes. Los objetivos de control se han desarrollado para su aplicación en el amplio espectro de sistemas de información en la empresa. Estos objetivos de control tienen en cuenta lo siguiente:

• Adecuación a los estándares y normativas legislativos y de hecho existentes que se aplican en el marco global, así como en los objetivos de control individuales.

• Revisión crítica de las diferentes actividades y tareas bajo los dominios de control y posibilitando la especificación de indicadores de prestaciones importantes (normas, reglas, etc.)

• Establecimiento de unas directrices y fundamentos para proporcionar investigación consistente sobre los temas de auditoría y control de Tecnologías de Información (TI).

COBIT se ha diseñado como sistema metodológico que consiste en un conjun-to de objetivos de control de TI de alto nivel y una estructura global para su clasifi-cación y funcionamiento(Véase la Figura 2).


Figura 2. Recursos de TI, Objetivos de Negocio y Dominios de COBIT “Copyright 1996, 1998, 2000 Information Systems Audit and Control Foundation.

Reprinted with the permission of the Information Systems Audit and Control Foundation and IT Governance Institute.”

3.2. Estructura y Objetivos de Control

La teoría subyacente para la clasificación elegida, en línea con las experien-cias de Re-Ingeniería, es que hay, en esencia, tres niveles de esfuerzos en TI cuan-do se considera la gestión de los recursos de TI:

CAPÍTULO 2 67

• Actividades: Las actividades, junto con las tareas están en el nivel

inferior. Las actividades tienen el concepto de ciclo de vida mientras que las tareas se consideran discretas en el tiempo.

• Procesos: Se definen en un nivel superior como series de actividades unidas con puntos de control naturales.

• Dominios: Correspondientes al nivel superior, son agrupaciones de procesos. COBIT distingue cuatro dominios en línea con el ciclo de gestión o el ciclo de vida aplicables a los procesos de TI (Véase la Tabla 2):

Planificación y Organización:

Conduce la estrategia y las tácticas y corres-ponde a la identificación de la forma en que la información tecnológica puede contribuir mejor a alcanzar los objetivos de gestión.

Distribución y Soporte:

Corresponde con la distribución normal de los servicios requeridos, que van desde las tradi-cionales operaciones sobre seguridad y conti-nuidad hasta la formación.

Adquisición e Implementación:

Para llevar a cabo la estrategia es necesario identificar, desarrollar y adquirir soluciones de TI apropiadas, así como implementarlas e integrarlas en los procesos de gestión.

Monitorización:

Todos los procesos de TI deben evaluarse regularmente en el tiempo para comprobar su calidad.

Tabla 2. Dominios de COBIT

El marco conceptual se enfoca desde tres puntos de vista distintos: criterios de gestión para la información, recursos de TI y procesos de TI. Estos tres puntos de vista se ensamblan en un formato cúbico y permiten que se obtengan referencias cruzadas en dicho marco y se pueda acceder a él eficientemente (Véase la Figura 3).


Figura 3. El cubo de COBIT “Copyright 1996, 1998, 2000 Information Systems Audit and Control Foundation.


Los objetivos de control de TI están organizados inicialmente por proceso / actividad, pero las ayudas para la navegación que se aportan, facilitan la entrada desde cualquier punto estratégico. También facilitan la adopción de enfoques com-binados o globales, tal como la instalación / implementación de un proceso, res-ponsabilidades de gestión global para un proceso, y el uso de los recursos de TI por un proceso (Véase la Figura 4).

CAPÍTULO 2 69

Figura 4. Objetivos de control de COBIT definidos genéricamente “Copyright 1996, 1998, 2000 Information Systems Audit and Control Foundation.


La información que los procesos de gestión necesitan está proporcionada por el uso de los recursos de TI. Para asegurar que los requisitos de gestión para la información se aplican, se tiene que definir medidas de control adecuadas, se tiene que implementarlas y monitorizarlas sobre estos recursos. Está claro que no todas las medidas de control satisfarán los requisitos de gestión en el mismo grado, así que se hace una distinción en COBIT contemplando el cumplimiento:

Primario (P): grado en que el objetivo de control satisface completamente el requisito de información correspondiente.

Secundario (S): grado en que el objetivo de control satisface solamente en menor extensión o indirectamente el requisito de información correspon-diente.


Figura 5. Tabla resumen de COBIT “Copyright 1996, 1998, 2000 Information Systems Audit and Control Foundation.


2.4 Bibliografía

[1] Acha Iturmendi J.J. Auditoría Informática en la empresa. Paraninfo, Madrid, 1994.

[2] Alonso Rivas G. Auditoría Informática.Díaz de Santos, Madrid, 1989.

[3] Auerbach Publishers. EDP Auditing. Auerbach Publishers, Orlando (USA), 1989

[4] Badiru a. b., Whitehouse G. E. Computer Tools, Models and Techniques for Pro-ject Management. Tab Books, Blue Ridge Summit, PA, 1989.

[5] Casals Creus, R Fundamentos de auditoría.3ª ed. Instituto de auditores-censores jurados de cuentas de España, Madrid, 1992.

[6] Chu G.T. "Expert Systems in Computer Based Auditing". EDP Auditor Journal, vol I, 1989.

[7] Davis G.B., Adams D.L., Schaller C.A.Auditing & EDP.2ª ed. American Insti-tute of Certified Public Accountants. New York, 1983.

[8] Davis G.B., Rittenberg L.E., O'Sullivan J. J. Auditing & EDP.2 ed. Study Guide. American Institute of Certified Public Accountants. New York, 1983.

[9] De Juan Rivas A., Pérez pascual A. La auditoría en el desarrollo de proyectos in-formáticos. Díaz de Santos, madrid, 1988.

CAPÍTULO 2 71

[10] Derrien Y. Técnicas de la Auditoría Informática. Marcombo, Barcelona, 1994.

[11] Fernández Peña E. Diccionario de Auditoría, 1989.

[12] Fisher A. S. CASE. Using Software Development Tools. 2nd. ed. John Wiley, New York, 1991.

[13] Grupp B. La gestión del departamento de informática. Organización. Dirección. Información. Hispano Europea, S.A., Barcelona, 1985. ESADE. Estudios de la Empresa.

[14] Hannan J. Gestión de las Operaciones del Centro de Explotación de Datos. Edi-ciones Arcadia, S.A, Madrid, 1984. Guías Prácticas CHIP-AUERBACH.

[15] Instituto de Directivos de Empresa. Seminario de Auditoría Informática. Master de Informática para directivos. Instituto de Directivos de Empresa. Madrid, 1991.

[16] Iskandar M., Mc Mann P. "EDP Auditor Journal". EDP Auditor Journal, vol IV, 1989

[17] Coopers & Lybrand. Manual de auditoría Coopers & Lybrand. Diorki, Bilbao-Deusto, 1989

[18] Martínez García, F. J. Auditoría de cuentas. Cuestiones y supuestos prácticos. Enunciados y soluciones, 1ª ed. Jucar, Madrid, 1989.

[19] Millán Fernández, W. Auditoria empresarial. 2ª ed. Instituto de Contabilidad y Auditoria de Cuentas, Madrid, 1989.

[20] Mockler R.J. Knowledge-Based Systems for Management Decisions. Prentice-Hall International, Englewood Cliffs, NJ (USA), 1989.

[21] Montersinos Julve, V. ed. La Auditoría en Espanya situación actual y perspecti-vas. Servei de Publicacions de la Universitat de València, València, 1991.

[22] Pérez Pascual A., Juan Rivas A. La Auditoría en el desarrollo de proyectos in-formáticos. Díaz de Santos, Madrid, 1988.

[23] Porter Thomas, J.R. y Buston John C. Auditing: A Conceptual Approach. Wadswoz, Belmont, CA (USA), 1971

[24] Ramos González M.A. Contribución a la mejora de la Auditoría Informática me-diante la aplicación de métodos y herramientas de Ingeniería del Conocimiento. Tesis doctoral, Universidad Politécnica de Madrid, Madrid, Septiembre, 1990.

[25] Ros Mcdonnell L., Bernal Montañés R., Grau Gadea G., Ortíz Bas A., Chalmeta Rosaleñ R. Apuntes de gestión de Sistemas y Tecnologías de la Información. Servicio de Publicaciones de la Universidad Politécnica de Valencia, Valencia, 1995.

[26] SEDISI. Guía de Gestión de Programas de ordenador. SEDISI.


[27] The Journal of Information Systems Audit and Control Association. The EDP Auditors Association. Vol II, 1995.

[28] The Journal of Information Systems Audit and Control Association. The EDP Auditors Association. Vol III, 1995.

[29] Thomas A.J. Auditoría Informática, 2ª ed. Paraninfo,Madrid,1988.

[30] Thorin M.La Auditoría Informática. Métodos, Reglas, Normas.Masson, S.A., Barcelona, 1989. Manuales de Informática Masson

[31] Vallabhaneni S.R. CISA Volume 1: Theory (rev. 1996).SVR Professional Publi-cations, Schaumburg, Illinois (USA), 1996.

[32] Wallace, W. A. Handbook of internal accounting controls. 2nd ed. Englewood Cliffs, N.J. Prentice-Hall cop. 1991

[33] Waterman D. A guide to expert systems. Addison-Wesley, Boston, MA, 1986.

[34] Weber R. EDP Auditing. Conceptual Foundations and Practice. 2nd ed. McGraw-Hill, Sydney, 1988.

2.4 Índice de tablas

Tala 2.3. Descomposición del Subsistema de Dirección.............................................................11 Tabla 3.6. Niveles del Sistema en un proceso de transacciones.................................................12 Tabla 3.9. Pautas de selección para la elección de un sistema de aplicación específico

para una auditoría .........................................................................................................20 Tabla 2.1. Matriz (Probabilidad, amenaza, impacto) ...................................................................45 Tabla 2.2. Matriz (Amenaza, medida de cobertura, efecto) ........................................................46 Tabla 2.3. Matriz (Amenaza, recurso, medida de cobertura)......................................................46

2.4 Índice de figuras

Figura 3.5. Estructura de Control del Subsistema de Dirección.................................................12 Figura 3.7. Niveles del Sistema en un proceso de transacciones ...............................................13

Auditoria Informatica Modulo 2 %28pdf%29

Documents

Transcript of Auditoria Informatica Modulo 2 %28pdf%29