52

5. INTRODUCCIN A LA REALIZACIN DE UNA

AUDITORIA DE SISTEMAS DE INFORMACIN

5.1. LA NATURALEZA DE LOS CONTROLES

5.2. EL MANEJO DE LA COMPLEJIDAD
5.2.1. Factorizacion en subsistemas
5.2.2. Evaluacion de la Fiabilidad del Sistema

5.3. RIESGOS DE AUDITORIA

5.4. TIPOS DE PROCEDIMIENTOS DE AUDITORIA

5.5. VISTAZO A LOS PASOS BASICOS DE UNA AUDITORIA
5.5.1. PlaniIicacion de la auditoria
5.5.2. Evaluacion del nivel de riesgo de control
5.5.3. Pruebas de los controles
5.5.4. Pruebas sustantivas de las transacciones
5.5.5. Pruebas de los balances o de los resultados globales
5.5.6. Finalizacion de la auditoria

5.6. AUDITORIA ALREDEDOR vs A TRAVES DEL ORDENADOR
5.6.1. Auditoria alrededor del ordenador
5.6.2. Auditoria a traves del ordenador

Es una gran experiencia el estar a cargo de una auditoria de SI de una organizacion
que tenga varios cientos de programadores y analistas, muchos ordenadores interconectados
y miles de Iicheros. Obviamente, no todas las organizaciones son de este tamao, pero a
excepcion de las mas pequeas los auditores no pueden realizar una revision detallada de
todo el procesamiento de datos que se realiza dentro de la Iuncion de SI. Por lo que deben
conIiar en una muestra de los datos para determinar si se han conseguido los objetivos de la
auditoria de sistemas de inIormacion.
En este capitulo se da un vistazo a la estrategia general que los auditores utilizan
para obtener un aseguramiento razonable de que una organizacion salvaguarda sus activos,
mantiene la integridad de los datos y alcanza lo anterior con un sistema eIicaz y eIiciente.
Primero se examina la naturaleza de los controles y se plantean algunas tecnicas para
simpliIicar y poner orden en la complejidad que los auditores tienen que aIrontar para
poder realizar una evaluacion de un sistema inIormatico. En segundo lugar, se consideran
algunos de los riesgos basicos que los auditores aIrontan, como estos riesgos inIluyen en la
estrategia global de una auditoria y los tipos de procedimientos de auditoria que se utilizan
para evaluar o controlar el nivel de estos riesgos. En tercer lugar se presentan los pasos
basicos para realizar una auditoria de SI. Por ultimo, se examina una decision importante
que los auditores deben tomar cuando planiIican y realizan una auditoria de SI, es decir,
cuanto tienen que conocer del trabajo interno de un SI para poder realizar una auditoria
eIicaz.

53

5.1 LA NATURALEZA DE LOS CONTROLES
El objetivo ultimo de los auditores de SI es el de evaluar la Iiabilidad, o eIicacia
operativa, de los controles. Por tanto, es importante que entendamos que es lo que se
entiende por control.

Un control es un sistema que previene, detecta o corrige eventos ilicitos.

En esta deIinicion hay tres aspectos clave:
El primero, un control es un sistema. Dicho de otra manera, esta compuesto por un
conjunto de componentes interrelacionados que Iuncionan juntos para conseguir un
determinado objetivo. DesaIortunadamente, se tiende a dar nombre a los controles
Iijandose solo en una caracteristica del control. Por ejemplo, el control contrasea; una contrasea
por si misma no es un control. Las contraseas son controles solo en el contexto de un sistema que permite la
emision segura de contraseas, su validacion correcta, su almacenamiento seguro, seguimiento de su uso
ilicito, etc. Si este sistema Ialla de alguna manera, las contraseas seran ineIicaces como control. En resumen,
el termino control de contrasea es una notacion para el conjunto de cosas que Iuncionan juntas para asegurar
que solo las personas autorizadas utilizan los recursos de computacion. Por tanto, cuando se evalua un control
se debe considerar su Iiabilidad desde una perspectiva de sistema.
El segundo, el Ioco de los controles son los eventos ilicitos. Un evento ilicito puede
aparecer si se realizan entradas no autorizadas, inexactas, incompletas, redundantes,
ineIicaces o ineIicientes en un sistema; por ejemplo, una persona de entrada de datos puede introducir
datos incompletos en un sistema. Un evento ilicito tambien puede aparecer si el sistema
transIorma la entrada en una Iorma no autorizada, inexacta, incompleta, redundante,
ineIicaz o ineIiciente. Por ejemplo, un programa podria contener instrucciones erroneas que produjesen
resultados incorrectos. Cualquiera que Iuese la causa, el sistema pasa a un estado que no se considera
aceptable.
Tercero, los controles se usan para prevenir, detectar o corregir eventos ilicitos.
Vamos a ver algunos ejemplos:
Control preventivo: Las instrucciones que se ponen en un documento de entrada para
prevenir que el documento se rellene incorrectamente.
Control detectivo: Un programa que identiIica la introduccion de datos incorrectos.
Control correctivo: Un programa de comunicaciones que utiliza codigos especiales que
le permiten corregir datos corruptos debido a ruido en una linea de comunicaciones.

El proposito global de los controles es el de reducir las perdidas esperadas debidas
a los eventos ilicitos que pueden ocurrir en un sistema. Esto lo hacen en dos Iormas.
Primero, los controles preventivos reducen la probabilidad de que ocurran eventos ilicitos;
por ejemplo, las instrucciones en un documento Iuente reducen la probabilidad de que la persona que rellene
el documento cometa un error.
Segundo, los controles detectivos y correctivos reducen la cantidad de las perdidas que
aparecen si ocurre el error. Por ejemplo, si una persona de entrada de datos introduce un dato erroneo en
un sistema inIormatico, un control de validacion de entrada puede detectar que el dato es erroneo y detener el
proceso posterior. Indudablemente aparece una perdida pequea porque se demora el proceso, sin embargo no
ocurren perdidas mas grandes asociadas a una base de datos con datos erroneos. Ademas, el control podria
determinar la naturaleza del error de tecleo del dato, quizas basandose en los errores de tecleo pasados, y
corregirlo sin que la persona de entrada de datos intervenga. De esta manera, tambien se reducen las perdidas
asociadas con la correccion del error.
La tarea del auditor es:
54
determinar qu controles estn establecidos y
si funcionan para prevenir los eventos ilicitos que puedan ocurrir en un sistema.
A los auditores les concierne ver si existe al menos un control para cubrir cada
evento ilicito que pueda ocurrir en un sistema. Algunos eventos ilicitos no se cubriran
debido a que no se haya podido encontrar un control que sea eIicaz en coste (Iigura 5.1).

Figura 5.1 Eventos licitos e ilicitos en un SI
Incluso cuando un evento ilicito este cubierto por un control, los auditores deben evaluar si
el control esta Iuncionando eIicazmente. Es mas, si un evento ilicito esta cubierto por mas
de un control, los auditores se deben asegurar que todos ellos Iuncionan eIicazmente.


5.2 EL MANE1O DE LA COMPLE1IDAD
La realizacion de una auditoria de SI es un ejercicio de manejo de la complejidad,
dado que, normalmente, se tiene que estudiar una gran cantidad de sistemas. Dado que el
manejo de la complejidad es un problema comun para muchos proIesionales, ha habido
mucho trabajo de investigacion en el desarrollo de directrices para reducir la complejidad
de tareas sobre las que hay que emitir un juicio. En las siguientes subsecciones
estudiaremos dos directrices que delinean la estrategia a tomar cuando se realiza una
auditoria de SI:

