Auditoria Informatica Modulo 2 PDF

2
2. DESARROLLO GENERAL DE UNA AUDITORA. PROCESOS, METODOLOGAS, TCNICAS Y TECNOLOGAS
Objetivos
El objetivo principal del tema es el estudio de los conceptos fundamentales asociados al desarrollo general de una auditora, las descripcin de sus etapas, puntos de decisin y resultados finales de cada etapa de la auditora.
El objetivo principal del captulo es la presentacin de las herramientas que tiene a su alcance el auditor para facilitarle su trabajo. Como el examen de los sistemas de control y de informacin que realiza el auditor tiene muchos aspectos y de distinta naturaleza, as las herramientas que utiliza pueden ser de distinto tipo. La obtencin de informacin fiable y que proporcione confianza al auditor es una de las premisas para que cada una de las herramientas sea til.
AUDITORA INFORMTICA (ITIG)
2.1 Introduccin
En primer lugar estudiaremos los aspectos relacionados con la direccin de auditoras. Despus abordaremos el proceso general de una auditora. Y luego trataremos los resultados de la auditoria. En la Auditora tenemos, por orden de mayor importancia y generalidad, las normas, los procedimientos, las tcnicas y las herramientas. El auditor, en el desarrollo de su labor, ha de realizar su examen conforme a las normas tcnicas, oficiales o generalmente reconocidas, como reglas tcnicas y ticas. En el estudio de los distintos aspectos del sistema que est auditando, tiene que aplicar los procedimientos de auditora, que son las descripciones de los pasos que tiene que seguir para llevar a cabo con xito su investigacin. Segn la naturaleza del sistema o de la auditora, el auditor tiene a su disposicin una serie de tcnicas, que le ofrecen diversas alternativas contrastadas en la evaluacin de elementos especficos del sistema a auditar. Sin embargo, el auditor, solamente con su intelecto y sus manos, no puede llegar muy lejos en la obtencin y elaboracin de la informacin, y sobre todo cuando el entorno es muy especializado. Entonces, le hace falta un conjunto de herramie ntas que le facilite su labor y le ayude a obtener datos con mayor precisin y fiabilidad. Los mtodos es el conjunto de principios, reglas y prcticas que suministran la forma de desarrollar tcnicamente (el cmo) la auditora Las metodologas son los sistemas estructurados y organizados de principios, reglas y prcticas que se aplican a ramas del conocimiento especficas. Las herramientas es el conjunto de los el elementos que, mediante la estructuracin, clasificacin y automatizacin de determinados procedimientos de ingeniera y diseo, facilitan el trabajo del ingeniero al descargarle de tareas rutinarias, repetitivas o extremadamente exhaustivas, y permitirle centrarse en aspectos cualitativos o fundamentales. Suministran en resumen un soporte automtico o semia utomtico a los mtodos. Los procedimientos es el conjunto de facilidades que integran mtodos y herramientas en unidades metodolgicas operativas. Entre otras cosas, estas unidades definen las secuencias de aplicacin de los mtodos; describen y establecen los resultados de la culminacin de cada etapa de aplicacin de los mtodos, denominadas 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 tcnico en particular en la evaluacin del progreso en el desarrollo de sus actividades.
CAPTULO 2
Una herramienta de auditora, se puede definir como el elemento que, media nte la estructuracin, clasificacin y automatizacin de determinados procedimie ntos de auditora, facilita el trabajo del auditor al descargarle de tareas rutinarias, repetitivas o extremadamente exhaustivas, y permitirle centrarse en aspectos cualitativos o fundamentales. Las herramientas de auditora pueden ser de muchos tipos y presentarse en diversos soportes materiales, as como ser muy sencillas o bastante complicadas en su utilizacin. Tambin hay herramientas ms tradicionales y herramientas altamente innovadoras y especializadas, segn el grado de tecnologa 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 aplicacin. Esto significa que, para cualquier herramienta, el auditor debe recibir la formacin pertinente antes de poder utilizarla. Por otra parte, hay herramientas que son generales, es decir, que se pueden aplicar en otro tipo de actividades distintas de la auditora, y hay herramientas que son especficas de la auditora.
3.2 Proceso y Direccin de una Auditora de Sistemas de Informacin

Resulta una experiencia incomparable el llevar a cabo la Auditora de Sistemas de Informacin de una instalacin que tenga ms de 100 programadores y analistas, un gran ordenador, y miles de ficheros o tablas de Base de Datos. Obviamente, no todas las instala ciones de proceso de datos son de este tamao. Sin embargo, incluso en la instalacin ms pequea, es normalmente imposible para el auditor llevar a cabo una revisin detallada de todo el proceso de datos que se lleva a cabo en la instalacin. De modo que: Cmo puede la Auditora de Sistemas de Informacin realizarse de modo que el Auditor obtenga una garanta razonable de que la instalacin 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 seccin proporcionaremos una visin global del enfoque utilizado para llevar a cabo una Auditora de Sistemas de Informacin. En primer lugar, describiremos algunas tcnicas para simplificar y poner en orden la complejidad a la que se enfrentan los auditores cuando realizan juicios de evaluacin sobre sistemas. A continuacin examinaremos los efectos de un sistema de control interno en el entorno de auditora, despus discutiremos la relacin entre las prdidas espera-
das, errores e irregularidades. Tambin discutiremos la naturaleza de los controles informticos, para a continuacin dar una visin de los pasos en una ASI, y finalmente describir algunas de las decisiones ms importantes al llevar a cabo una ASI.
3.2.1 La gestin y organizacin de la Funcin de Auditora de Sistemas de Informacin

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 auditoras no se realizan por inspiracin 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 supervisan, asesoran, organizan, dirigen o ayudan, as como puede, a su vez, ejercer estas funciones sobre otros empleados. Para realizar una auditora necesita de una serie de recursos y que le proporcionen un conjunto de informaciones y documentacin. El auditor, en resumen, materializa e instancia la funcin de auditora. La funcin de auditora, como tal funcin, debe estar apoyada por una estructura organizada de profesionales y, adems, gestionada por los mismos profesionales. Tambin puede estar inmersa en el conjunto de funciones de una empresa, como funcin de auditora interna. Por otra parte, la funcin de auditora del Proceso Electrnico de Datos es una parte integral de la funcin de auditora global [31], aunque ha emergido con tal fuerza que se diferencia sensiblemente del resto de funciones de auditora. En esta seccin vamos a tratar de varios aspectos relacionados con la funcin de auditora de Proceso Electrnico de Datos: Necesidad e Independencia, Organizacin, Composicin, Relaciones con la direccin y otras organizaciones, Equipo de auditora y Gestin. 3.2.1.1 Consideraciones iniciales La necesidad de tener una seccin de auditora de Proceso Electrnico de Datos en las empresas de auditora, dentro de la organizacin general pero con entidad propia, se justifica por razones de competencia tcnica, incremento de independencia basado en la competencia tcnica informtica, y mejores y ms fluidas relaciones entre la direccin de auditora y la direccin de proceso de datos en base a la competencia tcnica. La agrupacin de auditores especialistas en Proceso Electrnico de Datos en una unidad con entidad propia, proporciona un nivel de independencia mayor con
CAPTULO 2
respecto del grupo de auditora en base al mayor conocimiento tcnico en Proceso Electrnico de Datos, tanto de cada uno de los componentes, como del grupo como unidad funcional. 3.2.1.2 Organizacin de la Funcin de Auditora La unidad funcional de auditora de Proceso Electrnico de Datos puede integrarse en la organizacin de auditora de dos formas distintas, en funcin de la naturaleza de las auditoras realizadas y de otras consideraciones postuladas por los tericos: puede estar como funcin de staff, asesorando a la direccin de auditora en materias tcnicas de su competencia (ver la Figura 3.1); o puede estar como funcin en lnea, como parte integral del equipo de auditora y con las responsabilidades tcnicas correspondientes en la realizacin de la auditora (ver la Figura 3.2).
1 Jefe de Auditora
2
Jefe Aud. Equipo 1
3
Jefe Aud. Equipo 2
4
Jefe Aud. PED
5 Auditor Staff Gral
7 Auditor Inf Especialista
Figura 3.1. La auditora de PED como funcin de Staff [Weber]
1 Jefe de Auditora
2 Jefe Aud. Equipo 1
3 Jefe Aud. Equipo 2
3 Jefe Aud. Equipo3
Figura 3.2. La auditora de PEd como funcin de lnea [Weber]
Los argumentos que justifican la funcin de auditora como funcin de staff son los siguientes:
1) Utilizacin ms eficiente de los recursos de auditora de Proceso Electrnico de Datos. 2) Mayor satisfaccin laboral del auditor de Proceso Electrnico de Datos. 3) Mayor compromiso de la organizacin hacia la funcin de auditora de Proceso Electrnico de Datos. 4) Facilidad de coordinacin y control. 5) Permite el incremento de la especializacin para cubrir las tecnologas complejas.
Los argumentos que justifican la funcin de auditora como funcin en lnea son los siguientes:
1) Mayor congruencia en los objetivos. 2) Facilidad en la comunicacin. 3) Mejora el conocimiento y experiencia en Proceso Electrnico de Datos de la direccin de auditora en cada equipo.
CAPTULO 2
3.2.1.3 Composicin y gestin de la Funcin de Auditora de Sistemas de Informacin No hay ninguna frmula que determine cuantos auditores de sistemas de informacin deben componer una unidad funcional. Adems, este nmero puede variar en funcin de las necesidades temporales de la organizacin de auditora. En grupos de auditora interna, el nmero de auditores de sistemas de informacin se puede fijar en base a los factores siguientes: tamao de la organizacin, naturaleza de la organizacin, extensin del uso de sistemas de informacin, tipos de sistemas informticos instalados, y estabilidad del entorno de Proceso Electrnico de Datos. En grupos de auditora externa, el nmero de auditores de sistemas de informacin est en funcin del nmero de clientes con instalaciones informticas y de la complejidad del proceso de datos realizado en las mismas. El origen de los auditores de sistemas de informacin suele ser de dos tipos: auditores de empresa o profesionales de proceso de datos. La eleccin de uno de los tipos y su posterior formacin puede realizarse en funcin de qu tipo de conocimiento es ms difcil de adquirir (auditora o proceso de datos) a la hora de abordar determinado tipo de auditoras. La formacin de los auditores de Sistemas de informacin la hemos tratado con bastante extensin en una seccin anterior. Por otra parte, se puede producir una evolucin del auditor de Sistemas de informacin hacia otras funciones por diversos caminos: funcin de especialista en el Sistemas de informacin, funcin de auditor, funcin operativa[10]. 3.2.1.4 Relaciones con la direccin y con otros grupos Uno de los objetivos fundamentales de la unidad funcional de auditora de Sistemas de informacin es el establecimiento de relaciones cordiales con los diversos estamentos de gestin dentro de la organizacin, sobre todo cuando se trata de auditora interna. Sin embargo, dada la naturaleza de la auditora 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 gestin: presiones de la direccin para actuar con demasiada rapidez, problemas de comunicacin con la organizacin y fricciones con otros grupos. Se puede aplicar algunas soluciones para paliar dichos problemas: promocin de comunicaciones abiertas entre las partes en conflicto, auditora en base a la capacitacin tcnica, asignacin de prioridad a las tareas que se pueden cumplir, y gestin adecuada de la funcin de auditora de Sistemas de informacin.
3.2.1.5 El equipo de auditora El equipo de auditora se debe crear en base a los perfiles de auditor requeridos para cada tipo de misin y en base a la naturaleza de las tareas que debe realizar este equipo. La organizacin del equipo de auditora debe atender a las capacidades tcnicas y experiencia de cada uno de los miembros. La direccin del equipo es asumida por el auditor con ms experiencia y ms preparado en tareas de organizacin y gestin. 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 ms baja responsabilidad. Estas posiciones pueden variar a medida que los auditores van adquiriendo conocimientos y experiencia en su entorno profesional. En el control de los equipos se aplican las metodologas y tcnicas de gestin necesarias, as como las herramientas hardware y software especializadas. En general, no hay que confundir el equipo de auditora de Sistemas de informacin con la unidad funcional de auditora de Sistemas de informacin. En el equipo de auditora se integran los miembros en funcin de su perfil y de la misin concreta a realizar, con una duracin temporal determinada por el cumplimiento de la misin. En la unidad funcional se integran los miembros en funcin de su especializacin y con un cariz de permanencia.
3.2.2 Tcnicas
Se describen algunas tcnicas para simplificar y prevenir de la complejidad con la que se enfrentan los auditores al evaluar y juzgar un sistema informtico. 3.2.2.1 El tratamiento de la complejidad La direccin de una ASI es un ejercicio complicado. Han de seguirse unos pasos:
1. Dados los objetivos de la Auditora, dividir el sistema a ser evaluado en subsistemas. 2. Identificar los componentes que desarrollan las actividades bsicas en cada subsistema. 3. Evaluar la fiabilidad con la que cada componente ejecuta sus actividades.
CAPTULO 2
4. Determinar la correccin con la que cada subsistema se ejecuta y las implicaciones de cada uno de ellos sobre los dems niveles en el sistema.
3.2.2.2 Descomposicin del subsistema El primer paso a dar es descomponer el sistema a evaluar en subsistemas. Un subsistema es una unidad con la que el sistema que lleva a cabo esa funcin bsica, necesita de todo el sistema para conseguir sus objetivos fundamentales. El proceso de descomponer un sistema en subsistemas se denomina factorizacin ("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 constituyentes, los cuales a su vez estn descompuestos hasta que los auditores entienden suficientemente el subsistema que estn tratando. Deben tenerse en cuenta algunos aspectos antes de comenzar el proceso de descomposicin:
La funcin 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 dems. Cada subsistema debe ser internamente cohesivo en el que todas las actividades que desarrolla el subsistema estn diseadas para esa funcin.
Desde el punto de vista de una auditora, los subsistemas son difciles de entender y su correccin es complicada de evaluar a menos que presenten estas caractersticas. Se deben evaluar adems el grado de relacin y cohesin de los subsistemas entre ellos. Al menos conceptualmente, los auditores deben factorizar los sistemas en diferentes modos. Se han utilizado generalmente en la direccin de una ASI dos formas diferentes:
1. Una de ella s relacionada con las funciones administrativas necesarias para cumplir el proceso de informacin.
10
2. La segunda est en relacin con las funciones de aplicacin necesarias para cumplir el proceso de informacin. 3.2.2.3 El subsistema de direccin La ASI trata de conseguir que el desarrollo, la implementacin, la ejecucin, y el mantenimiento de los sistemas informticos 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 informacin sobre las bases del da a da. Algunos niveles del subsistema de direccin se han identificado correspondindose con la jerarqua de la organizacin y las principales funciones que se llevan a cabo dentro de la instalacin de proceso de datos. (ver Figura 3.3)
CAPTULO 2
11
Tala 2.3. Descomposicin del Subsistema de Direccin

SUBSISTEMA DE DIRECCIN Alta Direccin DESCRIPCIN DEL SUBSISTEMA La alta direccin de la organizacin debe asegurarse de que la instalacin de proceso de datos est correctamente dirigida. Es el responsable de una poltica de decisiones a largo plazo sobre cmo van a utilizarse los ordenadores y sistemas de informacin en la organizacin. La direccin de Proceso de Datos tiene la responsabilidad global de planificar y controlar todas las actividades informticas. Adems proporciona las entradas de la poltica de decisiones a largo plazo de la alta direccin y traduce las polticas a largo plazo en objetivos a corto plazo.
Direccin de Proceso de Datos.
Desarrollo de sistemas (Systems Devel- Responsable del diseo , de la implementacin y del opment Management) mantenimiento de las aplicaciones y de los sistemas de informacin. Programadores Responsables de programar nuevos sistemas manteniendo los actuales y proporcionando a los sistemas el adecuado soporte software. Responsable del control y uso de la informacin, incluyendo Bases de Datos y sistemas de ficheros. Responsable de la seguridad fsica de la instalacin de proceso de datos. Controla diariamente las operaciones del sistema de proceso de datos. Responsable de preparar la informacin, de la informacin que fluye a travs de la instalacin, de los sistemas de produccin, del m antenimiento del hardware y en algunos casos del mantenimiento de programas y libreras de facilidades.
Administracin de datos Direccin de seguridad Direccin de explotacin
12
ALTA DIRECCIN DIRECCIN EDP Direccin de desarrollo de sistemas Direccin de Programacin Administracin de Informacin Administracin de Seguridad
Direccin de Explotacin APLICACIN CONTROL SISTEMA
Figura 3.5. Estructura de Control del Subsistema de Direccin
El control es como las capas de una cebolla, cuyas capas estn alrededor de las aplicaciones de control: El subsistema de aplicacin es a su vez dividido en subsistemas que incluyen:
Tabla 3.6. Niveles del Sistema en un proceso de transacciones

SUBSISTEMAS DE APLICACIN Frontera Entrada Comunicacin DESCRIPCIN DE LOS SUBSISTEMAS Comprende los componentes q establecen la interface ue entre el usuario y el sistema. Comprende los componentes que captura, prepara e introducen informacin en el sistema. Comprende los componentes que trasmiten informacin a todos los subsistemas en el sistema y entre un sistema y otro sistema. Comprende los componentes que llevan a cabo la computacin, la clasificacin, la ordenacin y la conclusin de la informacin en el sistema. Comprende los componentes que definen, aaden, acceden, modifican y borran informacin en el sistema. Comprende los componentes que recuperan y presentan la informacin a los usuarios del sistema.
Proceso.
Base de Datos. Salida
CAPTULO 2
13
Proceso de datos
Pr
Ciclo
Aplicacin del sistema
Subsistema de aplicacin
Figura 3.7. Niveles del Sistema en un proceso de transacciones
3.2.2.4 Identificacin de componentes Las funciones del subsistema son ejecutadas va componentes, que seran las unidades fsicas que llevan a cabo las actividades bsicas. Los auditores deducen como funciona un subsistema determinando sus componentes, las actividades que realiza cada componente y las relaciones entre los componentes. La identificacin de componentes suele ir acompaada de una identificacin 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 visin global del sistema.
Los subsistemas presentan tres caractersticas:
1. Han de estar organizados jerrquicamente. 2. Han de ser independientes (frente a otros subsistemas). 3. Han de ser coherentes.
14
Pero identificar claramente los componentes en un subsistema no es fcil, porque 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 tendrn que enjuiciar el correcto funcionamiento de los componentes de un subsistema para comprobar que realizan correctamente la funcin de dicho subsistema. 3.2.2.3 Fiabilidad de los componentes Un sistema alcanza sus objetivos de la salvaguarda de activos, de mantener la integridad de los datos, y de tener un sistema eficaz y eficiente si cada uno de sus subsistemas es fiable. Un subsistema es fiable si los componentes que desarrollan las actividades en el subsistema lo son. Una vez los componentes han sido identific ados, los auditores deben evaluar su fiabilidad respecto a cada tipo de error o irregularidad que suele ocurrir. La fiabilidad de un componente es una funcin de los controles que actan en dicho componente. Un control es una muestra de actividades o acciones ejecutadas por ms de un componente para prevenir, detectar o corregir errores o irregularidades que afectan a la fiabilidad de un componente. Adems 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 funcin es establecer, ejecutar, modificar y mantener actividades de control de modo que la fiabilidad global del sistema sea aceptable. Algunos de los controles ms importantes que deben evaluarse son los s iguientes:
1. Controles de autenticidad: Para verificar la identidad de un usuario o proceso que quiera tomar alguna accin en el sistema. Ejemplo: passwords, nmeros de identificacin personal (PIN: Personal Identification Number), etc. 2. Controles de precisin: Para asegurar la correccin de la informacin y procesos en el sistema. Ejemplo: un programa o rutina que valide que el contenido de un campo contiene nicamente nmeros.
CAPTULO 2
15
3. Controles de completitud: Asegurarse de que no hay prdida de informacin y que todo proceso llega a su adecuada conclusin. Ejemplo: no hay dos campos vacos, etc. 4. Controles de redundancia: Para asegurar que la informacin es procesada una sola vez. 5. Controles de privacidad: La informacin est protegida contra accesos no autorizados. 6. Controles de auditora (Audit trail controls): Tratan de asegurar que queden registrados cronolgicamente 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 auditora, la auditora de cuentas y la auditora 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 estn protegidos de la destruccin o corrupcin. Ejemplo: extintores, contraseas, etc. 9. Controles de eficacia: Asegurar que el sistema alcanza sus objetivos. 10. Controles de eficiencia: Asegurar que el sistema utiliza el mnimo nmero de recursos para conseguir sus objetivos.
Cada tipo de control normalmente aparece en cada subsistema. Adems estos tipos de control no son mutuamente excluyentes. Un control puede partic ipar en varias categoras. Al evaluarse los efectos de un control sobre la fiabilidad de un componente, se consideran varios atributos del control:
La bsqueda del tipo de control adecuado, dada la naturaleza del proceso de actividades depende del sistema. Adems algunas veces el controlar algn tipo de error o irregularidad es mucho ms caro que las prdidas que estos producen. Un atributo a considerar cuando se evala la efectividad del control es si el control previene, detecta o corrige errores.
16
Otro atributo a tener en cuenta es el nmero de componentes necesarias para realizar el control. Finalmente han de considerarse el nmero de subsistemas afectados por el control. Esta funcin comprueba si se trata de una componente compartida, es decir, que realiza actividades en varios subsistemas. Generalmente el control sobre componentes compartidos necesita ser ms fiable y consecuentemente ms complicado.
3.2.2.4 Evaluacin de la fiabilidad del sistema Es el proceso de emitir juicios fiables a medida que el auditor evala la jerarqua del sistema partiendo de los niveles inferiores hacia los niveles superiores. Si el Auditor participa en la fase de diseo produce los efectos siguientes (ver la Figura 3.8):
1. Aumenta el conocimiento tcnico de proceso de datos. 2. Asigna auditores diferentes para disear la fase de auditora y revisin posterior. 3. Reunir a los auditores con ms experiencia en proceso de datos. 4. Establecer una seccin de proceso de datos en el departamento de auditora interna, especializado en ASI. 5. Alcanzar un elevado nivel de soporte de la alta direccin.
CAPTULO 2
17
ANLISIS
DISEO
IMPLEMENTACIN
EJECUCIN
REVISIN
Tiempo
Posible participacin del auditor
Figura 3.8. Participacin del auditor en el ciclo de vida de los sistemas
3.3.2.5 Utilizacin de computadores en una auditora Es otra de las decisiones que deben tomarse al planificar una auditora. Auditora alrededor del computador (Auditing around the computer) Se ve al ordenador como una caja negra. Este enfoque es tanto ms habitual cuanto ms 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 informticos donde puede aplicarse este enfoque es muy restrictivo. Auditora a travs del ordenador (Auditing through the computer) Puede utilizarse el ordenador para realizar pruebas.
1. A la lgica y controles existentes en el sistema.
18
2. A los registros producidos por el sistema.

Dependiendo de la complejidad del sistema de aplicacin que est siendo auditado, el enfoque puede ser simple o necesitar competencias y conocimientos tcnicos por parte del auditor. Normalmente este tipo se utiliza en las circunstancias y sistemas siguientes:
1. Sistemas de aplicacin que procesan un gran volumen de informacin (entradas) y producen una gran cantidad de resultados (salidas), lo que hace que sea muy complicada la validacin de entrada y salida de datos. 2. Cuando partes significativas del sistema de control interno estn incluidas en el sistema informtico. 3. Cuando la lgica 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 auditora.
Cuando se aplica este enfoque requiere expertos tcnicos e implica alto coste. Sin embargo estas desventajas son aparentes cuando este enfoque es el nico mtodo viable para realizar la auditora. 3.3.2.6 Seleccin de los sistemas de aplicacin para la auditora (Selecting Application Systems for Audit) Por regla general deben seleccionarse para la auditora aquellos sistemas de aplic acin ms crticos para la continuidad de la existencia de la organizacin. Han de seleccionarse aquellos sistemas de aplicacin de los cuales se obtienen mejores resultados para la organizacin auditada y que, consecuentemente, la pondran en graves aprietos si fallaran o funcionasen incorrectamente. A menudo, una forma de descubrir en qu sistemas de aplicacin existen problemas, es realizando una auditora de usuario. Cuando un sistema de aplicacin no funciona bien, son los usuarios los afectados. Los usuarios aportan informacin sobre los problemas que les han ocurrido. Es necesario investigar el entorno del usuario. Algunas veces un problema en el sistema de aplicacin 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 eficie ncia del sistema.
CAPTULO 2
19
La auditora de usuario puede realizarse formal o informalmente. Sin embargo, en ambos casos, necesita estar planificada y los resultados bien documentados. 3.3.2.7 Conclusin Tanto el proceso como la direccin 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 bsicas 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 valoracin global acerca de la fiabilidad del sistema. Las fases de que consta una Auditora de Sistemas de Informacin son similares a las fases que componen una auditora de un sistema manual. Primero, se realiza un anlisis preliminar de la instalacin informtica para obtener una idea de cmo est administrada la instalacin y cmo se procesan los principales sistemas de aplicacin. En segundo lugar, si se cuenta con un sistema de control interno, se realiza un anlisis detallado. Seguidamente se realizan pruebas de fiabilidad a controles que la auditora considera crticos, a continuacin se llevan a cabo las pruebas substantivas. Finalmente debe emitirse una valoracin. Despus de todos los pasos el auditor evala el sistema de control interno y decide si sigue con la auditora o seguir por otro camino. Desde el principio la ASI debe asumir y tomar varias decisiones complicadas. Cada evaluacin de la fiabilidad de un sistema de control interno requiere una compleja evaluacin por etapas. Debe decidirse sobre la fase de diseo. Debe realizarse una evaluacin cuidadosa. Deben seleccionarse los sistemas crticos en los cuales debe centrarse la auditora.
3.2.3 Pautas de seleccin para la eleccin de un sistema de aplicacin especfico para una auditora
En la Figura 3.9 podemos apreciar las pautas de seleccin para la eleccin de un sistema de aplicacin especfico para una auditora.
20
Tabla 3.9. Pautas de seleccin para la eleccin de un sistema de aplicacin especfico para una auditora
PAUTAS DE SELECCIN DESCRIPCIN Sistema financiero Debe prestarse mayor atencin en aquellos sistemas que poseen un control financiero sobre los activos de la corporacin. Ejemplo: Cobros totales y desembolsos, nminas, cuentas a pagar y cobrar, etc. Algunos sistemas de aplicacin son ms arriesgados que otros: 1. Porque son susceptibles de varios tipos de prdidas. Ej.: fraude, malversacin, etc. 2. Su prdida puede paralizar la organizacin. Ej.: Prdidas en el proceso de nminas debidas a huelgas. 3. Su interferencia con otros sistemas y los errores generados se propagan a esos otros sistemas. Alta capacidad para la com- Algunos sistemas dan a la organizacin una buena situacin petencia peligrosa en el mercado. Ej.: Patentes, Copyright, un plan estratgico, etc. Sistema avanzado tecnolgi- Si un sistema utiliza tecnologa avanzada. Ej.: Un sistema de camente 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.
Sistema de alto-riesgo
3.2.4 Herramientas para la direccin y desarrollo de auditoras

Vamos a tratar, en primer lugar, del diseo y aplicacin de una entrevista. En segundo lugar, trataremos el diseo y uso de los cuestionarios. En tercer lugar, consideraremos los aspectos de fiabilidad y validez de los cuestionarios. A continuacin, trataremos de la construccin de un diagrama de flujos de control. Finalmente, consideraremos las ventajas y desventajas de un diagrama de flujo de control. Vamos a estudiar tres tcnicas manuales utilizadas para recoger pruebas y/o evidencias de la calidad de los sistemas informticos : entrevistas, cuestionarios y diagramas de flujo de control. Las entrevistas y los cuestionarios han sido usados generalmente en tcnicas de recogida de evidencias en los sistemas manuales. Su importancia no ha disminuido en los sistemas informticos. Particularmente durante la evaluacin de la estructura de control de direccin, las entrevistas y los cuestionarios constituyen un medio importante para comprobar la conformidad. Los diagramas de flujo de control tambin se han utilizado en los sistemas manuales:
CAPTULO 2
21
sin embargo, en la actualidad, adems, su uso est mucho ms difundido debido a la popularidad general de las tcnicas de diagrama de flujo, como una ayuda de anlisis y documentacin en los sistemas informticos 3.2.4.1 Entrevistas Las entrevistas se suelen utilizar para obtener informacin tanto cualitativa como cuantitativa. Su objetivo es obtener respuestas francas, completas y honestas de un entrevistado que tiene ms informacin 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 ningn tipo de antagonismo entre el entrevistador (el auditor) y el entrevistado. Las entrevistas constan de tres fases principales:
1. La preparacin de la entrevista. 2. La realizacin de la entrevista. 3. El anlisis de la entrevista ya realizada.

Las entrevistas reducen el tiempo requerido para encontrar informacin 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 Preparacin de la entrevista Algunos de los pasos ms importantes durante esta fase son:
1. Realizar una investigacin previa: el auditor debe asegurarse de que la informacin que pretende conseguir mediante la entrevista no est disponible de forma sencilla de alguna otra fuente. 2. Identificacin de los entrevistados: Puesto que ocupa, horario y lugar idneos 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 informacin 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 problemticos, y las ltimas deben permitir al entrevistado expresar su opinin. Deben evitarse en lo posible las preguntas "abiertas" del tipo: Qu tipos de controles implanta usted en la preparacin
22
de trabajos? y sustituirlas por preguntas de respuesta cerrada (del tipo "si" "no") : Preparan ustedes "hash totals" sobre los nmeros de documento ?. 4. Planificar fecha, hora y lugar de la entrevista: La planificacin 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 fcilmente documentacin adicional, etc. , siempre y cuando no sea motivo de interrupciones, llamadas telefnicas, u otras distracciones.
3.4.1.2 Realizacin de la entrevista La entrevista debe seguir bsicamente la estructura que hemos diseado previamente en la fase de preparacin. 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 crtica. 5. Evitar los sarcasmos y los recursos humorsticos. 6. Evitar la utilizacin de jergas: Formular preguntas concisas y claras. 7. Permanecer atento e interesado durante el transcurso de la entrevista. 8. Evitar las confrontaciones. 9. Responder cortsmente a las preguntas que nos pueda a su vez realizar el entrevistado. 10. Evitar las familiaridades, aunque conozcamos personalmente al entrevistado.
CAPTULO 2
23
En todo caso, durante la entrevista, el auditor debe tomar notas continuamente; debe evitarse en lo posible la utilizacin de grabadoras de cinta, que podran poner nervioso al entrevistado. Tambin debe permitirse, como norma general, que el entrevistado consulte o pueda revisar las anotaciones escritas que hemos realizado nosotros. 3.4.1.3 Anlisis de la entrevista Tan pronto como sea posible tras la realizacin 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 opinin. 2. Intentar asimilar toda la informacin obtenida durante la entrevista, y determinar lo que aporta cada contestacin al objetivo global de la misma.
3.2.4.2 Cuestionarios Los cuestionarios pueden usarse para obtener informacin factual u opiniones. La mayor dificultad aparece cuando debe obtenerse una opinin. El auditor debe ser prudente para utilizar cuestionarios que sean vlidos y fidedignos. En el anexo a esta publicacin figuran algunos formatos de cuestionarios sobre diversas reas de Auditora y de diversos autores y procedencias. 3.2.4.3 Diagramas de Control Los diagramas de flujos de control muestran qu controles existen y dnde estn en un sistema. Un auditor con experie ncia puede utilizar los diagramas de flujo de control para identificar los controles de debilidades y puntos fuertes que existen en un sistema. No obstante los diagramas de flujo de control son a menudo costosos (en cuestin de tiempo) y difciles de mantener y modificar. Existe software que soporta dibujos y grficos de este tipo, y su utilizacin mitiga algunas de las tradicionales dificultades asociadas con el uso de los diagramas de flujo de control.
24
3.3 Planificacion del trabajo de auditoria

3.3.1 Introduccin
Las normas bsicas de Auditoria sobre la realizacin del trabajo se pueden resumir en los siguientes principios:
1. Necesidad de planificacin del trabajo con anterioridad al comienzo de ste. 2. Necesidad de analizar y evaluar el sistema de control interno de la organizacin 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 realizacin 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 documentacin de las conclusiones alcanzadas.
3.3.2 Normas para la ejecucin del trabajo

El conjunto de Normas de Auditora Generalmente Aceptadas, promulgadas por la AICPA, se puede clasificar en tres grupos distintos: Normas Generales, Normas para la Ejecucin del Trabajo y Normas para la Emisin del Informe. Segn 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 evolucin del control interno existente, como base para determinar la confianza que se puede depositar en el mismo y, consecuentemente, la extensin de las pruebas de Auditora. Norma 3. Deber obtenerse evidencia comprobatoria suficiente y competente, mediante inspecciones, observaciones, preguntas y confirmaciones, para tener una base razonable para emitir una opinin sobre los Registros sujetos a examen.
CAPTULO 2
25
Estas normas deben presidir la preparacin y ejecucin efectivas del trabajo del auditor, tanto en los mbitos tradicionales, como en el mbito del Sistemas de informacin, donde son igualmente aplicables. La planificacin, adems de ser una norma, es una fase esencial de la Auditora, pues del xito o fracaso de la planificacin depender en gran medida el xito o fracaso del resto del trabajo. Es bsica para garantizar que la auditora se va a llevar a cabo en la forma menos costosa para el cliente y ms eficaz para el auditor. En la fase de planificacin deben quedar totalmente aclaradas las siguientes cuestiones:
1. Dnde se va a realizar el trabajo ?. 2. Cundo o en qu periodo de tiempo se va a realizar ?. 3. Qu tipo de informe se va a emitir ?. (Auditora, revisin limitada, examen diagnstico ...) 4. En qu fecha es necesario que est terminado el trabajo ?. 5. Cundo estar terminado el informe ?. 6. Determinacin de la composicin del "Comit de Auditoria". En ciertos casos, cuando la complejidad del trabajo as lo requiera, es conveniente la creacin de un "Comit de Auditora", formado por el personal del cliente y los auditores.
3.3.3 Reglas basicas en la realizacion de una auditora

1. Fomentar la cooperacin 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 Direccin, ya que se debern realizar entrevistas y solicitar documentacin 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 presentacin o entrevista inicial en la que se cuenta el objetivo, su justificacin y se aclaran dudas. 5. Solicitar, con la antelacin precisa, la informacin inicial a obtener.
26
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 Metodologa y Fases de la Auditora Informtica

Las fases del desarrollo de una auditora informtico son las siguientes:
1. 2. 3. 4. 5. 6.
Toma de Contacto Validacin de la Informacin Desarrollo de la Auditora Fase de Diagnstico Presentacin de Conclusiones Formacion del Plan de Mejoras
A continuacin vamos a descricbir cada una de ellas.
3.4.1 Pasos en una Auditora de Sistemas de Informacin

La realizacin de una ASI la podemos desglosar en varias fases o pasos: 3.4.1.1 Fase de anlisis preliminar Objetivo: Obtener la informacin necesaria para tomar la decisin sobre como proceder con la auditora. Pueden seguirse tres caminos.
1. Renunciar a la auditora: El auditor carece de la competencia tcnica para realizar la auditora. 2. Realizar un anlisis detallado del sistema de control interno.
CAPTULO 2
27
3. Desconfiar del sistema de control interno. Existen dos razones para tomar esta decisin
Quiz sea ms rentable realizar directamente las pruebas substantivas. El control de proceso de datos duplicar los controles existentes en el rea de usuario. Esta fase incluye un anlisis de los controles directivos y los controles de aplicacin. Durante el anlisis de los primeros se trata de comprender la organizacin y las prcticas directivas utilizadas en cada nivel de la jerarqua de la instalacin. Durante el segundo anlisis deben comprenderse los controles realizados sobre las transacciones ms importantes que fluyen a travs de los sistemas de aplicacin en la instalacin. En primer lugar, durante esta fase, se realizan entrevistas con el personal de la instalacin, se observan las actividades de la instalacin y se analiza la documentacin de la instalacin. Las evidencias han de documentarse completando cuestionarios, construyendo diagramas de flujo y tablas de decisin y preparando informes. El anlisis 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 anlisis, sobre todo en temas de control de direccin, ya que estn 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 anlisis preliminar, antes de proceder directamente con las pruebas substantivas, siguen realizando unas pruebas detalladas del sistema de control interno en vista de hacer recomendaciones especficas para mejorar.
3.4.1.2 Fase de anlisis detallado Objetivo: Obtener informacin necesaria para que el auditor tenga un conocimie nto profundo de los controles usados en la instalacin informtica. De nuevo debe decidir si la auditora se lleva a cabo o se rechaza, o se procede conforme a la fase
28
de pruebas con la expectativa de que la dependencia puede estar situada sobre el sistema de control interno, o proceder directamente al anlisis de los controles de usuario o procedimiento de pruebas substantivas. Tanto los controles de direccin, como los controles de aplicacin han de analizarse y a ser posible en este orden. Es importante identificar las causas de prdida y riesgos existentes en la instalacin y establecer los controles para reducir los efectos de las causas de prdida. Al final ha de comprobarse si los controles reducen las prdidas a un nivel aceptable. An dentro de esta fase no se sabe con certeza si los controles son efic aces, la evaluacin 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 tcnicas 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 anlisis 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 valoracin final sobre la existencia o no de prdidas o la posibilidad de que ocurran durante el proceso de datos. El auditor externo emite esta valoracin como una opinin. Segn Davis [1983] existen cinco tipos de pruebas substantivas que se realizan en una instalacin de proceso de datos.
1. Pruebas que identifican los procesos errneos.
CAPTULO 2
29
2. Pruebas para asegurar la calidad de la informacin. 3. Pruebas para identificar informacin inconsistente. 4. Pruebas para comparar informacin con cmputos fsicos. 5. Confirmacin de informacin con fuentes externas.
Algunas de estas pruebas requieren soporte informtico.
3.4.2 Decisiones importantes en una Auditora

Cuando se realiza una ASI aparecen ciertas dificultades a la hora de tomar decisiones. Vamos a ver los aspectos ms importantes que afectan a la toma de decisiones. 3.4.2.1 Evaluacin de una decisin (The evaluation judgment) Es una de las decisiones ms difciles al hacer una Auditora de Sistemas. Debe hacerse al final de la fase de anlisis preliminar, al final de la fase de anlisis detallado, 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 continuacin de la auditora, si se puede contar con el sistema de control interno, qu controles son crticos para la auditora y cmo deben probarse, qu pruebas deben realizarse y finalmente si el sistema est protegido fsicamente, mantiene la integridad de los datos y si el sistema es eficaz y eficiente. No existe una metodologa para tomar este tipo de decisiones. 3.4.2.2 Escoger el instante del proceso de auditora Al planificar una ASI, es importante decidir cundo va a llevarse a cabo la auditora. Algunos piensan que son necesarios algunos cambios en el trabajo habitual, ya que probablemente se deba compartir el tiempo de ordenador para los propsitos de la auditora. Otros opinan que deben hacerse cambios fundamentales al evaluarse un sistema informtico. Estos insisten en la participacin del diseo de las fases de un sistema de proceso de datos. Si se acepta esta ltima visin, las auditoras se desarrollarn en tres etapas de la vida del sistema : Fase de diseo, fase de ejecucin y fase de revisin.
30
3.4.3 Toma de Contacto

Objetivos
Principalmente es una fase para lo que podramos llamar auditores externos y como objetivos principales tendramos la puesta en contacto con todos aquellos elementos informativos que puedan ser interesantes para la consecucin del trabajo.
Realizacin
Aqu habr que tener en cuenta inicialmente dos visiones:
Organizativa: La propia estructura organizativa de la empresa, su organigrama, volumen , lneas de producto, situacin en el mercado... Recursos informticos: Estructura del departamento, relaciones funcionales y jerrquicas, recursos humanos, materiales (SGBD, SO, comunicaciones...), aplicaciones de desarrollo en sistemas de explotacin.
En definitiva lograr alcanzar un profundo conocimiento de la idiosincrasia organizativa 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 anlisis preliminar son las correctas sera interesante que se pudieran contrastar con la emitidas con el grupo de auditores internos. Es tambin en esta fase donde se da el visto bueno a la viabilidad de la realizacin de la auditora, puede que por diversas razones como, por ejemplo, la carencia de capacidad para auditar el sistema, ya que excede el campo de actuacin del auditor, o la necesidad de realizar otro tipo de auditora, ya que auditando informticamente no se alcanzarn a resolver los problemas que la empresa tenga.
Herramientas y Documentacin
En la fase de toma de contacto se utilizan principalmente dos herramientas intangibles que son:
CAPTULO 2
31
La experiencia propia: el auditor con la experiencia adquirida en la realizacin de otras auditoras interpreta de una forma ms efectiva toda aquella informacin. Implicacin de Directivos y usuarios: para que el auditor pueda realizar las labores de aproximacin al problema de una forma ptima necesita la cooperacin de todos y cada uno de los integrantes de la estructura organizativa de la empresa, porque quin mejor que los propios implicados en la empresa son capaces de transmitir cules son los puntos clave a ser auditados, haciendo partcipes a stos en todo el proceso de ejecucin de la auditora.
Adems de los dos puntos enumerados anteriormente el auditor tiene que ayudarse de todo tipo de formularios que pueda rellenar el personal y que despus puedan ser de inters a la hora de extraer conclusiones. Tambin podramos utilizar todo tipo de material informtico como programas de interpretacin de datos obtenidos, estadsticos..., pero nunca perdiendo de vista las interpretaciones ms subjetivas, que no por ello errneas, de todos los aspectos interesantes. Por ltimo cabra remarcar la importancia que se le tiene que dar a esta fase, ya que sobre todas las conclusiones extradas se basarn todas las otras fases, es decir, una mala interpretacin de la filosofa de la empresa podra repercutir en una mala realizacin de la auditora.
3.4.4 Validacin de la Informacin

Objetivos
Una vez finalizada la fase de toma de contacto el auditor tiene que estar seguro de que toda la informacin recogida es vlida, precisa, eficiente y de real importancia para su trabajo. Lo que pretende esta fase es validar toda la informacin obtenida anteriormente, as como definir los resultados esperados en la fase de operacin.
Realizacin
Con toda la informacin deberemos ser capaces de tratar los siguientes temas que son de importancia vital:
32
Concentracin de objetivos: fijar los objetivos a nivel global que esperamos obtener en nuestro trabajo, hasta dnde llegaremos y cmo lo queremos hacer. Las reas que cubrir: qu partes exactas de la empresa y, en este caso del sistema, sern objeto de ser auditadas. Personas de la organizacin que debern colaborar directa e indirectamente y en qu momento concreto. Plan de trabajo:
Tareas que se debern realizar. Calendario, tanto de todas las fases as como de la consecucin 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 estimacin lo ms exacta posible del equipo de auditores necesario, en cuanto a nmero y especialidades, o reas de conocimiento.
Llegados a este punto, el auditor debe disponer de todo tipo de manuales de los diferentes sistemas informticos 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 organizacin tiene que ser mxima. el auditor tambin debe estar familiarizado con los controles directivos y con los de aplicacin para ser capaz ms adelante de determinar dnde puede haber fallos en la utilizacin o si, por otro lado, son los propios controles los que no funcionan adecuadamente. Y por ltimo se tendr que utilizar constantemente la documentacin obtenida de los cuestionarios realizados en la fase anterior.
CAPTULO 2
33
3.4.5 Desarrollo de la Auditora

Objetivos
Es en esta fase donde realmente se llevarn a cabo las tareas propias de la realizacin de la auditora. Es aqu donde se profundizar en todo aquello que es susceptible de ser revisado, modificado o cambiado.
Realizacin
Es el momento de ejecutar todas aquellas tareas explicitadas en la fase anterior. Esta fase la podramos calificar de fase de observacin, no en el sentido que se le daba a la primera en la que o bservbamos 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 informtico objeto de la auditora. Ser un periodo en el que se efectuarn los siguientes trabajos :
Se efectuaran las entrevistas previstas en la fase de planificacin. Se completarn los cuestionarios que conlleva el auditar: cuestionarios que nos ayudarn a observar problemas en el sistema, basndonos en la informacin facilitada por los usuarios directos del sistema que son los perfectos conocedores de ste. Se observarn las situaciones deficientes, no slo las aparentes sino las que hasta ahora no hayan sido detectadas, por lo que se podr llegar a simular situaciones lmite. Se observarn los procedimientos, tanto en los informticos como en los usuarios. Se ejecutarn, por tanto, todas las previsiones efectuadas en la fase anterior con el objetivo de llegar a la siguiente etapa en condiciones de diagnosticar la situacin que se ha encontrado. Herramientas y Documentacin
En lo que respecta a la documentacin, el auditor tiene que apoyarse en la experiencia que ha obtenido de otros sistemas para poder comparar resultados de rendimientos anteriores con los que le presta el sistema actual.
34
En cuanto a las herramientas, puede ser interesante que se utilice algn tipo de herramienta mecanizada que le ayude a interpretar los cuestionarios realizados por los usuarios. A menudo, tambin deben utilizarse tcnicas asistidas por ordenador que determinen la existencia y la fiabilidad de los controles. Adems, se puede disponer de:
Los juegos de ensayo que son una herramienta eficiente y significativa que se utiliza para probar programas enrevesados, aunque la realizacin de buenos juegos de ensayo no siempre sea una tarea fcil. Los programas de auditora desarrollados por las principales firmas auditoras. Las tcnicas de ejecucin en paralelo para verificar el correcto funcionamiento de los programas que se tienen que revisar.
3.4.6 Fase de Diagnstico

Objetivo
El objetivo ser analizar e interpretar todos los datos obtenidos en el punto anterior y ser capaces de concluir con un diagnstico de la situacin real encontrada.
Realizacin
Para ello se servirn 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 instalacin con las caractersticas de la observada. Como resultado de esta etapa, deben quedar claramente definidos los puntos dbiles y por contrapartida los fuertes, los riesgos eventuales y en primera instancia unos posibles tipos de solucin o mejora. La finalidad de esta fase es conseguir evidencias suficientes para emitir una valoracin sobre la existencia o no de prdidas o la posibilidad de que ocurran durante el proceso de datos. El auditor externo emite esta valoracin como una opinin.
CAPTULO 2
35
Para diagnosticar correctamente la eficacia del sistema informtico, existen cinco tipos de pruebas substantivas que se realizan en una instalacin de proceso de datos: 1. Pruebas que identifican los procesos errneos. 2. Pruebas para asegurar la calidad de la informacin. 3. Pruebas para identificar informacin inconsistente. 4. Pruebas para comparar informacin con cmputos fsicos. 5. Confirmacin de informacin con fuentes externas.
En lo referente a la documentacin, la informacin no tiene porqu ser til slo para los auditores sino, en general, para cualquier consultor informtico. Entre esta documentacin cabe destacar:
Organigrama de la empresa y en especial del servicio informtico. Documentos de organizacin interna. Aspectos econmicos como gastos, presupuestos, costes humanos y materiales, etc. Estudios informticos realizados y en curso. Actividades desarrolladas por el propio personal o por terceros. Configuraciones de mquina: ordenadores, unidades de disco, comunicaciones, etc. Documentos de input de datos. Listado de operacin de consola. Plannings. Y por ltimo, para las aplicaciones existentes se pueden citar: el anlisis funcional y orgnico, los cuadernos de carga, el diseo de ficheros, los juegos de ensayo, las pruebas de programa, etc.
36
En cuanto a las herramientas, hay que decir que se debe continuar con las utilizadas hasta ahora, pero siempre teniendo en cuenta su utilizacin en cada fase, ya que sta es diferente.
3.4.7 Presentacin de Conclusiones

Es el momento de que los responsables conozcan las conclusiones obtenidas por los auditores en la realizacin de la fase anterior. Por supuesto que estas conclusiones se discutirn 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 anmalas o por lo menos mejorables. Por eso es recomendable que los auditores tengan el suficiente tacto como para presentar estas conclusiones como un plan de mejoras en beneficio de todos, ms que como una reprobacin 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 Direccin) tenga la obligacin de hacer conocer estas situaciones. Y por ltimo, resaltar la importancia de la forma que debe tener la presentacin de conclusiones, es decir, tiene que ser clara, precisa, relevante y que no de lugar a la ambigedad.
3.4.8 Formacin del Plan de Mejoras