1. Conocido el proposito de la auditoria, factori:ar el sistema a evaluar en subsistemas.
2. Determinar la fiabilidad de cada subsistema y la implicacion que tiene el nivel de
Iiabilidad de cada subsistema en el nivel de fiabilidad global del sistema.

5.2.1 Factorizacin en subsistemas
El primer paso a dar para estudiar un sistema complejo es partirlo en subsistemas.
Un subsistema es un componente dentro de un sistema que realiza una funcion basica
necesaria para que el sistema alcance sus objetivos Iundamentales. Un subsistema es un
concepto logico mas que un concepto Iisico. Por ejemplo, no podemos ver el subsistema de entrada
en un SI; lo que si podemos ver son cosas tales como terminales, personal de entrada de datos, pero estas
cosas son los componentes del subsistema de entrada de datos.
La factori:acion es el proceso de descomponer un sistema en subsistemas. La
Iactorizacion es un proceso iterativo que termina cuando los auditores piensan que han
partido el sistema en partes lo suIicientemente pequeas para que puedan ser comprendidas
y evaluadas. En otras palabras, cada subsistema se descompone en sus sistemas
55
constituyentes que, a su vez, se descomponen tambien hasta que los auditores puedan
comprender suIicientemente cada subsistema. El sistema a evaluar se puede describir como
una jerarquia de subsistemas, donde cada subsistema realiza una Iuncion basica que
necesita un subsistema de nivel superior (Iigura 5.2)

.
Figura 5.2 Jerarquia de sistemas v subsistemas

Para abordar el proceso de Iactorizacion se necesitan algunas bases para identiIicar
subsistemas.
Una ya se ha sugerido anteriormente, a saber, es que la esencia de un subsistema es
la funcion que realiza. Los auditores deben mirar primero la Iuncion Iundamental que
realiza un sistema para alcanzar sus objetivos. DiIerentes Iunciones delinean diIerentes
subsistemas. Por ejemplo, el objetivo global de una organizacion puede ser obtener un beneIicio; una
Iuncion critica de este sistema es la recepcion de los pedidos de los clientes. Esta Iuncion delinea el
subsistema de entrada de pedidos de clientes. El subsistema de entrada de pedidos de clientes, a su vez, se
puede partir en otros subsistemas sobre la base de las subIunciones que se deben realizar para alcanzar el
objetivo global de tener los pedidos registrados de Iorma exacta y completa. Se requeriran Iunciones para ver
si hay suIiciente inventario disponible para un pedido y para determinar si el del pedido del cliente ha
excedido su limite de credito.
Ademas de la Iuncion, la teoria de sistemas indica que hay otras dos directrices que
sirven de base para identiIicar y delinear subsistemas:
(1) cada subsistema debe ser relativamente independiente de los otros subsistemas
debilmente acoplado-
(2) cada subsistema debe tener cohesion interna en el sentido de que todas las actividades
que realice solo vayan en la direccion de conseguir la Iuncion.

En resumen, los subsistemas si no tienen estas dos caracteristicas son diIiciles de
entender y su Iiabilidad es diIicil de evaluar.
Si los subsistemas no tienen estas caracteristicas habria que intentar una Iactorizacion
diIerente. Si no hay una Iactorizacion que consiga subsistemas con estas caracteristicas,
probablemente no se pueda evaluar la Iiabilidad del sistema.

En la practica de la auditoria de SI se han encontrado dos estrategias para Iactorizar
los sistemas (Iigura 5.3).
56

Figura 5.3 Descomposicion de la funcion de sistemas de informacion

La primera de ellas pone el Ioco en las funciones gerenciales que se necesitan para
asegurar que el desarrollo, implementacion, operacion y mantenimiento de SI se realiza de
una Iorma planiIicada y controlada. El objetivo de estos subsistemas es el de proporcionar
un entorno estable para construir, operar y mantener los SIs en el dia a dia.
Se han identiIicado diIerentes tipos de subsistemas gerenciales que corresponden
con la estructura de organizativa y con alguna de las grandes Iunciones que, normalmente,
se realizan en la Iuncion de SI.

Subsistema gerencial Descripcin del subsistema
Alta gerencia Debe asegurar que el SI esta bien dirigido. Es responsable, en primer
lugar, de las decisiones estrategicas sobre como se debe usar la
inIormatica en la organizacion.

Gerencia de SI Tiene la responsabilidad global de la planiIicacion y el control de todas
las actividades inIormaticas. Tambien suministra inIormacion a la alta
gerencia para la toma de decisiones estrategicas y convierte las
estrategias para los SIS en a planes a corto plazo.

Gerencia de desarrollo de sistemas Tiene la responsabilidad del diseo, implementacion y el mantenimiento
de los sistemas de aplicacion.

Gerencia de desarrollo de programas Tiene la responsabilidad de la programacion de los nuevos sistemas y del
mantenimiento de los actuales.

Administracion de datos Tiene la responsabilidad del control y el uso de los datos de una
organizacion.

Gerencia de aseguramiento de la calidad Tiene la responsabilidad del aseguramiento del desarrollo, implantacion,
operacion y mantenimiento de los SIS conIorme a los estandares de
calidad establecidos.

Administracion de la seguridad Tiene la responsabilidad de los controles de acceso y de la seguridad
Iisica de las instalaciones de SI.

Gerencia de operaciones Tiene la responsabilidad de la planiIicacion y el control de las
operaciones del dia a dia de SI.
57

La segunda estrategia de Iactorizacion pone el Ioco en las aplicaciones. Esta
Iactorizacion corresponde con el enIoque de ciclos que los auditores tradicionalmente han
adoptado para realizar una auditoria de SI.
Los sistemas de inIormacion que soportan a una organizacion se agrupan a un
primer nivel en ciclos. Los ciclos varian dependiendo del tipo de la organizacion. Por
ejemplo, un conjunto tipico para organizaciones de Iabricacion y comerciales incluye, entre otros, los ciclos
de: (a) ventas y cobros, (b) personal y nominas (c) compras y pagos (d) inventarios y (e) tesoreria.
Cada ciclo se Iactoriza en uno o mas sistemas de aplicacion. Por ejemplo, el ciclo de
ventas comprende (1) un sistema de aplicacion de entrada de pedidos de clientes, (2) uno de Iacturacion y (3)
uno de cuentas a cobrar.
Los sistemas de aplicacion, a su vez, se Iactorizan en subsistemas, y asi
sucesivamente. El nivel mas bajo en la jerarquia de subsistemas de aplicacion esta
constituido por los siguientes:

Subsistema de aplicacin Descripcin del subsistema

Acceso Comprende a los componentes de la interIaz entre el usuario y el sistema.

Entrada Comprende a los componentes que capturan, preparan e introducen los
mandatos y los datos en el sistema.

Comunicacion Comprende a los componentes que transmiten los datos entre los
subsistemas y los sistemas.

Proceso Comprende a los componentes que realizan la toma de decisiones, el
proceso, la clasiIicacion, la ordenacion y la sumarizacion de los datos en
el sistema.

Base de Datos Comprende a los componentes que deIinen, aaden, acceden, modiIican
y eliminan los datos en el sistema.

Salida Comprende a los componentes que recuperan y presentan los
datos a los usuarios.


5.2.2 Evaluacin de la Fiabilidad del Sistema
Una vez que se ha establecido la jerarquia de susbsistemas de cada una de las dos
estrategias se puede empezar a evaluar la Iiabilidad de los controles.
Lo primero que haya que hacer es la identificacion de eventos. Para ello se empieza
por los subsistemas de nivel mas bajo, tratando de identiIicar todos los diIerentes tipos de
eventos susceptibles de ocurrir en estos subsistemas. Aunque hay que pensar tanto en los
eventos licitos como los ilicitos, la preocupacion mayor de un auditor son los eventos
ilicitos que puedan ocurrir.