Llegamos a este ltimo punto, la direccin ya conoce las deficiencias que el equipo auditor ha observado en su departamento informtico; 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 auditora, el plan de mejoras que permitir solventar las deficiencias encontradas. El informe comprender las deficiencias encontradas en los pasos anteriores abordando los puntos relativos a auditora funcional, como son la gestin de recursos humanos, la seguridad fsica, los costes, etc., abordando tambin aspectos de auditora operativa, tales como el cumplimiento de plazos, los procedimientos de control, la calidad i fiabilidad.
CAPTULO 2
37
El plan de mejoras abarcar todas las recomendaciones que intenten soslayar las deficiencias detectadas en la realizacin de la auditora. Para ello se tendrn en cuenta los recursos disponibles, o al menos potencialmente disponibles, por parte de la empresa objeto de la auditora. De cara a la ejecucin de las recomendaciones contenidas en el pla n, es posible 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 incluirn aquellas mejores puntuales y de fcil realizacin como son las mejoras en plazo, calidad, planificacin o formacin. Las medidas a medio plazo necesitarn de uno a dos aos para poderse concretar. Aqu pues, caben ya mejoras algo ms profundas y con mayor necesidad de recursos, como la optimizacin de programas, o de la documentacin, e incluso algunos aspectos de diseo del sistema. Para concluir, las consideraciones a largo plazo, como cabe pensar fcilmente, pueden llevar a cambios sustanciales en las polticas, medios o incluso estructuras de servicio de informtica. Lgicamente con ms tiempo y ms medios es posible afrontar profundas modificaciones si con ello se consiguen las mejoras redactadas por el equipo auditor. Estas mejores pueden pasar por la reconsideracin de los sistemas en uso o de los medios humanos y materia les con que se cuenta, llegando si es preciso a una seria reconsideracin del plan informtico. Todo esto comporta un riesgo adicional, por lo que se requiere una profunda reflexin por parte de la empresa, as como un considerable grado de confianza en el equipo auditor.
3.5 El Informe de Auditora

El informe final en una auditora de Sistemas de informacin tiene las mismas consideraciones que en cualquier tipo de auditora tradicional: es la expresin documental del juicio emitido por el auditor y la nica referencia oficial o, por lo menos, constatable, de la auditora [1]. La estructura y contenido del informe final debe seguir las pautas dadas en el captulo anterior para el informe de auditora en general, con las adaptaciones necesarias a este entorno de trabajo diferenciado. En esta seccin vamos a desarrollar la estructura y contenido de la Carta de Presentacin del Informe, y la estructura formal, el modelo conceptual y expositivo, y las guas de lenguaje y redaccin del informe final.
38
3.5.1 La Carta de Presentacin del Informe Final

Constituye una especie de resumen de la auditora realizada, cuyo contenido se ampliar en el informe final. El destinatario de este documento es nica y exclusivamente la persona que realiz el encargo de auditora, sea la direccin general de la empresa, sea el cliente contratante o la persona delegada directamente por el cliente. Es obvio que el auditor debe poseer tambin una copia para guardarla en el expediente de la auditora realizada y de uso absolutamente privado. La estructura y contenido de este documento debe atenerse a las recomendaciones siguientes:
1. Independientemente de la extensin del informe final, no debe superar las cuatro pginas. 2. Tiene que incluir datos como la fecha y la naturaleza de la auditora, as como los objetivos generales y alcance de la misma. 3. Tiene que cuantificar el peso de las reas analizadas. 4. Debe presentar una conclusin 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 inclusin de recomendaciones, que solamente se expresan en el informe.
La Carta de Presentacin, como resumen del Informe Final, normalmente se redacta una vez finalizada la redaccin del propio informe.
3.5.2 Estructura formal del Informe Final