5.2.2.1 Identificacin de eventos
La Iorma de identiIicar eventos se hace dependiendo de si el subsistema a analizar
es gerencial o de aplicacion.
En los subsistemas gerenciales para identiIicar tanto eventos licitos como ilicitos, se
pone el Ioco en las mavores funciones que se realizan en cada subsistema. Se considera
como se lleva a cabo cada Iuncion y se evalua lo bien que un subsistema cumple con la
vision que tenga el auditor de como se debe realizar esa Iuncion. Por ejemplo, una Iuncion
58
importante que debe ser realizada por el subsistema de alta direccion es la planiIicacion de sistemas de
inIormacion. Conocida la naturaleza de la organizacion que se esta auditando, un auditor podria determinar
que si se quiere asegurar el exito de los SIs en la organi:acion, la alta direccion debe involucrarse
fuertemente en la planificacion estrategica pero solo a un nivel moderado en la planificacion operacional.
Lo anterior, seria la decision del auditor de como debe participar la alta direccion en la planiIicacion de SI en
esa organizacion y seria la base para determinar que eventos de la planiIicacion de SI se consideraran licitos y
cuales ilicitos.
Despues se identiIicarian los eventos de la planiIicacion de SI que han ocurrido y se clasiIican en
licitos e ilicitos. Si, analizando la documentacion que haya demandado viese que la alta direccion no ha
realizado la planiIicacion estrategica, es que ha ocurrido un evento ilicito (la no realizacion). Tambien, si
viese que se involucra demasiado en planiIicacion operacional ocurre un evento ilicito.
El Iactor clave para identiIicar eventos licitos e ilicitos en los subsistemas
gerenciales es la decision del auditor de como se debe realizar una Iuncion especiIica
dentro del subsistema. La Iorma en como se debe realizar las Iunciones gerenciales de SI
dentro de una organizacion puede variar, dependiendo de las circunstancias particulares de
la organizacion. Por ejemplo, en algunas organizaciones, la planiIicacion estrategica de SI es una Iuncion
critica, sin embargo en otras es de menor importancia.
Por tanto, los auditores deben tener conocimientos v habilidad para determinar las
formas en que se pueden reali:ar las funciones gerenciales en cada organi:acion a auditar.
Si no es asi, los fuicios sobre que eventos son licitos estaran mal emitidos.

En cuanto a la identiIicacion de eventos en los subsistemas de aplicacion, se pone el
Ioco en las transacciones que pueden ocurrir en el subsistema.
Todos los eventos que ocurren en una aplicacion son consecuencia de una
transaccion. El subsistema de aplicacion inicialmente cambia de estado cuando se recibe la
transaccion. Por ejemplo, un sistema de entrada de pedidos debe registrar un pedido cuando este llega al
subsistema. A medida que el sistema va procesando la transaccion van ocurriendo mas
cambios de estado. Por ejemplo, una vez que el sistema de entrada de pedidos haya registrado un pedido,
intentara cumplimentar el pedido. Apareceran eventos licitos si la transaccion y el consiguiente
proceso este o sea autorizada, exacta, completa, sin redundancia, eIicaz y eIiciente. Si no,
apareceran eventos ilicitos.

Para identiIicar todos los eventos que, como resultado de una transaccion, pueden
ocurrir en un sistema de aplicacion, el auditor debe comprender como el sistema va a
procesar la transaccion. Para ello, los auditores normalmente utilizan tecnicas de
recorrido(walk-through), es decir, cogen una transaccion, identiIican los componentes
particulares del subsistema que procesan la transaccion y, entonces, tratan de comprender
cada paso del proceso que ejecuta cada componente del sistema. Tambien consideran todos
los errores e irregularidades (eventos ilicitos) que puedan ocurrir durante el proceso. Por
ejemplo, si se esta analizando una transaccion de credito de ventas, una vez que la transaccion haya sido
introducida en el sistema de ventas, podrian seguir el rastro el credito de ventas en cada paso de proceso
ejecutado por el programa de entrada de pedidos. Tambien podran considerar como se podria introducir la
transaccion de Iorma inapropiada y como aparecerian los subsiguientes errores e irregularidades del proceso.

Normalmente es muy costoso rastrear cada transaccion individual a traves de un
sistema de aplicacion para obtener una comprension de todos los diIerentes tipos de eventos
que pueden ocurrir en el sistema. Por esta razon, normalmente los auditores se centran en
clases de transacciones. En otras palabras, agrupan las transacciones cuyo proceso sea
similar. Una vez agrupadas las transacciones en clases tratan de entender estas
59
transacciones y los eventos que puedan ocurrir. Ademas, solo se centran en aquellas
transacciones que consideran que tendran importancia desde el punto de vista de sus
objetivos de auditoria. Cuando utilizan esta estrategia, tienen claro que no identiIicaran
todos los eventos que puedan ocurrir en el sistema.

5.2.2.1 Identificacin y prueba de los controles
Una ve: identificados los eventos que puedan ocurrir en un sistema, los auditores
deben evaluar si existen controles para cubrir los eventos ilicitos v si funcionan
adecuadamente.
Como consecuencia de esto, obtendran evidencias de la existencia y Iiabilidad de
los controles y podran determinar si las perdidas esperadas de los eventos ilicitos caen
dentro de un nivel aceptable.
Para ello, consideran cada tipo de evento ilicito que pueda ocurrir, que controles
cubren cada uno de los tipos de eventos, que Iiabilidad tienen estos controles y si aun puede
ocurrir un error o irregularidad que sea material.
Para ayudar en esta tarea hay publicadas listas de los fallos tipicos que ocurren en
los subsistemas gerenciales y de los errores e irregularidades tipicos que ocurren en los
diIerentes tipos de transacciones en los diIerentes tipos de sistemas de aplicacion, asi como
los controles que se pueden utilizar para reducir las perdidas esperadas de los errores e
irregularidades.
La tabla 5.1 es un ejemplo de una de estas listas para una transaccion de pedidos de
clientes en un sistema de aplicacion de entrada de pedidos. Esta tabla muestra una matriz
en la que las columnas muestran los errores o irregularidades que pueden ocurrir y las Iilas
los controles que se pueden establecer para reducir las perdidas esperadas de estos errores e
irregularidades. Los elementos de la matriz muestran la evaluacion que podria hacer un
auditor de la eIicacia del control para reducir las perdidas esperadas de cada tipo de error o
irregularidad.



Nota: A Alta Iiabilidad; M Fiabilidad media; B Baja Fiabilidad
Tabla 5.1 Algunos controles sobre la clase de transacciones de pedidos de clientes en un sistema de entrada
de pedidos
La evaluacion de la Iiabilidad se realiza empezando por los niveles mas bajos de la
jerarquia de subsistemas. Una vez evaluado la Iiabilidad de un subsistema de un nivel, se
puede evaluar su impacto en los en subsistemas de nivel superior. La evaluacion procede
en la jerarquia de subsistemas hasta que se haya considerado el sistema de mas alto nivel (el
sistema global).
60
Los pasos de la evaluacion son los mismos para cada subsistema de cada nivel de la
jerarquia:
primero se identiIican las transacciones de entrada en el sistema,
luego se consideran los eventos licitos e ilicitos que pueden ocurrir como resultado de
su introduccion,
finalmente se evalua la Iiabilidad de los controles que cubren los eventos ilicitos.

Cuando se esta evaluando subsistemas de nivel superior en la jerarquia es probable
que se puedan encontrar nuevos controles debido a tres razones.
La primera, los controles en los niveles mas bajos puede que no Iuncionen
correctamente. Para prevenir estas situaciones, se puede implantar un control de nivel mas
alto para cubrir los eventos ilicitos que pueden aparecer cuando los controles en los
subsistemas de nivel mas bajo Iallan en prevenir, detectar o corregirlos. Por ejemplo, un grupo
de empleados que procesan pedidos por correo. El trabajo se puede dividir entre ellos en base a la primera
letra de los apellidos del cliente; por lo que habra varios subsistemas para procesar los pedidos de diIerentes
grupos de clientes. Cada empleado debe realizar ciertos controles para prevenir, detectar o corregir los errores
en el proceso de sus pedidos. No obstante, su jeIe (gerente) debe examinar tambien la calidad de su trabajo.
Los gerentes son los responsables de la calidad del trabajo en todos los subsistemas y ejercitan un control de
mas alto nivel para el caso de que un control de mas bajo nivel no Iuncione correctamente.

La segunda, puede ser mas eIicaz en coste implantar controles en niveles mas altos.
Siguiendo con el ejemplo anterior, si los empleados estan bien instruidos y son competentes, podria no
requerirse la veriIicacion independiente (por otro empleado) de cada pedido que procese, ya que si se espera
un bajo porcentaje de errores, el coste de la veriIicacion podria ser muy alto. No obstante, su jeIe
periodicamente deberia coger una muestra de pedidos introducidos por sus empleados para evaluar la calidad
de la inIormacion introducida. El control de mas alto nivel es mas eIicaz en coste, ya que esta realizado por
una sola persona (el jeIe) que tiene mas Iacilidad con el control que varias personas (sus subordinados).

La tercera, algunos eventos solo se maniIiestan como ilicitos en sistemas de nivel
mas alto. Por ejemplo, un empleado podria estar autorizado a consultar una base de datos para obtener la
media de los salarios de las mujeres que trabajan como consultoras en una compaia, y el subsistema que
procese la transaccion considerar esta consulta como un evento licito. Este empleado podria estar autorizado a
consultar la base de datos para obtener el numero de mujeres consultoras en dicha organizacion, y el
subsistema que procese esta consulta tambien considerarla como un evento licito. En el caso de que la
compaia tuviese una sola mujer consultora, el empleado sabria ahora el salario de la consultora. Para detectar
este caso de violacion de la conIidencialidad del salario de la consultora se necesita un control en un sistema
de mas alto nivel. Solo cuando se consideren juntos los dos eventos, en principio licitos en los dos
subsistemas de menor nivel, el evento global resultara ilicito.

De lo anterior se deduce que el proceso de agregacion de la evaluacion de la
Iiabilidad de subsistemas a niveles mas altos en la jerarquia de subsistemas puede ser una
tarea diIicil. Los errores que se cometan en la evaluacion de un nivel mas bajo se
propagaran a la evaluacion de los niveles mas altos. Los auditores deben poner especial
cuidado en la obtencion de evidencias y en la evaluacion, especialmente cuando comienzan
a Iijar evaluaciones en los niveles mas bajos y se mueven a subsistemas de mas alto nivel.


61
5.3 RIESGOS DE AUDITORIA
Debido a la naturaleza de prueba que tiene la auditoria, los auditores podrian Iallar
en detectar perdidas materiales reales o potenciales. Al riesgo de que suceda tal Iallo se le
llama riesgo de auditoria.
Los auditores eligen un enIoque de auditoria y disean procedimientos de auditoria
intentando reducir este riesgo a un nivel que puedan considerarse aceptable.
Como base para determinar el nivel de riesgo de auditoria deseado (RAD), se suele
adoptar el siguiente sencillo modelo:

RAD RI * RC * RD

donde:
RI es el riesgo inherente, que reIleja la probabilidad de que pueda existir una perdida
material en alguna de las partes a auditar antes de que se considere la Iiabilidad de los
controles internos.
RC es el riesgo del control, que reIleja la probabilidad de que los controles internos en
alguna de las partes a auditar no prevengan, detecten o corrijan las perdidas materiales.
RD es el riesgo de deteccion, que reIleja la probabilidad de que los procedimientos de
auditoria utilizados en alguna de las partes de la auditoria Iallen en detectar perdidas
materiales.

Este modelo se aplica de la siguiente manera:
1. Primero se elige el nivel de riesgo de auditoria deseado. Para esto los auditores evaluan
las consecuencias a corto y largo plazo que tendria su organizacion si Iallan en detectar
perdidas materiales reales o potenciales.

2. Despues consideran el nivel de riesgo inherente. Para ello, los auditores tienen en
consideracion Iactores tales como: la naturaleza de la organizacion (es de alta
volatilidad?), la industria en la que opera (es una industria sujeta a un cambio
continuo?), las caracteristicas de la gerencia (es una gerencia agresiva y autocratica?) y
temas de contabilidad y auditoria (se utilizan practicas contables creativas?). Los
auditores entonces consideran el riesgo inherente asociado con las diIerentes partes de
la auditoria (ciclos, sistemas de aplicacion). En cada uno de las partes en que se divida
la auditoria, consideran Iactores tales como los siguientes:

Factor de Riesgo Inherente Descripcin

Sistemas Iinancieros Los sistemas que realizan el control Iinanciero sobre los activos mas
importantes de una organizacion (p.e. cobros y pagos de caja, nomina,
cuentas a pagar y a cobrar) son los que normalmente tienen el mayor
riesgo inherente. Normalmente son objetivo para el Iraude y el desIalco

Sistemas estrategicos Los sistemas que proporciona una ventaja competitiva a una organizacion
en (p.e. sistemas de Iidelizacion de clientes o proveedores, o tratan
patentes, copyrights, etc.) suelen tener un alto riesgo inherente. Pueden ser
objetivo de espionaje industrial
62
Sistemas con operaciones criticas Los sistemas que pueden daar a la organizacion si Iallan (sistema de
reservas de clientes, sistemas de control de produccion) suelen tener un
alto riesgo inherente.
Sistemas de tecnologia avanzada Los sistemas que utilizan tecnologia avanzada (p.e. sistemas de bases de
datos distribuidas, hardware distribuido) tienen un alto riesgo inherente
porque suelen ser complejos y la organizacion tiene poca experiencia con
ellos.

3. Para evaluar el nivel de riesgo de control asociado con una parte de la auditoria, los
auditores evaluan la Iiabilidad tanto de los controles gerenciales como de los de
aplicacion. Para ello, normalmente primero identiIican y evaluan los controles
gerenciales. Esto lo hacen por dos razones:
La primera es que los controles gerenciales son controles fundamentales ya que
aIectan a todos los sistemas de aplicacion; por tanto, la ausencia de un control
gerencial es un tema preocupante para los auditores. Conceptualmente, estos
controles, constituyen varios niveles protectores alrededor de las aplicaciones, tal
como se muestra en la Iigura 5.4

Figura 5.4 Controles gerenciales envolviendo a los controles de aplicaciones

Las Iuerzas que amenazan la salvaguarda de los activos, la integridad de los
datos, la eIicacia y la eIiciencia del sistema deben atravesar cada nivel superior para
poder aIectar a un nivel inIerior. Cuanto mas intactos esten los niveles superiores,
habra mayor probabilidad de que los niveles inIeriores esten intactos.
La segunda razon es que para los auditores es mas eIiciente evaluar antes los
controles gerenciales que los de aplicacion. Por ejemplo, si el auditor encuentra que en una
instalacion la direccion de SI promueve la utilizacion de estandares de documentacion de alta
calidad, es menos probable que tenga que revisar la calidad de la documentacion de cada sistema de
aplicacion que posteriormente tenga que analizar.