La estructura del informe final debe constar de las secciones siguientes:
1. Identificacin e introduccin. 2. Definicin de objetivos y alcance de la auditora. 3. Enumeracin exhaustiva de los temas objeto de la auditora. 4. Cuerpo expositivo.
CAPTULO 2
39
En la seccin de Identificacin e introduccin, debe constar la fecha de inicio de la auditora y la fecha de redaccin del informe, as como la identificacin del equipo de auditora, y de las personas entrevistadas, con los datos de su puesto de trabajo, responsabilidad y departamento al que estn adscritas. En la seccin de Definicin de objetivos y alcance de la auditora, se debe aplicar las mismas pautas que en el modelo general de informe, vistas en el captulo anterior. En la seccin de Cuerpo expositivo, se debe tratar en profundidad cada uno de los temas enumerados en la seccin anterior, siguiendo un orden determinado, que expresamos a continuacin:
* Situacin actual. * Tendencias de situacin futura. * Puntos dbiles y amenazas. * Recomendaciones y planes de accin. * Redaccin de la Carta de Presentacin.
A diferencia de la Carta de Presentacin, el auditor puede proporcionar cuantas copias indique el cliente, siempre y cuando estn personalizadas y se entreguen directamente a sus destinatarios. Recordemos el carcter privado de una auditora.
3.5.3 El modelo conceptual y expositivo del Informe Final

No existe un modelo normalizado de Informe Final de Auditora, de la misma forma que no existe una auditora que sea exactamente igual a otra. Sin embargo, hay modelos elaborados por las empresas o los profesionales de auditora que aplican habitualmente y que se han perfeccionado en base a la experiencia. Podemos hablar de un modelo estndar que se basa en los principios de Inclusin y de Consolidacin de hechos relevantes: solamente se debe incluir los hechos importantes, que se puedan verificar objetivamente, que estn probados y respaldados documentalmente, y que las recomendaciones sobre los mismos mantengan o mejoren las normas y estndares del sistema. Los hechos que cumplen estos principios se pasan al informe, lo que significa que existe una debilidad objetivo de correccin. El modelo estndar -consensuado
40
por la prctica- 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. Descripcin exacta, convincente y sin repeticiones del hecho encontrado. 2. Consecuencias deducibles del hecho. 3. Repercusin del hecho sobre otros mbitos del sistema o de la empresa auditada. 4. Conclusin del hecho en el caso de una exposicin extensa y compleja. 5. Recomendacin del auditor concreta, exacta en el tiempo, explcita en el texto, y dirigida expresamente a quien pueda implantarla.
3.5.4 Guas de lenguaje y redaccin

Podemos distinguir tres unidades bsicas en la redaccin del informe: ttulos, prrafos y frases. Los ttulos deben ser breves y al mismo tiempo deben expresar exactamente el contenido del texto que les sigue. Los prrafos deben tener un lmite de unas 10 lneas y tratar solamente un asunto. Si se supera este lmite, se crea otro prrafo distinto. Las frases deben tener un lmite de 3 lneas y deben corresponder a una sola idea, expresada con dos tiempos verbales como mximo, y sin sustantivizar los verbos. En general, hay que utilizar un lenguaje lo ms exacto y sobrio posible, con los trminos tcnicos ms extendidos y el equivalente en la propia lengua si no introduce distorsin 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 Clasificacin informal de las herramientas de Auditora

Debido a la rpida expansin de las tecnologas informticas, el auditor puede disponer actualmente de herramientas cuyo soporte es cualquier ordenador compatible
CAPTULO 2
41
PC, de sobremesa o porttil, o puede tener herramientas ms 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 informtico a auditar. Por tanto, es difcil establecer una clasificacin estricta de las herramie ntas de auditora. Para no pecar en exceso de criterios, vamos a reducirlos solamente a dos criterios principales: 1) en cuanto a la innovacin tecnolgica: las herramie ntas tradicionales y las herramientas informticas; y 2) en cuanto a su especializacin: las herramientas de propsito general y las especficas de auditora. 1) En cuanto a innovacin tecnolgica:
1.1. Herramientas tradicionales: son las herramientas que ha venido utilizando el auditor tradicionalmente e, incluso, que ha heredado de la tradicin de otros tipos de auditora ( contable): Cuestionarios Previos. Estndares. Entrevistas. Checklist. Matrices de Riesgos.
1.2. Herramientas informticas: son las que funcionan con ordenador, de cualquier tipo: Trazas y/o Huellas de Auditora. Software de ofimtica (procesadores de textos, hojas de clculo, gestores de bases de datos, procesadore s de grficos e imgenes). Software estadstico. Software de control de proyectos. Software de interrogacin. Lenguajes de programacin y libreras de programas. Simuladores y analizadores de sistemas operativos. Monitores. Software de Re-Ingeniera e Ingeniera Inversa. Paquetes de auditora (CAAT).
2)
En cuanto a su especializacin:
42
2.1. Herramientas de propsito general: son las herramientas cuyo espectro de aplicacin trasciende el mbito de la auditora y sirven tambin para otros tipos de actividades. Estndares. Software de ofimtica (procesadores de textos, hojas de clculo, gestores de bases de datos, procesadores de grficos e imgenes). Software estadstico. Software de control de proyectos. Software de interrogacin. Lenguajes de programacin y libreras de programas. Simuladores y analizadores de sistemas operativos. Monitores. Software de Re-Ingeniera e Ingeniera Inversa.
2.2. Herramientas de propsito especfico: son las que tienen solamente aplicacin en la actividad informtica. Cuestionarios Previos. Entrevistas. Checklist. Trazas y/o Huellas de Auditora. Paquetes de auditora (CAAT).
2.2 Herramientas utilizadas en la actividad de Auditora

2.2.1 Cuestionarios previos
Para iniciar el trabajo de campo del auditor, suele ser habitual comenzar solicitando la cumplimentacin de cuestionarios preimpresos que se envan a las personas concretas 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 diferentes y muy especficos para cada situacin, y muy cuidados en su fondo y en su forma.
CAPTULO 2
43
2.2.2 Estndares
Conjunto de normas y procedimientos de aplicacin en la funcin informtica y administrativa de la empresa. Pueden ser estndares de calidad o de otro tipo.
2.2.3 Entrevistas
Las relaciones personales con el auditado pueden ser de tres formas: Mediante la peticin de documentacin concreta sobre alguna materia de su responsabilidad. Mediante "entrevistas" en las que no se sigue un plan predeterminado ni un mtodo estricto de sometimiento a un cuestionario. Por medio de entrevistas en las que el auditor sigue un mtodo preestablecido de antemano y busca unas finalidades concretas.
La entrevista es una de las actividades personales ms importantes del auditor. En ellas, recoge ms informacin y mejor matizada, que la proporcionada por medios propios puramente tcnicos o por las respuestas escritas en los cuestionarios. La entrevista se basa fundamentalmente en el concepto de interrogatorio. El auditor informtico experto entrevista al auditado siguiendo un cuidadoso sistema previamente establecido, consistente en que, bajo la forma de una conversacin correcta y lo menos tensa posible, el auditado conteste sencilla mente y con pulcritud a una serie de preguntas variadas, tambin sencillas. Sin embargo, la sencillez es slo aparente. Tras ella debe existir una preparacin muy elaborada y sistematizada, y que es diferente para cada caso en particular.
2.2.4 Checklist
Las preguntas que el auditor elabora sistemticamente para el anlisis, cruzamiento de datos y sntesis posterior, que luego traduce en preguntas sencillas en las entrevistas, se denomina checklist. La checklist se recomienda que sea slo de uso interno del auditor, y que no se dedique a recitar dichas preguntas en las entrevistas, sino a darles una forma coloquial para aplicarlas en la entrevista con la persona auditada. Hay dos tipos de evaluacin de checklist:
44
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 ms negativa y 5 el valor ms positivo). Checklist Binaria: constituida por preguntas con respuesta nica y excluyente: Si o No. Aritmticamente, 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 Exposicin a un suceso es la probabilidad de que se produzca ese suceso. El Riesgo de un suceso es el producto de la exposicin por el coste del suceso. El Riesgo es una medida en dinero del coste probable que supone para una instalacin la existencia de una posible amenaza. En la aplicacin de las matrices de riesgos se aborda el estudio de las amenazas a la funcin informtica, el impacto que pueden producir si estas amenazas se materializarn, los recursos afectados, y el impacto de las medidas de cobertura aplicadas. En la figura 8.1 se muestra la grfica clsica que contempla los costes frente al grado de seguridad alcanzado cuando se aplican medidas de cobertura sobre los riesgos detectados.
CAPTULO 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 ij ai 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.
46
Tabla 2.2. Matriz (Amenaza, medida de cobertura, efecto)

Medida de Cobertura /Amenaza mj ai eij
e ij : Efecto que produce, sobre la amenaza ai, la aplicacin 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 accin/Amenaza o elemento amenazado rj ai mij1......; mijk......;
mij : medida de cobertura que puede ser aplicable
2.2.6 Trazas y/o Huellas

Las Trazas se utilizan para comprobar la ejecucin de las validaciones de los datos previstas, para verificar que los programas realizan exactamente las funciones previstas. Las trazas no deben modificar en absoluto el sistema. La Auditora Financiero-contable convencional emplea trazas con mucha frecuencia. Son programas encaminados a verificar la correccin de los clculos de nminas, primas, etc. Hay incluso programas de contabilidad que facilitan la gestin de libreras y registran los cambios producidos en los mdulos de librera (PANVALET), para investigaciones posteriores.
CAPTULO 2
47
2.2.7 Software de Ofimtica

Son procesadores de textos, hojas de clculo, gestores de bases de datos, procesadores de grficos e imgenes, y cualquier otro programa que se utilice en entornos de ofimtica y similares. Los procesadores de textos pueden usarse sobre todo en la elaboracin de la documentacin narrativa: cartas, informes, memorndums, etc.; as como en otro tipo de documentacin: cuestionarios, listas, etc. Normalmente funcionan en plataformas compatibles PC, Apple MacIntosh, o Unix. Podemos citar algunos productos bastante tiles: Microsoft Word para Windows versiones 2.0 y 6.0 (PC), Microsoft Word para Macintosh versiones 5.0 y 6.0, MacWrite II (MacIntosh), Wordperfect versin 6.0 -y posteriores (PC y MacIntosh), Lotus Ami Pro (PC) y LATEX (Unix). Las hojas de clculo tienen mltiples aplicaciones como para la elaboracin de un presupuesto, el cotejo de listas de nmeros, etc. Entre los productos ms conocidos tenemos: Microsoft Excel versin 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 documentacin manejada en los papeles de trabajo, registros de actividades realizadas, de personas contactadas, etc. Los productos ms conocidos son: Microsoft Access versin 2.0 (PC), Borland dBASE IV y V (PC), y Paradox versin 4.0 y posteriores. Los procesadores grficos y de imgenes pueden aplicarse en la confeccin de diagramas de flujo -hay productos especializados en esto-, en la captacin y edicin de grficos producidos por otro tipo de software, como el estadstico, para preparar presentaciones, etc. Los productos ms conocidos son: Corel Draw versin 3.0 y posteriores (PC), Microsoft Power Point versin 3.0 y posteriores (PC y MacIntosh) -para presentaciones-, Micrograf Designer (PC), Micrograf Graphics Works (PC), Micrograf ABC FlowCharter (PC) -para diseo de diagramas de flujo-, y Harvard Graphics (PC). En los entornos de Mainframe, con sistemas operativos propios y no estndar, suele haber tambin herramientas que realizan funciones similares a las descritas en esta seccin. El auditor debe recabar toda la informacin posible acerca de ellas. Por lo general, estas herramientas de Mainframe suelen ser muy potentes en el manejo de grandes volmenes de informacin, pero bastante farragosas en su manejo.
48
2.2.8 Software estadstico

Son paquetes de programas bastante extensos y que permiten el estudio estadstico de cualquier conjunto de muestras o poblacin, aplicando diversas tcnicas y enfoques. Permiten al auditor el muestreo de los datos y el anlisis del grado de confianza de los mismos segn el diseo de la muestra que ha confeccionado. Algunos de los mdulos ms comunes de estos programas, se han incorporado en otros programas de auditora ms especficos. Entre los productos ms conocidos, tenemos los siguientes: BMDP (PC y Mainframe), S PSS (PC y Mainframe), Statgraphics (PC y Macintosh), y Systat (PC y Macintosh).
2.2.9 Lenguajes de programacin y bibliotecas de programas