4. Por ultimo, aplicando el modelo, calculan el nivel de riesgo de deteccion que pueden
asumir para conseguir el nivel de riesgo de auditoria deseado. En Iuncion del riesgo de
deteccion que puedan asumir, deciden los procedimientos de auditoria que van a
utilizar. Por ello deben tener un buen conocimiento de la eIicacia para detectar una
perdida material, cuando esta exista, de los distintos procedimientos de auditoria que
pueden utilizar. Ademas, deben evaluar el nivel de Iiabilidad con el que es probable que
se apliquen los procedimientos de auditoria. Es decir, no solo deben elegir los
procedimientos de auditoria que tengan la capacidad de proporcionarles el nivel de
63
riesgo de deteccion deseado sino que tambien deben asegurar que se ejecutan
apropiadamente.

En resumen, de todo la anterior se puede deducir que los esIuerzos de auditoria se
deben centrar donde puedan producir un mayor beneIicio. En muchos casos, los auditores
no pueden obtener evidencias al nivel que desearian; por lo tanto deben tener la habilidad
para saber donde deben aplicar sus procedimientos de auditoria y como deben interpretar
las evidencias obtenidas. Durante la auditoria, los auditores tienen que tomar decisiones
continuamente sobre cual es el proximo paso a realizar. Son sus nociones de materialidad y
de riesgo de auditoria las que les guiaran en esta toma de decisiones.


5.4 TIPOS DE PROCEDIMIENTOS DE AUDITORIA
Los procedimientos que utilizan los auditores en la realizacion de una auditoria se
encuadran en los siguientes tipos:
1. Procedimientos para obtener una comprension de los controles. Sirven para obtener
una comprension de cuales son los controles administrativos que estan establecidos. Se
suelen utilizar entrevistas, inspecciones y observaciones.

2. Pruebas (de cumplimiento) de los controles. Sirven para ver si los controles estan bien
diseados y Iuncionan eIicazmente. Por ejemplo, un auditor podria entrevistar al director de
operaciones para veriIicar si revisa regularmente los inIormes de tiempo de respuesta de un sistema en
linea critico y, si lo hace, que acciones toma cuando el tiempo de respuesta no es aceptable.


3. Pruebas sustantivas. Estas pruebas se utilizan para determinar si se cumplen los
objetivos de salvaguarda de los activos, integridad de los datos, eIicacia y eIiciencia. Por
ejemplo, para el caso del tiempo de respuesta anterior, un auditor podria probar el tiempo de respuesta de
una muestra de transacciones para determinar si caen dentro de unos limites aceptables. Otro ejemplo, la
direccion puede establecer que el tiempo de respuesta medio para una aplicacion en un periodo de 12
meses sea de 2 segundos. Para veriIicar esto, los auditores pueden encuestar a una muestra de usuarios de
la aplicacion acerca del tiempo de respuesta que tienen.

4. Procedimientos de revision analitica. Estas pruebas se utilizan para sacar
consecuencias del analisis de determinada inIormacion. Por ejemplo, los auditores pueden
construir un modelo de cola o de simulacion de una aplicacion para evaluar si los recursos consumidos
por la aplicacion parecen razonables.

Normalmente, el orden de las pruebas de menor a mayor coste es el siguiente: (1)
procedimientos de revision analitica, (2) procedimientos para obtener una comprension de
los controles, (3) pruebas de los controles, (4) pruebas sustantivas. Sin embargo, el orden es
el inverso cuando se considera la Iiabilidad y el contenido de inIormacion de la evidencia
proporcionado por los procedimientos de auditoria.
De acuerdo a esto, los auditores normalmente realizan primero las pruebas menos
costosas con la esperanza puesta en que la evidencia obtenida por estos procedimientos
indique que es poco probable que hayan ocurrido graves debilidades. Si esta presuncion se
conIirmase, podrian cambiar la naturaleza, la temporizacion y la extension de las pruebas
mas costosas a utilizar. Por ejemplo, en base a su comprension de los controles y de las pruebas de estos,
64
podrian concluir que los controles estan bien diseados y que Iuncionan eIicazmente. Ante esto, podrian
decidir reducir los costes de las pruebas sustantivas de las siguientes Iormas: (1) cambiar la naturaleza de las
pruebas sustantivas utilizando pruebas menos costosas, (2) cambio en la temporizacion de dichas pruebas
realizandolas en un periodo de tiempo mas largo para reducir sus costes y (3) cambio en la extension de las
pruebas optando por tamaos de muestras mas pequeos.


5.5 VISTAZO A LOS PASOS BSICOS DE UNA AUDITORIA
Teniendo presente lo visto en las secciones precedentes sobre:
la naturaleza de los controles,
la importancia de la Iactorizacion de sistemas para reducir la complejidad,
la naturaleza y las consecuencias de los riesgos de auditoria y
los tipos de procedimientos de auditoria que los auditores pueden realizar
en la Iigura 5.5 se presenta un diagrama de Ilujo de los principales pasos a realizar en una
auditoria de SI.
Los siguientes apartados describen brevemente cada paso y resaltan aquellas partes
donde, normalmente, el auditor juega un papel importante. Aunque el diagrama presenta
una progresion secuencial en los pasos de auditoria, algunos de estos pasos se pueden
realizar concurrentemente y tambien se debe realizar alguna iteracion en los pasos; por
ejemplo, puede que haya que realizar algunas pruebas de los controles al mismo tiempo que se intenta
comprender los controles que deben estar establecidos.
65
Figura 5.5 Diagrama de flufo de los principales pasos de una auditoria de SI.

Ademas, aunque los auditores externos e internos sigan el enIoque presentado en la
Iigura, las decisiones que toman en cada paso podrian variar debido a que juegan diIerentes
papeles; por ejemplo, los auditores internos podrian gastar mas tiempo probando los controles ya que a ellos
les interesa mas la eIiciencia de los controles que a los externos.

5.5.1 Planificacin de la Auditora
La planiIicacion es el primer paso en una auditoria.
Esto signiIica comprender los objetivos a alcanzar en la auditoria, obtener
inIormacion de apoyo, asignar personal de auditoria apropiado e identiIicar areas de riesgo.
Los auditores deben decidir sobre el nivel de riesgo de auditoria deseado.
Normalmente, el nivel de riesgo de auditoria deseado se establece a nivel global de la
auditoria, mas que a nivel de cada una de las partes en que se divida la auditoria.
Como se ha dicho en el punto 5.3, el nivel de riesgo de auditoria deseado dependera
del impacto que puedan tener las decisiones que tomen los destinatarios del inIorme si para
la toma de decision es Iundamental el inIorme de auditoria.
Los niveles de riesgo inherente, normalmente, seran distintos en las diIerentes
partes en que se divida una auditoria. Algunos partes son mas susceptibles de errores,
66
irregularidades, ineIicacias e ineIiciencias que otras. Los auditores deben considerar cada
parte y evaluar los Iactores que inciden en el riesgo inherente asociado. Por ejemplo, los
sistemas que tratan sobre manejo de dinero son susceptibles de desIalcos; los sistemas con tecnologia
compleja son mas susceptibles de una utilizacion ineIiciente de recursos.

5.5.2 Evaluacin del nivel de riesgo de control
Quizas la decision mas diIicil de tomar en la Iase de planiIicacion es la opinion
sobre el nivel de riesgo del control asociado a cada parte de la auditoria. Para dar esta
opinion son especialmente importantes los conocimientos que tenga el auditor sobre SI.
Para evaluar el nivel de riesgo de control, los auditores antes tienen que entender los
controles internos que se tienen en una organizacion.

Los controles internos comprenden cinco componentes interrelacionados:
1. El entorno de control. Son los elementos que establecen el contexto del control en el
que operan los sistemas especiIicos y los procedimientos de control. El entorno de
control se maniIiesta en diIerentes Iormas como: la responsabilidad del consejo de
administracion, el estilo de direccion, la competencia proIesional, la estructura
organizativa, la delegacion de responsabilidades y las politicas y practicas de recursos
humanos.
2. Evaluacion del riesgo. Los elementos que utilizan los responsables de una organizacion
para identiIicar y analizar los riesgos que aIronta la organizacion y las Iormas en que
gestionan estos riesgos.
3. Actividades de control. Los elementos que Iuncionan para ayudar a evitar que los
riesgos se materialicen y produzcan eIectos negativos. Las actividades de control se
traducen en politicas (lo que debe hacerse) y procedimientos (como debe hacerse).
4. Informacion v comunicacion. Los elementos en que se identiIica, captura e intercambia
la inIormacion en Iorma y tiempo apropiados para permitir que el personal realice su
trabajo apropiadamente.
5. Supervision. Los elementos que aseguran que los controles internos Iuncionan
Iiablemente y que van adaptandose a las nuevas necesidades y cambios en el entorno

La comprension de los controles internos de una organizacion incluye la
Iactorizacion y el examen de los controles tanto de los subsistemas gerenciales como de los
de aplicacion.
1. Los auditores pueden comprender el entorno de control y evaluar el riesgo examinando
en primer lugar los controles gerenciales. Por ejemplo, cuando determinan si existe un comite de
sistemas de inIormacion, estan intentando comprender el ambiente de control y la evaluacion del riesgo
de los componentes del control interno.

2. Los auditores pueden comprender las actividades de control revisando tanto los
controles gerenciales como los de aplicacion. Por ejemplo, cuando revisan aquellas actividades
relacionadas con la puesta en produccion de los programas de aplicacion o la entrada de datos en una
aplicacion, estan intentando comprender los controles que se llevan a cabo.

3. Los auditores pueden comprender el componente de informacion v comunicacion
examinando los controles gerenciales y de aplicacion. Por ejemplo, cuando examinan como la
direccion comunica los papeles y responsabilidades o como las transacciones se capturan, registran,
67
procesan y sumarizan en un sistema de aplicacion, estan intentando comprender el componente de
inIormacion y comunicacion.

4. Finalmente, los auditores pueden comprender el componente de supervision
examinando primero los controles gerenciales. Por ejemplo, cuando examinan las Iormas
en que los gerentes evaluan el desempeo de los empleados, estan intentando comprender el
componente de supervision.

Los controles gerenciales pueden diIerir bastante de una organizacion a otra.
Por ejemplo, una organizacion puede tener todo el procesamiento de la inIormacion realizado en una
sola instalacion que este bajo el control de un unico departamento de sistemas de inIormacion. En esta
situacion, solo hay un director de sistemas de inIormacion a evaluar. Los auditores podrian Iactorizar este
sistema en varios subsistemas (alta direccion, direccion de desarrollo de sistemas, gerencia de programacion,
etc.) e intentar comprender los controles internos en el contexto de estos sistemas.
Sin embargo, en otra organizacion, la Iuncion de sistemas de inIormacion de una organizacion
podria estar ampliamente distribuida. Cada division podria tener la responsabilidad del desarrollo, operacion y
mantenimiento de sus propios sistemas de inIormacion. Cada una podria tener su propia instalacion y personal
inIormatico. La inIormatica de usuario Iinal podria ser substancial. Algunos usuarios podrian estar
desarrollando, operando y manteniendo sus propios sistemas. En estas circunstancias, los auditores deberian
evaluar multiples sistemas gerenciales: uno por cada division y quizas uno por cada instalacion de inIormatica
de usuario Iinal importante. Deberian considerar cada subsistema, evaluar los riesgos asociados a cada uno y
Iactorizar aquellos que consideren importantes. En resumen, para comprender los controles internos tendrian
que examinar multiples subsistemas de alta direccion, multiples subsistemas de desarrollo de sistemas,
multiples de programacion, etc.

Los controles de aplicacion tambien pueden diIerir substancialmente de una
organizacion a otra.
Por ejemplo, en una organizacion altamente centralizada, podria haber un solo conjunto de ciclos a
evaluar. Sin embargo, en una organizacion altamente descentralizada podria haber multiples conjuntos de
ciclos que tendrian que evaluarse. Cada division podria tener sus propios ciclos de ventas y cobros, de
personal y nominas, de compras y pagos, de Iabricacion, inventario y almacenes y de tesoreria. Los auditores
deben identiIicar aquellos ciclos que tengan importancia para la auditoria, Iactorizar los ciclos en sistemas y
subsistemas de aplicacion e identiIicar los controles que hayan sido puestos sobre cada clase de transacciones
que pase por los diIerentes sistemas y subsistemas.

Las tecnicas de recogida de evidencias que se suelen utilizar para ayudar a
entender los controles internos son : (a) revision de papeles de trabajo de auditorias previas,
(b) entrevistas con la alta direccion y con el personal de sistemas de inIormacion, (c)
observacion de las actividades que realiza el personal de sistemas de inIormacion y (d)
revision de la documentacion de sistemas de inIormacion.
Las evidencias se puede documentar: (a) rellenando cuestionarios, (b)
construyendo diagramas de Ilujo de alto nivel y tablas de decision y (c) preparando
inIormes.

No obstante, los auditores deben tener cuidado en no proIundizar demasiado en
esta Iase. Hay que tener en cuenta que el objetivo de esta Iase es obtener justo la
inIormacion para entender los controles internos para poder decidir como proceder en los
siguientes pasos de la auditoria.

Despus de obtener una comprensin satisfactoria de los controles internos ya
estn en disposicin de poder evaluar el nivel del riesgo de control.
68

Los auditores evaluan el riesgo de control Irente a los objetivos que la direccion
haya puesto implicita o explicitamente para el sistema. Por ejemplo, la direccion puede requerir
que un sistema: (a)consiga un cierto nivel de Ilujo de salida de inIormacion y (b) que los usuarios que utilicen
la salida del sistema tengan un determinado nivel de satisIaccion.
Los auditores deben utilizar su comprension de los controles internos para
determinar si han sido diseados apropiadamente y si estan operando para soportar los
objetivos de la direccion.

Una vez evaluado el riesgo de control los auditores deben decidir cuales son los
siguientes pasos de auditoria que van a realizar:
Si evaluan que el riesgo de control esta por debajo del limite que hayan marcado,
identiIicaran y probaran los controles especiIicos involucrados para determinar si estan
Iuncionando eIicazmente. Realizaran su trabajo con la esperanza puesta en que si las
pruebas de los controles muestran que estos Iuncionan eIicazmente puedan reducir la
extension de las pruebas sustantivas necesarias para poder dar una opinion de auditoria.
Si evaluan que el riesgo de control esta por encima del limite marcado, normalmente no
probaran los controles ya que podrian concluir que los controles probablemente no sean
eIicaces y, por tanto, que seria mas eIicaz para la auditoria pasar a realizar directamente
las pruebas sustantivas.

5.5.3 Pruebas (de cumplimiento) de los Controles
Como se ha dicho anteriormente, los auditores prueban los controles cuando
determinan que el riesgo del control esta por debajo del limite asumible. Lo hacen porque
conIian en que estas pruebas serviran como base para poder reducir la extension de las
pruebas sustantivas posteriores, que generalmente son mas costosas.
No obstante, en este momento de la auditoria aun no saben si los controles
identiIicados Iuncionan eIicazmente. Por tanto el obfetivo de las pruebas de los controles es
evaluar la eficacia de los controles.