El auditor tiene a su disposicin una serie de lenguajes de programacin de propsito general, que pueden ser compila dos o interpretados, para elaborar peticiones de informacin, en forma de programas, contra el sistema auditado. Normalmente, est obligado a utilizar el lenguaje que tiene la instalacin informtica. En otras ocasiones, bajo condiciones especiales o autorizacin previa, si las normas de la instalacin lo exigen, puede aplicar programas hechos en un lenguaje distinto del de la instalacin. Los lenguajes de programacin ms usuales en las instalaciones informticas son el COBOL, el FORTRAN, el C, y el RPG (exclusivamente IBM -AS/400). Adems, 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, mdulos para la conversin y clculo de fechas, mdulos para el acceso parametrizado a bases de datos, etc. Otra posibilidad que tiene el auditor en cuanto a lenguajes de programacin son los denominados lenguajes de programacin visual, que funcionan sobre plataformas con gestores de ventanas, como Microsoft Windows, IBM OS/2, OSF/MOTIF y X-Window, porque tienen facilidades grficas para el desarrollo de un programa, adems de las sentencias escritas. Entre los productos ms conocidos tenemos los siguientes: Microsoft C++, Microsoft Visual Basic, Borland C++, Zortech C++, Watcom C++, CA Clipper Borland Turbo Pascal y Borland Delphi. Por otra parte, existen generadores de aplicaciones cuyo propsito es la generacin de programas en un lenguaje de programacin dado, a partir de unas especificaciones iniciales. Estos productos crean los fuentes de los programas que, posteriormente se pueden o no ampliar manualmente y se compilan para obtener los
CAPTULO 2
49
mdulos 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 diseados para la gestin de proyectos de cualquier ndole, con facilidades para la definicin de tareas, de tiempos asignados a cada tarea, de distribucin de recursos, etc. con el propsito de alcanzar el objetivo fijado de antemano. Las fases ms comunes en este tipo de software son: Conceptualizacin, Desarrollo, Monitorizacin, Control y Terminacin de proyectos. Prctic amente todos los productos estn basados en las tcnicas PERT/CPM, para el anlisis y diseo de proyectos. Se puede llevar a cabo un control de proyectos utilizando una hoja de clculo, como las mencionadas en la seccin 8.2.7, que tienen capacidad para crear grficos a partir de los datos contenidos en ellas. Tambin se puede utilizar gestores de bases de datos como los mencionados en la seccin 8.2.7, para registro de personal, presupuestos, recursos, asignacin de responsabilidades, etc. Hay, por otra parte, herramientas analticas que efectan el anlisis de los proyectos, aplicando tcnicas PERT/CPM y estadsticas. Estas pueden ser tan generales como los lenguajes de programacin , vistos en la seccin 8.2.9, o tan complicadas como los paquetes estadsticos, vistos en la seccin 8.2.8. Finalmente, las herramientas ms modernas combinan las capacidades de las herramientas vistas en los prrafos anteriores, con funciones de red y comunicacin para la comparticin de informacin. Se suelen denominar Sistemas de Informacin de Gestin de Proyectos (Project Management Information Systems, PMIS). Entre los productos ms conocidos, que pueden funcionar sobre red local de plataformas 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 aplicacin que tiene este tipo de herramientas para el auditor, le puede servir para el diseo de la planificacin y programacin de los procedimientos de auditora, para el seguimiento de las actividades, y para la evaluacin final de las desviaciones entre lo presupuestado y lo real. Tambin puede aplicarse en las tareas de direccin de auditora.
50
2.2.11 Software de interrogacin

El software de interrogacin son programas o conjuntos de programas que permiten, a travs de rdenes sencillas y de pequeo formato, o a travs de mens y teclas de funcin, generar programas que realizan funciones tpicas de muestreo al azar, muestreo segn otros criterios, inspeccin y captura de ficheros y bases de datos, estudios estadsticos, edicin de informes, etc. El auditor tambin puede utilizar para estos fines los lenguajes de interrogacin asociados a los gestores de bases de datos relacionales, como ORACLE, INGRES, DB2 (IBM), ADABAS, etc., para acceder a informacin que se mantiene en estas bases de datos. Los lenguajes especficos para auditora pueden ser productos como CARS, DYL AUDIT y CA-EASYTRIEVE.
2.2.12 Simuladores y analizadores de sistemas operativos

Por lo que respecta al anlisis del sistema, los auditores informticos emplean productos que comprueban los valores asignados por Tcnica de Sistemas a los parmetros variables de las Bibliotecas ms importantes del mismo. Estos parmetros deben estar dentro de un intervalo marcado por el fabricante. Cuando la complejidad es demasiado grande para evitar la alteracin del sistema, o en situaciones especiales, se aplica unos productos llamados simuladores, que emulan el comportamiento de un pequeo subsistema. Hay simuladores basados en productos software, y otros que usan una mezcla de hardware y software. Por ejemplo, en el diseo de redes de comunicaciones se suele usar los productos TPNS, GPSS, SNAPSHOT, MDMS, NETPAC y SIMSCRIPT II.5. Hay otros que emplean la filosofa de orie ntacin 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 situacin e instante real. Se diferencian de los simuladores en que stos predicen o infieren el comportamiento de un elemento, mientras que los monitores slo miden, no provocan determinadas situaciones. Los monitores suelen ser productos muy dependientes de la instalacin en que trabajan, o dependientes del sistema de base de datos, por lo que no abundan productos estndar comerciales.
CAPTULO 2
51
2.2.14 Software de Re-Ingeniera e Ingeniera Inversa

La Re-Ingeniera es el proceso que toma un programa en cdigo fuente, lo introduce en una herramienta CASE para su modificacin y mejora, y entonces vuelve a generar el cdigo en una forma mas comprensible y fcil de mantener. Las herramientas de Re-Ingeniera permiten manipular cdigo fuente en el mdulo tanto a nivel de fichero como a nivel de instruccin de lenguaje individual. Permiten reestructurar y transformar grandes cantidades de cdigo con relativa facilidad, y adems, en la mayora de las veces, de forma automtica. La Ingeniera Inversa es el proceso que toma un programa en cdigo fuente, lo introduce en una herramienta CASE y reproduce toda la documentacin pertinente que se puede utilizar en el anlisis y diseo de dicho programa: diagramas de flujo, descripciones de registros, diccionario de datos, etc. En este caso, el producto final es la documentacin de anlisis, contrariamente al proceso de Re-Ingeniera. La mayora de los buenos productos de CASE incorporan funciones de ReIngeniera e Ingeniera Inversa. Entre ellos tenemos el EXCELERATOR (Index Technology Corp.), ProMod (Promod Inc.), y Teamwork (Cadre Technologies Inc.).
2.2.15 Paquetes de auditora (CAAT)