Esta Iase, normalmente, comienzan poniendo el Ioco, otra vez, primero en los
controles gerenciales. Si las pruebas muestran que, en contra de lo esperado, los controles
gerenciales no son Iiables, no merecera mucho la pena probar los controles de las
aplicaciones y deben optar por pasar a realizar las pruebas sustantivas o Iinalizar la
auditoria emitiendo una opinion adversa (ver tipos de opinion en 6.2.5.6 ).
Los auditores realizan la evaluacion en cada subsistema gerencial y en cada
subsistema de aplicacion que sea relevante para la auditoria.
Para ilustrar como probar los controles gerenciales veamos dos ejemplos:
1. Asumamos que los auditores, cuando obtienen una comprension de los controles internos, saben que la
alta direccion tiene que realizar regularmente la planiIicacion de SI. Para probar que este control Iunciona
eIicazmente, pueden revisar las actas de las reuniones que hayan tenido los miembros de la alta direccion
para evaluar que realizan concienzudamente la planiIicacion de Iorma regular. Ademas pueden pedir una
copia del plan de SI actual para evaluar su calidad.
2. Asumamos que, cuando obtienen una comprension de los controles internos, han identiIicado los
estandares que se deben seguir para la documentacion de los programas. Como resultado de sus reuniones
con los programadores creen que estos cumplen con los estandares cuando escriben los programas. Para
probar el control, los auditores pueden seleccionar una muestra de los programas que consideren
importantes para los objetivos de la auditoria y examinar la documentacion de esta muestra para
determinar si, eIectivamente, la documentacion existe y si esta sigue los estandares establecidos.
69

Si los auditores concluyen que los controles gerenciales estan establecidos y que
Iuncionan satisIactoriamente, entonces pasan a evaluar la Iiabilidad de los controles de
aplicacion.
Para ello rastrean instancias de clases de transacciones importantes a traves de cada
control signiIicativo en los diIerentes subsistemas de aplicacion. En cada transaccion
considerada evaluan si los controles estan Iuncionando eIicazmente.
Para ilustrar como probar los controles de aplicaciones, veamos tambien dos
ejemplos:
1. Asumamos que los auditores, cuando obtienen una comprension de los controles, han identiIicado un
control que requiere que un gerente compruebe que un administrativo resuelve todos los errores
reportados durante una actualizacion realizada por una aplicacion por lotes. Los auditores podrian
seleccionar una muestra de los inIormes de actualizacion generados y veriIicar la existencia una Iirma
que indique que el gerente ha veriIicado regularmente el trabajo del administrativo.
2. Asumamos que han identiIicado un control que requiere que una persona de entrada de datos solo
introduzca pedidos de clientes que esten Iirmados por el cliente. Los auditores podrian seleccionar una
muestra de los documentos de pedidos que hayan sido introducidos en el periodo analizado y veriIicar
que tienen su correspondiente documento Iirmado por el cliente.

Despus de que los auditores hayan completado las pruebas de los controles,
vuelven a evaluar el riesgo de control.
Dependiendo de los resultados de las pruebas, podrian subir o bajar el nivel de
riesgo. Dicho de otra manera, podrian concluir que los controles son mas debiles o mas
Iuertes que lo que inicialmente previeron.
Si viesen que los controles son mas Iuertes de lo que inicialmente creian, podrian
decidir que merece la pena seguir realizando mas pruebas de controles pensando que, si
estas pruebas son satisIactorias, van a reducir mas adelante las pruebas sustantivas.

El enIoque de esta Iase puede variar dependiendo de si la auditoria es externa o
interna. Si los auditores internos encuentran debilidades en los controles, pueden extender
sus investigaciones para tener un mejor conocimiento de la naturaleza y de las
implicaciones de estas debilidades. Su objetivo podria ser dar una recomendacion basada en
este conocimiento mas proIundo para rectiIicar dichas debilidades. Sin embargo, los
auditores externos cuando encuentran debilidades en los controles tienden a no proIundizar
mas y proceden a realizar pruebas sustantivas mas extensas debido al mayor riesgo de
control que perciben.

5.5.4 Pruebas (sustantivas) de las transacciones
Estas pruebas se utilizan para evaluar si ha habido un proceso erroneo o irregular de
alguna transaccion. Estas son pruebas tales como: rastreo del diario de las transacciones
hasta los documentos Iuentes que las han originado, el examen de la adecuacion de los
datos de un Iichero y pruebas de la exactitud del proceso.
Para la realizacion de estas pruebas suele ser de gran utilidad la disponibilidad de
herramientas inIormaticas. Por ejemplo, los auditores podrian utilizar software general de auditoria para
veriIicar si el interes pagado en las cuentas bancarias se ha calculado correctamente.

Desde una perspectiva operacional, los auditores utilizan las pruebas de las
transacciones para evaluar si las transacciones han sido procesadas eIicazmente y
70
eIicientemente. Por ejemplo, para indicar la eIicacia de una base de datos, los auditores podrian examinar
una muestra de las consultas registrada en el registro de transacciones para ver si las consultas han sido
generadas por una amplia variedad de usuarios de la base de datos. Para evaluar la eIiciencia, los auditores
podrian examinar el tiempo de proceso total de una muestra de trabajos que se hayan enviado a un sistema de
aplicacion. Aqui tambien se puede utilizar soItware general de auditoria para seleccionar una muestra de las
consultas a una base de datos registradas en un registro de transacciones para su evaluacion.

Normalmente realizan las pruebas de las transacciones en diIerentes Iechas para
poder reducir la cantidad de pruebas sustantivas de los resultados globales que tendrian
que realizar cerca de la Iecha de emision del inIorme de auditoria. Por ejemplo, si el tiempo de
respuesta de una muestra de transacciones que ocurren durante el periodo auditado es satisIactorio, los
auditores podrian reducir el numero de usuarios a encuestar, cerca de la Iecha del inIorme de auditoria, para
determinar si consideran que los tiempos de respuesta son satisIactorios.

Si los resultados de las pruebas de transacciones no son satisIactorios, las pruebas
sustantivas de los resultados globales tendran que ser mas extensas.

5.5.5 Pruebas (sustantivas) de los resultados globales
Los auditores utilizan estas pruebas para obtener evidencia suIiciente para emitir la
opinion Iinal en el inIorme de auditoria. Normalmente, estas pruebas son las mas costosas
de la auditoria (aunque ya se argumenta que los costes y beneIicios de estas pruebas esta
cambiando al disponer cada vez mas de herramientas inIormaticas para realizar estas
pruebas), por lo que los auditores deben disear y ejecutar estas pruebas con especial
cuidado.
Veamos dos ejemplos para entender la estrategia que siguen en esta Iase:
1. Los auditores pueden trabajar con los usuarios de una aplicacion para estimar las perdidas que ellos creen
que son debidas a que el sistema no les proporcionan los datos que necesitan para una toma de decisiones
de alta calidad.
2. Los auditores podrian intentar estimar los costes de las ineIiciencias que han ocurrido debido a que Iallos
en la planiIicacion de SI han llevado a la compra de un hardware inapropiado.

A menudo se requiere el soporte de herramientas inIormaticas para realizar pruebas
sustantivas de los resultados globales de una Iorma eIicaz y eIiciente. Por ejemplo, se puede
utilizar un paquete de simulacion para estimar cuanto trabajo de salida se ha perdido debido a que la
plataIorma de hardware/soItware este mal conIigurada.

5.5.6 Finalizacin de la auditora
A diIerencia de la auditoria de cuentas, en que esta Iormalizada el tipo de opinion de
auditoria, en auditoria de SI los auditores Iormulan la opinion de la Iorma que crean
oportuna para comunicar claramente sus hallazgos y sus juicios. No obstante, un inIorme de
auditoria tipico deberia contener:
una introduccion que describa los objetivos de la auditoria, su alcance y la estrategia
general utilizada,
un resumen de los halla:gos criticos,
las recomendaciones dirigidas a los mayores temas que aparecen de los hallazgos y
los datos que soportan a los halla:gos criticos que aparecen en el inIorme.

A los auditores tambien les concierne realizar una prognosis sobre el sistema, dicho de
otro modo, aunque hayan concluido que la auditoria es satisIactoria pueden creer que
71
existen debilidades en el control que pueda llevar a que en el Iuturo el sistema no alcance
sus objetivos si no se corrigen dichas debilidades. Por ejemplo, los clientes podrian demandar a una
organizacion si esta no proporciona los productos o servicios comprometidos debido a que su sistema
inIormatico no este operacional.

Por lo tanto, a la conclusion de la auditoria, los auditores realizan una importante
Iuncion, que es la de dar a la direccion un inIorme documentando de todas las debilidades
del control que hayan identiIicado, las potenciales consecuencias de dichas debilidades y
algunas recomendaciones sobre acciones correctivas.


5.6 AUDITORIA ALREDEDOR Y AUDITORIA A TRAVES DEL
ORDENADOR
Una decision importante que el auditor tiene que tomar para probar los controles es
la de si incluir o no a todo el proceso inIormatico para probar los controles.
Las Irases auditoria alrededor del ordenador y auditoria a traves del ordenador
vienen del pasado. Aparecieron cuando se estaba debatiendo acerca del conocimiento
tecnico que se requeria para auditar sistemas inIormaticos. Algunos argumentaban que se
requeria poco conocimiento porque los auditores podian evaluar los sistemas inIormaticos
analizando solamente la entrada y la salida del sistema. Sin embargo, otros argumentaban
que las auditorias no se podian hacer apropiadamente si no se examinaba y evaluaba el
trabajo interno (el procesamiento) de dichos sistemas. DesaIortunadamente, los argumentos
del primer grupo muchas veces eran motivados por su incompetencia tecnica. De modo
que, entre algunos auditores, la Irase auditoria alrededor del ordenador tiene
connotaciones negativas. Sin embargo, hoy en dia se reconoce que ambos enIoques tienen
sus pros y sus contras y que se debe considerar la utilizacion de cada uno de ellos
cuidadosamente en la planiIicacion y ejecucion de una auditoria para que esta sea lo mas
eIicaz en coste.

5.6.1 Auditora alrededor del Ordenador
Este tipo de auditoria consiste en llegar a dar una opinion de auditoria analizando
los controles gerenciales y solo la entrada y la salida de las aplicaciones.
Los auditores inIieren la calidad del proceso sobre la base de la calidad de la entrada
y de la salida del sistema. El proceso no se analiza directamente, el auditor ve al sistema
inIormatico como una caja negra.
Este tipo de auditoria puede ser adecuado cuando una aplicacion tiene alguna de las
tres siguientes caracteristicas:
1. El sistema es simple y orientado al proceso por lotes. Estos sistemas tienen las
siguientes propiedades:
Su riesgo inherente es bajo. No es probable que sucedan errores materiales o
irregularidades o que se asocien a operaciones ineIicaces o ineIicientes.
La logica del sistema es sencilla y no se han desarrollado rutinas especiales para
procesar los datos.
Las transacciones de entrada se agrupan y se puede realizar el control por los
metodos tradicionales, por ejemplo, la segregacion de Iunciones y la supervision de
la gestion
72
El proceso consiste basicamente en clasiIicar los datos de entrada y actualizar los
Iicheros maestros de Iorma secuencial.
Hay una traza de auditoria clara y se preparan inIormes detallados en los puntos
clave del proceso.
El entorno de trabajo es relativamente constante, el sistema se modiIica raramente y
se pone poco estres en el sistema
2. Cuando un sistema de aplicacion utiliza un paquete estandar de soItware es mas eIicaz
en coste auditar alrededor del ordenador. Si el paquete:
(a) se adquiere a un proveedor de probada calidad,
(b) ha sido ampliamente utilizado y
(c) esta libre de errores,
el auditor puede decidir no probar directamente los aspectos de proceso del sistema
directamente. No obstante, el auditor se debe asegurar de que:
(1) el paquete no se ha modiIicado en la instalacion de ninguna Iorma
(2) que existen controles adecuados sobre el codigo Iuente, codigo objeto y la
documentacion para prevenir la modiIicacion no autorizada del paquete; y
(3) existen controles de alta calidad sobre la entrada y la salida en el paquete.

3. Cuando se tiene una alta conIianza en los usuarios de la aplicacion. En este caso el Ioco
de la auditoria se pone en los controles de usuario y no en los controles del proceso
inIormatico.

La ventafa primaria de auditar alrededor del ordenador es la simplicidad. Se puede
Iormar Iacilmente auditores con poco conocimiento tecnico de inIormatica para realizar la
auditoria, pero deben ser dirigidos por un especialista de auditoria de sistemas de
inIormacion.
Sin embargo este enIoque tiene dos grandes desventafas: La primera, que solo es
aplicable a un tipo de sistema inIormatico muy restringido. No se debe utilizar en sistemas
que tengan alguna complejidad en terminos de tamao o tipo de proceso. La segunda, que
el auditor no puede valorar muy bien la probabilidad de la degradacion del sistema cuando
el entorno sea cambiante. Al auditor le debe preocupar la habilidad del sistema de Iuncionar
en un entorno cambiante. Los sistemas se deben disear y los programas se deben escribir
de Iorma que un cambio en el entorno no ocasione que el sistema procese los datos
incorrectamente o que se degrade rapidamente.

5.6.2 Auditora a travs del Ordenador
Actualmente la mayor parte de las auditorias de SI se realizan teniendo en cuenta el
proceso inIormatico. El auditor examina el proceso inIormatico para comprobar: (a) la
logica y los controles que existen en el sistema inIormatico y (b) los registros producidos
por el sistema. Dependiendo de la complejidad del sistema a ser auditado, la tarea puede ser
simple o requerir una amplia competencia tecnica por parte del auditor.
Hay varias situaciones donde se debe utilizar la auditoria a traves del ordenador:
1. El riesgo inherente del sistema es alto
2. El sistema de aplicacion procesa grandes volumenes de entradas y produce grandes
volumenes de salidas lo que hace diIicil el examen detallado directo de la validez de la
entrada y de la salida.
73
3. Hay partes importantes del sistema de control interno imbuidas en el sistema
inIormatico. Por ejemplo, en un sistema de banca en linea un programa puede agrupar las
transacciones de los puestos individuales para dar los totales de control para la conciliacion al Iinal del
dia de proceso.
4. La logica del sistema es compleja y hay grandes porciones del codigo cuyo objetivo es
Iacilitar el uso del sistema o el proceso eIiciente.
5. Por consideraciones de coste-beneIicio cuando haya huecos sustanciales en la traza
visible de auditoria.

La ventafa primaria de utilizar este enIoque es que el auditor tiene una mayor
capacidad para probar un sistema inIormatico de Iorma eIicaz. Puede ampliar el rango y la
capacidad de las pruebas que realiza y, asi, incrementar la conIianza en la Iiabilidad de la
recogida y evaluacion de las evidencias. El auditor, mediante el analisis del proceso del
sistema, tambien puede valorar la habilidad del sistema de Iuncionar sin degradarse en un
entorno cambiante.
Las principales desventafas de este enIoque son, algunas veces, el alto coste
necesario y la necesidad de una amplia experiencia tecnica cuando el sistema es complejo.