Los paquetes de auditora son programas o conjuntos de programas que incorporan de entrada todas las funciones bsicas de auditora, formando una unidad operativa integrada, o a travs de mens grficos y teclas de funcin, o a travs de entornos grficos (Microsoft Windows, X -Window, etc.). Son paquetes especializados en auditora e, incluso, en determinados aspectos de la actividad de auditora, o en la auditora de entornos especializados de los Sistemas de Informacin. "CAAT" es el acrnimo de "Computer Aided Auditing Techniques", que significa, Tcnicas de Auditora Asistidas por Ordenador. Comprenden herramientas de auditora que pueden ser tiles a los auditores de los distintos tipos de auditoras y no solamente a los auditores informticos. De hecho, algunas de estas herramientas surgieron inicialmente para el mbito de la auditora financiero-contable. Son productos cuyas ltimas versiones funcionan sobre plataformas PC, bajo entornos DOS y Windows, e incluso sobre estaciones de trabajo UNIX. Los ms conocidos son: CA-PANAUDIT (Computer Associates), AUDIT (AUDIRFOR, S.A.), LANAuditor (ECONOMIC DATA, S.L.), e IDEA (UNIAUDIT- GRANT THORNTON).
52
Hay otros productos de reciente aparicin, o ms sofisticados, o para instalaciones de marcas especficas que no son muy conocidos todava, y son los siguie ntes: ACL (ACL Software), WizRule for Windows (WizSoft), VSA (Vanguard Integrity Professionals), Consul/Audit (Consul risk management b.v.) y Audit & Control Program Mentor (Angel Group). Mencin especial merece el proyecto CobiT (Control Objetives for IT), promovido 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 Tecnologas de Informacin generalmente aceptados para la utilizacin diario de los ejecutivos y auditores de Sistemas de Informacin. Desarrollaremos en las secciones posteriores una descripcin ms detallada de cada una de estas herramientas, debido a su mayor importancia en cuanto al resto de herramie ntas descritas anteriormente.
2.3 Tcnicas de Auditora Asistidas por Ordenador (CAAT's)

En esta seccin desarrollaremos con mayor detalle las herramientas cla sificadas en el grupo de CAAT y que hemos mencionado en la seccin 8.2.15.
2.3.1 IDEA. Interactive Data Extraction and Analysis (Uniaudit- Grant Thornton)
2.3.1.1 Introduccin
El Instituto Canadiense de Auditores de Cuentas (CICA), anticipndose a las necesidades de los auditores, cre en 1987 un programa de extraccin y anlisis de informacin, como respuesta a la creciente automatizacin informtica de la contabilidad de las empresas. El producto en cuestin es IDEA (Interactive Data Extraction and Analysis) y tuvo gran aceptacin desde su primera versin. En los ltimos aos el CICA ayudado por algunas multinacionales ha mejorado el producto original hasta llegar a la versin cuarta, considerada por los auditores y analistas (sus principales usuarios) como la ms completa aplicacin de interrogacin y extraccin de datos. El atractivo de IDEA estriba en la combinacin de un alto grado de funcionalidad con la sencillez de uso. El producto IDEA, aunque complejo y potente, no
CAPTULO 2
53
requiere conocimientos previos, a pesar de esto, la nueva versin incorpora un curso de formacin. Proporciona un entorno de trabajo en modo texto, basado en mens, susceptibles de ser personalizados, y con posibilidad de trabajar mediante ratn o teclas rpidas. En el nuevo producto se conservan las caractersticas 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 auditora, permitiendo clasificar los trabajos y mantener un historial de las operaciones realizadas, dotando a cada proyecto una clave de acceso. La aplicacin permite la exportacin e importacin de ficheros de datos en multitud de formatos y de diferentes aplicaciones. Adems admite multitud de tipos de unidades de almacenamiento. En general responde a las necesidades de todo auditor, ya que es una herramienta creada por auditores, para auditores. Dispone de miles de usuarios, incluso organismos gubernamentales. Proporciona una herramienta eficaz tanto en auditora interna como externa. Y su utilizacin es sencilla. 2.3.1.2 Auditora Informatizada: CAATS y Micro CATS
La revolucin informtica se ha extendido a todos los mbitos, incluyendo el de la auditora y sus mbitos de estudio o trabajo, afectando a su enfoque tradicional de trabajo. Qu puede hacer el auditor ante la revolucin informtica en el campo de la contabilidad? La nica respuesta es la informatizacin de la auditora. El auditor se encuentra cada vez ms con el problema de la reduccin de las pistas de auditora documentadas, puesto que todas las empresas se automatizan y pasan a guardar la informacin en medios magnticos, y no sobre papel como venan haciendo. El manipular la informacin con un ordenador no es todo lo fiable que se desea. La gran variedad de modelos de ordenador, aplicaciones y capacidad de poder manipular la informacin al antojo de uno, hacen que uno de los objetivos que se plantee el nuevo auditor, sea el de revisar la fiabilidad de la informacin.
54
Estos y otros muchos problemas, hacen necesaria la informatizacin de la auditora, permitiendo un mejor reparto del tiempo del auditor y una dedicacin mayor a tareas donde todava no se puede operar con ordenador. Una aplicacin informtica en el trabajo de auditora supone una mejora de los mtodos tradicionales. Los objetivos que se deben buscar son cuatro:
Mejorar la eficacia y reducir los costes de auditora. Incrementar la calidad y reducir el riesgo de auditoria. Reducir el tiempo de obtencin de la informacin. Permitir que personal menos cualificado realice tareas que antes necesitaban de un auditor con experiencia.
Los ingredientes esenciales para lograr la informatizacin de la auditora son cinco:

Objetivos claros. Hardware de calidad. Software de calidad. Buena predisposicin del personal. Gestin o direccin eficiente.
Sin embargo, el soporte informtico de ayuda a la auditora no es barato. Pero, como respuesta a las necesidades urgentes del nuevo auditor, surgen las Tcnicas de Auditora Asistidas por Microordenador. Estas aplicaciones se engloban bajo el nombre de CAATs o MCATs. Constituyen mtodos revolucionarios destinados a incrementar la eficacia de la auditora y a disminuir los costes de los trabajos. Adems presentan ventajas adicionales:
Entorno familiar: En lugar de tener que utilizar los equipos de los clientes, el auditor trabaja siempre en el mismo entorno informtico. No ms retrasos de trabajo: El equipo del auditor est siempre disponible, no como ocurra con los de la empresa a ser auditada. Integracin: Una vez se dispone de la informacin necesaria es posible utilizarla 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 seguridad necesarias. El final del trabajo rutinario: Se informatizan los trabajos tediosos.
CAPTULO 2
55
Las herramientas de extraccin, anlisis y muestreo de datos, que tambin reciben el nombre de herramientas de interrogacin de ficheros, son quiz el CAAT que ms 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 interrogacin
Como ya hemos comentado anteriormente IDEA es un producto software que permite al auditor o al analista, automatizar tareas que resultan tediosas y fcilmente manipuladas por el ordenador, permitiendo emplear el tiempo en otras labores ms delicadas. Como en breve comentaremos, es una herramienta de apoyo en labores de anlisis de informacin, y cubre la tarea desde el principio, extrayendo la informacin de la empresa a ser auditada, hasta el final, generando documentacin de los resultados del estudio de la informacin contable. En general, una labor de interrogacin con IDEA seguir los pasos siguientes:
Obtener el fichero de informacin en formato micro. Ubicar el fichero dentro de un proyecto, asignndole una clave de acceso. Hacer reconocible la informacin para el programa IDEA (importarlo). Realizar el anlisis. 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 identificacin del usuario al comenzar una sesin con IDEA es importante, ya que permite el acceso restringido a los distintos clientes y proyectos. Tambin existe la posibilidad de manipular los mens para realizar una restriccin de funciones por usuarios. La aplicacin almacena automticamente una pista de los ficheros que se hallan bajo su control y de la utilizacin de los mismos. Esto permite saber en todo momento el trabajo realizado sobre un fichero, manteniendo una pista de auditora y un historial que puede ser accedido en cualquier momento, y en el que se pueden incluir comentarios.
56
2.3.1.4
Descripcin de la versin 4.0
8.3.1.4.1Funciones de extraccin y anlisis Este es el rea principal de trabajo de IDEA y provee al auditor de las herramientas necesarias para realizar los anlisis y producir la documentacin.
Funciones de Extraccin:
Permiten extraer registros de un archivo mediante algoritmos de extraccin. El programa es capaz de generar los algoritmos interactivamente con el usuario, o dejar a ste la labor de confeccin. Una funcin adicional permite almacenar algoritmos importantes en un catlogo. Virtualmente se genera un nuevo archivo con los registros de inters, pero fsicamente, lo que realmente se almacena en disco, es la definicin lgica y no la informacin. De esta forma se evita duplicar informacin.
Indexacin y Clasificacin:
Son dos formas de reorganizar la informacin de un archivo, que no estaba en el orden adecuado, utilizando claves de ordenacin. La Clasificacin genera un archivo equivalente con el orden deseado. La Indexacin, menos costosa, genera simplemente un archivo ndice de referencias al original.
Funciones de Anlisis:
Engloba un conjunto de funciones, utilizadas a menudo, en el anlisis de informacin. A continuacin se exponen estas funciones comentando las ms importantes: Estratificacin 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 informacin, generando un nuevo archivo que contenga el campo clave, el nmero de registros y los totales de los campos numricos. Grficos de barras. Permite generar grficas de la informacin resumida. Estadsticas de Campos. Permite calcular distintos estadsticos de hasta 32 campos en una sola pasada.
CAPTULO 2
57
Anlisis de Antigedad. Permite averiguar la antigedad 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, permitiendo conocer las diferencias existentes. Deteccin de Espacios Vacos. Permite detectar cualquier salto o vaco de los valores de un determinado campo, como puede ser el nmero de factura, que debera contener valores correlativos. Deteccin de Duplicados. Es la funcin contraria a la anterior y permite detectar elementos duplicados, como podra ser la contabilizacin de un cheque.
Funciones de Muestreo:
Permiten utilizar cinco mtodos de muestreo: Sistemtico, Aleatorio, Generacin de Nmeros Aleatorios, de Atributos y de Unidades Monetarias.
Funciones de Manipulacin de Campos:

Permiten modificar la informacin 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 informacin o resultado de anlisis manejados por el programa.
Funciones de Manipulacin de Informes:

Permiten la confeccin y edicin de los informes a medida que se suelen incorporar en la documentacin de los trabajos realizados. El soporte es el que proporcionara cualquier procesador de texto en cuanto a encabezados, pies, ttulos, etc.
58
8.3.1.4.2Otras opciones
Importar y Unir Datos:
Antes de que pueda ser utilizada por el programa IDEA, la informacin debe importarse en forma de archivo. Para ello se debern especificar los parmetros referentes al formato y estructura de campos que contiene el archivo fuente. Adems en ocasiones esto no es necesario, ya que el programa reconoce automticamente muchos tipos distintos de archivos.
Funciones de Exportacin de Datos:
De forma parecida, la informacin generada por la aplicacin, puede ser exportada a otras aplicaciones, como pueden ser procesadores de texto u hojas de clculo. En este rea IDEA tambin reconoce los formatos de diferentes plataformas.
Gestin de Clientes:
Se puede mantener por separado la informacin de diferentes clientes o proyectos de auditora. Tambin se pueden asociar claves de acceso a los distintos archivos.
Funciones de Gestin de Ficheros y otras Utilidades:

Son un conjunto de herramientas tiles para gestionar los archivos internamente por el programa, permitir ejecutar ordenes del DOS o incluir en los mens aplicaciones de uso habitual: Fusionar ficheros. Backup y Restauracin de Ficheros. Suprimir ficheros e ndices. Gestin de Ficheros en el DOS. Editar un Fichero de Texto. Salir Temporalmente al DOS. Funciones de Configuracin. Otras Aplicaciones.
CAPTULO 2
59
2.3.2 CobiT. Control Objetives for IT (Information Systems Audit and Control Foundation)
2.3.2.1 Introduccin El proyecto CobiT (Control Objetives for IT), fue promovido por la Information Systems Audit and Control Foundation con la colaboracin de grupos de trabajo internacionales, para obtener un producto de auditora, con el mismo nombre. CobiT es un moderno y estndar conjunto de Objetivos de Control de las Tecnologas de Informacin generalmente aceptados para la utilizacin diaria de los ejecutivos y auditores de Sistemas de Informacin. 2.3.2.2 La Information Systems Audit and Control Foundation La Information Systems Audit and Control Foundation es una fundacin de la Information Systems Audit and Control Association (ISACA), organizacin profesional con 14.000 miembros en todo el mundo que estn trabajando en la auditora, el control y la seguridad de los sistemas de informacin. Se fund en 1969 como la EDP Auditors Association, y actualmente la misin de ISACA es la de mejorar el reconocimiento de la profesin de auditora y control de los sistemas de informacin a travs de la elaboracin de estndares y prcticas, formacin y certificacin. La Information Systems Audit and Control Foundation est encargada de trabajos de investigacin para producir materiales de referencia y para establecer estndares profesionales que dirijan la prctica en las reas tecnolgicas para el beneficio de la comunidad global de Sistemas de Informacin. 2.3.2.3 Introduccin a CobiT
CobiT est diseado como un estndar aplicable y aceptable en general para la buena prctica de la auditora de las tecnologas de la Informacin en todo el mundo. El producto CobiT utiliza los Objetivos de Control de ISACA, mejorados con estndares especficos de tipo tcnico, profesional, normativo e industrial existentes y emergentes. Los objetivos de control se han desarrollado para su aplicacin en el amplio espectro de sistemas de informacin en la empresa. El trmino "generalmente aceptado" se utiliza explcitamente en el mismo sentido que en los PCGA (Principios Contables Generalmente Aceptados). En las reuniones iniciales, los planificadores identificaron que el estndar deba ser pragmtico, relativamente reducido en tamao, y suficiente para las necesidades de gestin al mismo tiempo que se mantuviera independiente de las instalaciones de TI adoptadas en una organizacin. Tena que identificar cualquier indica-
60
dor de rendimiento. La capacidad de un marco de cualificacin tenia una prioridad secundaria. El desarrollo tena que dar lugar a un producto final comercial, seguido de actividades de promocin y educacin para asegurar la introduccin y adopcin extensas de los objetivos de control de TI mejorados. La mejora consista en lo siguiente:
Adecuacin a los estndares y normativas legislativos y de hecho existentes que se aplican en el marco global, as como en los objetivos de control individuales. Revisin crtica de las diferentes actividades y tareas bajo los dominios de control y posibilitando la especificacin de indicadores de prestaciones importantes (normas, reglas, etc.). Establecimiento de unas directrices y fundamentos para proporcionar investigacin consistente sobre los temas de auditora y control de TI.
Se ha contado con la colaboracin de grupos de trabajo distribuidos por todo el mundo para aportar seguridad en la calidad y revisin experta de los trabajos de investigacin en el proyecto y en el desarrollo de la documentacin. Se ha contado con el asesoramiento de equipos de investigacin acadmicos y profesionales que han coleccionado y analizado recursos en Europa (Free University of Amsterdam), los EE.UU. (California Politechnic University) y Australia (University of New South Wales). Despus de la coleccin y anlisis de los recursos, los investigadores examinaron cada dominio y procedieron en profundidad y sugirieron nuevos objetivos de control aplicables a cada proceso de tecnologa de la informacin particular. Los investigadores compilaron, revisaron, evaluaron e incorporaron estndares tcnicos internacionales, cdigos de conducta, estndares de calidad, estndares de auditora profesionales, requisitos y prcticas en la industria, y requisitos especficos de la industria emergentes en la medida en que se relacionaban con los objetivos de control globales e individuales. Estos esfuerzos han producido ms de 300 objetivos de control nuevos y actualizados a considerar por los inspectores de calidad y grupos de expertos. La consolidacin de los resultados se realiz principalmente en el Equipo de Proyecto, compuesto por el Directos del Proyecto, el Gestor del Proyecto y el Director de Investigacin de la ISACA/F. La exposicin, promocin y publicacin de estos resultados han estado a cargo de la ISACA/F.
CAPTULO 2
61
2.3.2.4
La necesidad del Control en las Tecnologas de In-formacin
Hay una creciente necesidad entre las administraciones de las empresas y los usuarios de los servicios de TI de obtener confianza en la seguridad y el control a travs de la acreditacin y la auditora de los servicios de TI aportadas por unidades internas u organizaciones externas. En el presente, sin embargo, la implantacin de un buen control de TI en los sistemas de gestin - sean comerciales, no lucrativos, gubernamentales, etc.- esta dificultada por la confusin provocada por los distintos esquemas de evaluacin 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 aplicarse en la gestin como ayuda en el balance de riesgos y en el control de la inversin en un entorno de TI a menudo impredecible; por auditores de SI para sustanciar sus opiniones sobre los controles internos y de gestin; y por las administraciones de las empresas y usuarios para que puedan obtener confianza en la seguridad y el control de los servicios de TI proporcionados por unidades internas o por terceras partes. 2.3.2.5 Definicin y evolucin del producto
El producto bsico consiste en un sistema para el control en TI basado en criterios de gestin y documentado por objetivos de control organizados por dominios, procesos y actividades de TI. Cada una de estas reas tiene, adems de un conjunto de objetivos de control, una definicin y una base lgica 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 cada una de estas fases, las tareas y actividades de TI que sirven como estructura para organizar los objetivos de control de TI se refinarn y publicarn durante 1996 y 1997 respectivamente. 2.3.2.6 Objetivos y Criterios de Gestin
Para satisfacer los objetivos de gestin, la informacin debe cumplir ciertos criterios referidos como requisitos de gestin. Al establecer la lista de requisitos, se combinan los principios contenidos en modelos existentes y conocidos:

Requisitos de Calidad:
Calidad.
62
Coste. Distribucin.
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 Seguridad, se han identificado siete categoras distintas pero no disjuntas. Sus definiciones son las siguientes:
Efectividad: maneja informacin que es importante y pertinente para el proceso de gestin as como la que se distribuye de una forma oportuna, correcta, consistente y manejable. Eficiencia: corresponde a la provisin de informacin en la forma menos costosa. Integridad: referido a la precisin y completitud de la informacin as como su validez de acuerdo con el conjunto de valores y presupuestos de gestin. Confidencialidad: corresponde a la proteccin de la informacin sensible frente a una revelacin no autorizada. Disponibilidad: referido a la informacin que est disponible cuando lo requiera el proceso de gestin, y tambin 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 gestin. 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, evaluacin o localizacin, y presentacin y revelacin de esta informacin.
La informacin que los procesos de gestin necesitan est proporcionada por el uso de los recursos de TI. Para asegurar que los requisitos de gestin para la
CAPTULO 2
63
informacin 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 satisfarn los requisitos de gestin en el mismo grado, as que se hace una distincin en el sistema CobiT contemplando el cumplimiento primario y secundario:
Primario: grado en que el objetivo de control satisface completamente el requisito de informacin correspondiente. Secundario: grado en que el objetivo de control satisface solamente en menor extensin o indirectamente el requisito de informacin correspondiente.
El sistema consiste en objetivos de control de TI de alto nivel y una estructura global para su clasificacin y funcionamiento. La teora subyacente para la clasificacin elegida, en lnea con las experiencias de Re-Ingeniera, es que hay, en esencia tres niveles de esfuerzos en TI cuando se considera la gestin de los recursos de TI. Estos son actividades, procesos y dominios:
Actividades: las actividades, junto con las tareas estn 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 lnea con el ciclo de gestin o el ciclo de vida aplicables a los procesos de TI: Planificacin y Organizacin: conduce la estrategia y las tcticas y corresponde a la identificacin de la forma en que la informacin tecnolgica puede contribuir mejor a alcanzar los objetivos de gestin. Adquisicin e Implementacin: para llevar a cabo la estrategia es necesario identificar, desarrollar y adquirir soluciones de TI apropiadas, as como implementarlas e integrarlas en el procesos de gestin. Distribucin y Soporte: corresponde con la distribucin normal de los servicios requeridos, que van desde las tradicionales operaciones sobre s eguridad y continuidad hasta la formacin. Monitorizacin: todos los procesos de TI deben evaluarse regularmente en el tiempo para comprobar su calidad.
64
2.3.2.7
El manejo del sistema CobiT
El marco conceptual se enfoca desde tres puntos de vista distintos: criterios de gestin para la informacin, recursos de TI y procesos de TI. Estos tres puntos de vista se ensamblan en un formato cbico y permiten que se obtengan referencias cruzadas en dicho marco y se pueda acceder a l eficientemente. Los objetivos de control de TI estn organizados inicialmente por proceso/actividad, pero las ayudas para la navegacin que se aportan, facilitan la entrada desde cualquier punto estratgico. Tambin facilitan la adopcin de enfoques combinados o globales, tal como la instalacin/implementacin de un proceso, responsabilidades de gestin global para un proceso, y el uso de los recursos de TI por un proceso. Con el propsito de tener documentacin apta para publicar, el sistema CobiT est limitado a los objetivos de control de alto nivel en la forma de una necesidad de gestin sobre un proceso de TI particular. El requisito de gestin se alcanza a travs de una instruccin de control y se puede considerar controles potencialmente aplicables.
3. El marco metodolgico para la ASI

La Information Systems Audit and Control Association (ISACA), es una asociacin profesional de mbito mundial (ms de 40.000 asociados individuales e institucionales) para la regulacin de la prctica de a Auditora de Sistemas de l Informacin cuya sede esta en EE. UU. (http://www.isaca.org). En algunos pases la ISACA tiene reconocimiento oficial como la institucin reguladora del ejercicio de sus auditores informticos, con unas competencias similares a los organismos que controlan la actividad de auditora de cuentas. En otros pases, como Espaa, el reconocimiento es tcito ya que no existen normas legales especficas. 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 versin de un marco metodolgico formal denominado COBIT (Control Objectives for Information and related Technology - Objetivos de Control para la Informacin y Tecnologas Afines). COBIT, por tanto, est ampliamente aceptado por la comunidad internacional de auditores de sistemas de informacin como una norma estndar.
CAPTULO 2
65
3.1. Breve introduccin a COBIT

La Misin de COBIT es la siguiente: Investigar, desarrollar, publicar y promover un conjunto de objetivos de controlen tecnologa de informacin con autoridad, actualizados, de carcter internacional y aceptados generalmente para el uso cotidiano de gerentes de empresas y auditores. (ISACAF-EXS, 2000). COBIT est diseado como un estndar aplicable y aceptable en general para la buena prctica de la auditora de las tecnologas de la Informacin en todo el mundo. El producto COBIT utiliza los Objetivos de Control de ISACA, mejorados con estndares especficos de tipo tcnico, profesional, normativo e industrial existentes y emergentes. Los objetivos de control se han desarrollado para su aplicacin en el amplio espectro de sistemas de informacin en la empresa. Estos objetivos de control tienen en cuenta lo siguiente:
Adecuacin a los estndares y normativas legislativos y de hecho existentes que se aplican en el marco global, as como en los objetivos de control individuales. Revisin crtica de las diferentes actividades y tareas bajo los dominios de control y posibilitando la especificacin de indicadores de prestaciones importantes (normas, reglas, etc.) Establecimiento de unas directrices y fundamentos para proporcionar investigacin consistente sobre los temas de auditora y control de Tecnologas de Informacin (TI).
COBIT se ha diseado como sistema metodolgico que consiste en un conjunto de objetivos de control de TI de alto nivel y una estructura global para su clasificacin y funcionamiento(Vase la Figura 2).
66
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 teora subyacente para la clasificacin elegida, en lnea con las experie ncias de Re-Ingeniera, es que hay, en esencia, tres niveles de esfuerzos en TI cuando se considera la gestin de los recursos de TI:
CAPTULO 2
67
Actividades: Las actividades, junto con las tareas estn 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 lnea con el ciclo de gestin o el ciclo de vida aplicables a los procesos de TI (Vase la Tabla 2):
Planificacin y Organizacin:
Conduce la estrategia y las tcticas y corresponde a la identificacin de la forma en que la informacin tecnolgica puede contribuir mejor a alcanzar los objetivos de gestin.
Distribucin y Soporte:
Corresponde con la distribucin normal de los servicios requeridos, que van desde las tradicionales operaciones sobre seguridad y continuidad hasta la formacin.
Adquisicin e Implementacin:
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 gestin.
Monitorizacin:
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 gestin para la informacin, recursos de TI y procesos de TI. Estos tres puntos de vista se ensamblan en un formato cbico y permiten que se obtengan referencias cruzadas en dicho marco y se pueda acceder a l eficientemente (Vase la Figura 3).
68
Figura 3. El cubo 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.
Los o bjetivos de control de TI estn organizados inicialmente por proceso / actividad, pero las ayudas para la navegacin que se aportan, facilitan la entrada desde cualquier punto estratgico. Tambin facilitan la adopcin de enfoques combinados o globales, tal como la instalacin / implementacin de un proceso, responsabilidades de gestin global para un proceso, y el uso de los recursos de TI por un proceso (Vase la Figura 4).
CAPTULO 2
69
Figura 4. Objetivos de control de COBIT definidos genricamente 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.
La informacin que los procesos de gestin necesitan est proporcionada por el uso de los recursos de TI. Para asegurar que los requisitos de gestin para la informacin 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 satisfarn los requisitos de gestin en el mismo grado, as que se hace una distincin en COBIT contemplando el cumplimiento: Primario (P): grado en que el objetivo de control satisface completamente el requisito de informacin correspondiente. Secundario (S): grado en que el objetivo de control satisface solamente en menor extensin o indirectamente el requisito de informacin correspondiente.
70
Figura 5. Tabla resumen 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.
2.4 Bibliografa
[1] [2] [3] [4] [5] [6] [7] [8] [9] Acha Iturmendi J.J. Auditora Informtica en la empresa. Paraninfo, Madrid, 1994. Alonso Rivas G. Auditora Informtica.Daz de Santos, Madrid, 1989. Auerbach Publishers. EDP Auditing. Auerbach Publishers, Orlando (USA), 1989 Badiru a. b., Whitehouse G. E. Computer Tools, Models and Techniques for Project Management. Tab Books, Blue Ridge Summit, PA, 1989. Casals Creus, R Fundamentos de auditora.3 ed. Instituto de auditores-censores jurados de cuentas de Espaa, Madrid, 1992. Chu G.T. "Expert Systems in Computer Based Auditing". EDP Auditor Journal, vol I, 1989. Davis G.B., Adams D .L., Schaller C.A.Auditing & EDP.2 ed. American Institute of Certified Public Accountants. New York, 1983. 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. De Juan Rivas A., Prez pascual A. La auditora en el desarrollo de proyectos informticos. Daz de Santos, madrid, 1988.
CAPTULO 2
71
[10] [11] [12] [13]
Derrien Y. Tcnicas de la Auditora Informtica. Marcombo, Barcelona, 1994. Fernndez Pea E. Diccionario de Auditora, 1989. Fisher A. S. CASE. Using Software Development Tools. 2nd. ed. John Wiley, New York, 1991. Grupp B. La gestin del departamento de informtica. Organizacin. Direccin. Informacin. Hispano Europea, S.A., Barcelona, 1985. ESADE. Estudios de la Empresa. Hannan J. Gestin de las Operaciones del Centro de Explotacin de Datos. Ediciones Arcadia, S.A, Madrid, 1984. Guas Prcticas CHIP-AUERBACH. Instituto de Directivos de Empresa. Seminario de Auditora Informtica. Master de Informtica para directivos. Instituto de Directivos de Empresa. Madrid, 1991. Iskandar M., Mc Mann P. "EDP Auditor Journal". EDP Auditor Journal, vol IV, 1989 Coopers & Lybrand. Manual de auditora Coopers & Lybrand. Diorki, BilbaoDeusto, 1989 Martnez Garca, F. J. Auditora de cuentas. Cuestiones y supuestos prcticos. Enunciados y soluciones, 1 ed. Jucar, Madrid, 1989. Milln Fernndez, W. Auditoria empresarial. 2 ed. Instituto de Contabilidad y Auditoria de Cuentas, Madrid, 1989. Mockler R.J. Knowledge-Based Systems for Management Decisions. PrenticeHall International, Englewood Cliffs, NJ (USA), 1989. Montersinos Julve, V. ed. La Auditora en Espanya situacin actual y perspectivas. Servei de Publicacions de la Universitat de Valncia, Valncia, 1991. Prez Pascual A., Juan Rivas A. La Auditora en el desarrollo de proyectos informticos. Daz de Santos, Madrid, 1988. Porter Thomas, J.R. y Buston John C. Auditing: A Conceptual Approach. Wadswoz, Belmont, CA (USA), 1971 Ramos Gonzlez M.A. Contribucin a la mejora de la Auditora Informtica mediante la aplicacin de mtodos y herramientas de Ingeniera del Conocimiento. Tesis doctoral, Universidad Politcnica de Madrid, Madrid, Septiembre, 1990. Ros Mcdonnell L., Bernal Montas R., Grau Gadea G., Ortz Bas A., Chalmeta Rosale R. Apuntes de gestin de Sistemas y Tecnologas de la Informacin. Servicio de Publicaciones de la Universidad Politcnica de Valencia, Valencia, 1995. SEDISI. Gua de Gestin de Programas de ordenador. SEDISI.
[14] [15]
[16] [17] [18] [19] [20] [21] [22] [23] [24]
[25]
[26]
72
[27] [28] [29] [30] [31] [32] [33] [34]
The Journal of Information Systems Audit and Control Association. The EDP Auditors Association. Vol II, 1995. The Journal of Information Systems Audit and Control Association. The EDP Auditors Association. Vol III, 1995. Thomas A.J. Auditora Informtica, 2 ed. Paraninfo,Madrid,1988. Thorin M.La Auditora Informtica. Mtodos, Reglas, Normas.Masson, S.A., Barcelona, 1989. Manuales de Informtica Masson Vallabhaneni S.R. CISA Volume 1: Theory (rev. 1996).SVR Professional Publications, Schaumburg, Illinois (USA), 1996. Wallace, W. A. Handbook of internal accounting controls. 2nd ed. Englewood Cliffs, N.J. Prentice-Hall cop. 1991 Waterman D. A guide to expert systems. Addison-Wesley, Boston, MA, 1986. Weber R. EDP Auditing. Conceptual Foundations and Practice. 2nd ed. McGraw-Hill, Sydney, 1988.
2.4 ndice de tablas

Tala 2.3. Descomposicin del Subsistema de Direccin.............................................................11 Tabla 3.6. Niveles del Sistema en un proceso de transacciones.................................................12 Tabla 3.9. Pautas de seleccin para la eleccin de un sistema de aplicacin especfico para una auditora .........................................................................................................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 Direccin.................................................12 Figura 3.7. Niveles del Sistema en un proceso de transacciones ...............................................13

Auditoria Informatica Modulo 2 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Auditoria Informatica Modulo 2 PDF

Uploaded by

Copyright:

Available Formats

2

2. DESARROLLO GENERAL DE UNA AUDITORA. PROCESOS, METODOLOGAS, TCNICAS Y TECNOLOGAS

AUDITORA INFORMTICA (ITIG)

3.2 Proceso y Direccin de una Auditora de Sistemas de Informacin

AUDITORA INFORMTICA (ITIG)

3.2.1 La gestin y organizacin de la Funcin de Auditora de Sistemas de Informacin

5 Auditor Staff Gral

6 Auditor Staff Gral

7 Auditor Inf Especialista

8 Auditor Inf Especialista

Figura 3.1. La auditora de PED como funcin de Staff [Weber]

AUDITORA INFORMTICA (ITIG)

2 Jefe Aud. Equipo 1

3 Jefe Aud. Equipo 2

3 Jefe Aud. Equipo3

5 Auditor Staff Gral

7 Auditor Inf Especialista

5 Auditor Staff Gral

6 Auditor Staff Gral

8 Auditor Inf Especialista

Figura 3.2. La auditora de PEd como funcin de lnea [Weber]

AUDITORA INFORMTICA (ITIG)

AUDITORA INFORMTICA (ITIG)

Tala 2.3. Descomposicin del Subsistema de Direccin

Direccin de Proceso de Datos.

Administracin de datos Direccin de seguridad Direccin de explotacin

AUDITORA INFORMTICA (ITIG)

Figura 3.5. Estructura de Control del Subsistema de Direccin

Tabla 3.6. Niveles del Sistema en un proceso de transacciones

Base de Datos. Salida

Aplicacin del sistema

Figura 3.7. Niveles del Sistema en un proceso de transacciones

AUDITORA INFORMTICA (ITIG)

AUDITORA INFORMTICA (ITIG)

Figura 3.8. Participacin del auditor en el ciclo de vida de los sistemas

1. A la lgica y controles existentes en el sistema.

AUDITORA INFORMTICA (ITIG)

2. A los registros producidos por el sistema.

AUDITORA INFORMTICA (ITIG)

3.2.4 Herramientas para la direccin y desarrollo de auditoras

1. La preparacin de la entrevista. 2. La realizacin de la entrevista. 3. El anlisis de la entrevista ya realizada.

AUDITORA INFORMTICA (ITIG)

AUDITORA INFORMTICA (ITIG)

3.3 Planificacion del trabajo de auditoria

3.3.2 Normas para la ejecucin del trabajo

3.3.3 Reglas basicas en la realizacion de una auditora

AUDITORA INFORMTICA (ITIG)

3.4 Metodologa y Fases de la Auditora Informtica

A continuacin vamos a descricbir cada una de ellas.

3.4.1 Pasos en una Auditora de Sistemas de Informacin

AUDITORA INFORMTICA (ITIG)

1. Pruebas que identifican los procesos errneos.

3.4.2 Decisiones importantes en una Auditora

AUDITORA INFORMTICA (ITIG)

3.4.3 Toma de Contacto

3.4.4 Validacin de la Informacin

AUDITORA INFORMTICA (ITIG)

3.4.5 Desarrollo de la Auditora

AUDITORA INFORMTICA (ITIG)

3.4.6 Fase de Diagnstico

AUDITORA INFORMTICA (ITIG)

3.4.7 Presentacin de Conclusiones

3.4.8 Formacin del Plan de Mejoras