Introducción 1

Por una auditoria y control efectivos. 2

Auditoría de Sistemas, Definición y objetivos 5
Metodología Cobit 7
Resumen Ejecutivo 7
Marco Referencial (Framework) 8
Los Objetivos de Control 8
Las Guías de Auditoría. 8
Dominios y Procesos de COBIT 8
Objetivos propuestos por William Emory 9
Administrativa. 9
Soluciones aplicativas y programación 9
Servicios. 9
lista de algunos objetivos. 15
la auditoría a través del computador. 12
definicion. 12
ventajas y desv. de la auditoria a traves del computador 20 datos de prueba 12
enfoques y técnicas de auditoría para probar los sistemas de ped 12
técnicas de auditoria asistidas por computador. 17
tipos de prueba de auditoria. 17
alcance de las pruebas de auditoria. 17
enfoques para aplicar pruebas de auditoria 18
enfoques de auditoria para los SISTEMAS DE APLICACIÓN. 19
Introducción
El presente documento lo he elaborado para los estudiantes de la facultad de contaduría
pública de ha sido elaborado como material de consulta para los estudiantes de la
UNIMINUTO de la cátedra de auditoria de sistemas.

Los contenidos de este material contiene artículos e información que pueden permitir al
estudiante entender la importancia de la Auditoría de Sistemas y adicionalmente conocer la
forma como el Auditor de Sistemas realiza sus funciones.
Este documento sean actualizando con base en los lineamientos que periódicamente emite
ISACA (Information Systems audit. And Control Association) en el ámbito mundial.
La intención es que el estudiante tenga a su disposición una variedad de objetivos de
Auditoría de Sistemas así como modelos de los papeles de trabajo que utiliza el Auditor de
Sistemas.
Incluimos además información básica sobre las Técnicas de Auditoría Asistidas por
Computador (TAAC'S) que puede utilizar un Auditor en del desarrollo de sus funciones.

Por una auditoria y control efectivos.1

A pesar de su importancia, muchas organizaciones en nuestro medio carecen por completo
de auditoría y control a los sistemas de procesamiento electrónico de datos. Puntos de
partida para su análisis.
En su existencia, relativamente breve, el computador ha emergido vertiginosamente hasta
convertirse en parte integral de la vida de las organizaciones; ha logrado alterar en menos
de dos generaciones su estructura y funciones.
Muchos factores han contribuido para que las formas de control requeridas por este nuevo
ambiente no se hayan adoptado oportunamente. Los más significativos tienen que ver con
la complejidad técnica de los modernos sistemas de cómputo, verdaderas maravillas de la
ingeniería, veloces en el proceso y sofisticados tanto en el hardware como en el software.
Los sistemas son diseñados, configurados y programados por auténticos especialistas
quienes, como es entendible, han estado más comprometidos con la velocidad del proceso y
la elegancia técnica que con la verificación y control.
Desde 1976 se ha presentado un creciente interés en el tema de la auditoría y control a
sistemas de procesamiento electrónico de datos; sin embargo, muchas organizaciones en
nuestro medio carecen por completo de esta función o cuando existen no se ajusta a los
requerimientos mínimos generados por las capacidades actuales de proceso, los volúmenes
de datos, la diversidad de programas y la cantidad de usuarios, que hacen más complejos
los sistemas de información.
Cada día se amplía el uso del computador en diferentes actividades de la empresa, se
producen nuevos programas y el usuario final tiene mayor acceso a la información.
Todo esto, sumado al vertiginoso desarrollo tecnológico, nos hace pensar que se amplían
las barreras entre los complejos sistemas de información y la capacidad para ejercer una
auditoría y control efectivos.
Es nuestro interés explorar diferentes aspectos relacionados con este tema, desde una
definición comprensiva de la auditoria en informática o de sistemas, hasta algunas técnicas
que permitan a nuestros clientes evaluar su propia estrategia y el estado actual de esta
actividad en sus organizaciones.
Varios son los autores que han escrito sobre este tema y cuyas obras han llegado a nuestro
medio. Entre otros pueden destacarse: Elise Jancura, Donald Wuatne, Peter Turning,
Gabriel1 Tomado de la Revista ACTUALIDADES/17 publicada por IBM de Colombia

Rotherberg, Ron Weber, Leonard Krauss, Donn Parker, Keagle Davis, William Perry,
Javier Kuong, James Martin y F.J. Fitzgeral.
Los temas favoritos han sido El Control, La Auditoria, El Fraude, El Sistema de
Información Contable y La Seguridad.
Pero no hay duda que la base más importante de toda esta literatura corresponde al estudio
preparado por el Instituto de Auditores Internos de los EE.UU., con datos recopilados
por el Stanford Research Institute y con el patrocinio de IBM.
Dada la trascendencia que ha tenido para el desarrollo de la Auditoría de Sistemas vale la
pena comentar sus más importantes conclusiones como punto de partida para un análisis de
tan vital tema.
1. La responsabilidad primaria respecto al control interno corresponde a la Alta
Gerencia, en tanto que la responsabilidad operacional (exactitud, oportunidad y
confiabilidad de la información), corresponde al usuario.
No hay duda que la Gerencia de la empresa en el ejercicio de sus cuatro principales tareas
administrativas debe estar considerando como recurso importante la información,
inmediatamente después del recurso humano. En este orden de ideas deberá proyectar su
responsabilidad de control a través de toda la organización a fin de que sea manejada,
divulgada y salvaguardada de acuerdo con el valor que tiene para la operación y estabilidad
de la empresa. Desde el punto de vista las fallas parecen no ser mayores.
Sin embargo, no se puede estar tan seguro en cuanto a la parte operacional. Con frecuencia
no hay un entendimiento claro del valor de la información y por lo mismo de los niveles de
Clasificación que requiere por la administración de su confidencialidad.
Se pierde entonces con facilidad el concepto de propiedad, el de autorización para el acceso
y uso de los datos, el control de almacenamiento y las normas para la divulgación de la
información.
Control, auditabilidad, recuperación, respaldo, seguridad y unos cuantos conceptos más,
con mucha frecuencia, no son claves para el usuario, que en muchas ocasiones no está en
capacidad de exigir y/o dar un tratamiento adecuado a datos, información, programas y
equipos.
2. Es necesario mejorar los controles, esto es, ampliar el cubrimiento de control
interno al ambiente de procesamiento de datos. Los conceptos continúan siendo los
mismos pero la forma en que se debes aplicar es diferente. Se deben identificar y ejecutar
programas de control interno con objetivos claramente definidos para:
El desarrollo de nuevos sistemas.
Las operaciones de centros de cómputo.
Los cambios de tecnología.
Garantizar huellas confiables de auditoria que permitan evaluar y verificar el proceso.
Establecer las relaciones entre las diferentes funciones de la organización.
3. Los auditores deben participar en el proceso de desarrollo e implantación de nuevos
sistemas para garantizar el empleo de controles adecuados. Es demasiado tarde realizar
esta tarea cuando los sistemas ya han sido instalados, con los problemas adicionales
causados por las modificaciones que se reflejan tanto en costos como en tiempo.
Adicionalmente facilita la inclusión de herramienta para la auditoria como parte integral de
los nuevos sistemas.
4. La verificación de los controles debe hacerse antes y después de la instalación. De
aquí la importancia de las pruebas de preinstalación que permitan comprobar el logro de los
requerimientos básicos no solo del sistema en sí, sino también la efectividad y operatividad
de los controles definidos. Posterior a la instalación se requieren las revisiones periódicas
que deben incluir la verificación de control y los resultados del proceso.
5. A medida que se incrementan y hacen más complejos los sistemas de procesamiento de
datos se hace necesario que el auditor se involucre más en todas las fases del proceso.
Bases de datos, procesamiento distribuido, comunicaciones, archivos electrónicos, sistemas
integrados, manejo de imágenes, control de proceso, transferencia electrónica de fondos,
etc.,
hacen que la responsabilidad sea compartida por diferentes facilidades y por muchos
usuarios con múltiples fuentes de información y variedad de recursos tanto en hardware
como en software.
El auditor de sistemas debe hacer uso de las herramientas apropiadas, dentro de las cuales
la más valiosa e importante es el computador mismo, y desarrollar habilidades que hacen de
él un especialista dentro de la organización de auditoria interna.
6. La sexta conclusión se refiere a la importancia de la función de Auditoría de Sistemas
dentro de la organización.
Pocos auditores internos tienen tanto el conocimiento como la experiencia requeridos para
adelantar auditorias efectivas a los actuales sistemas electrónicos de procesamiento de
datos.
7. Varias organizaciones están preparando algunos de sus profesionales de sistemas en
disciplinas propias de la auditoria.
Otras están transmitiendo a sus auditores internos conceptos y practicas relacionadas con el
procesamiento electrónico de datos.
8 Y finalmente algunas organizaciones mayores están brindando entrenamiento a sus
auditores y reforzando grupos interdisciplinarios con especialistas de sistemas.
7. Se requieren nuevas herramientas y técnicas de auditoria a medida que los sistemas
de información se vuelven lógica y técnicamente más complejos.
A pesar de que crece el numero de auditores que hacen uso del computador para el ejercicio
de su labor, muchos aún continúan con al concepto de auditoria “alrededor o a través
de...”.
Ya existe una variedad de programas especializados y muchos métodos funcionales de
prueba que permiten satisfacer los objetivos básicos. Sin embargo, el auditor debe
prepararse no solo para hacer uso de estas herramientas sino para desarrollar sus propias
ayudas.
8. Finalmente, se establece la necesidad de adelantar evaluaciones periódicas de los
programas de auditoria y control, los cuales deben ser iniciados por la alta Gerencia.
Estas revisiones deberían adelantarse en conjunto por parte de las Gerencias de auditoria
interna y procesamiento de datos. Con ello se pretende analizar objetivos de auditoria y
control, las guías para el control interno, el alcance de la auditoria, y la participación en el
desarrollo e investigación de nuevos sistemas y la educación, entre otros.
Tres deberían ser los principales objetivos:
a) Evaluación de las prácticas actuales de auditoria y control, y una revisión de las
capacidades de procesamiento de datos dentro de la función de auditoria.
b) Identificación de las tendencias, tanto en el área de desarrollo como en el uso de nuevas
tecnologías.
c) Formulación de programas que permitan optimizar la efectividad de la auditoria con
ambiente de procesamiento de datos.
Para llevar a la práctica en forma completa estas condiciones, se requiere la función de
Auditoría de Sistemas, con personal altamente calificado, el cual aún es escaso, puesto
que no son muchas las instituciones educativas calificadas que ofrecen un programa
completo para la formación de estos profesionales.
9 Auditoría de Sistemas, Definición y Objetivos.2
En 1982 Ron Weber afirmaba que las metodologías para el control y la auditoria del
procesamiento Electrónico de Datos (PED) aún estaban en la infancia.
A llegado el año 2000 y deberíamos preguntarnos cuál es el nivel de madurez que ha
adquirido en el medio esta importante función.
Ello depende lógicamente del grado de concientización alcanzado por quienes tienen la
responsabilidad de velar por los activos (tangibles o intangibles) de las organizaciones. Sin
embargo, parece que sigue siendo cierto que la tecnología ha avanzado a una velocidad
mayor que el desarrollo de metodologías viables para el ejercicio de la Auditoría de
Sistemas, para la cual se pretende dar una definición para tratar de entender en que
realmente consiste.
ISACA define la Auditoría a los sistemas de información como cualquier auditoría que
involucra la revisión y evaluación de todos los aspectos (o una porción de ellos) de los
sistemas de información automatizados incluyendo procesos no automatizados y las
interfases entre ellos.
El mismo Weber la define como: “el proceso de recolectar y evaluar evidencias para
determinar si un sistema de PED protege los activos, mantiene la integridad de los datos,
contribuye al logro de los objetivos de la organización en forma efectiva y gasta los
recursos eficientemente”.
Es así como la Auditoría de Sistemas soporta el logro de los objetivos de la auditoria
tradicional porque los conceptos básicos se mantienen, en tanto que se da un cambio
fundamental en la forma.
La información por si misma siempre ha sido un valioso activo pero ahora se obtiene y se
administra mediante sofisticados sistemas compuestos por otros activos tales como
maquinas, programas, archivos de datos, documentación, suministros y el recurso humano,
el más importante de todos los recursos.
La integridad de los datos es un concepto fundamental en auditoria y está directamente
relacionada con otros atributos o cualidades básicas de la información tales como
Confiabilidad, oportunidad, confidencialidad, etc., las cuales se mantienen mediante
sistemas de seguridad y que lógicamente presentan un costo para la organización.
Por lo tanto los beneficios obtenidos deberán exceder los costos correspondientes a los
diferentes niveles de control cuyo uso debe estar en relación directa con su efectividad.
2Tomado de la Revista ACTUALIDADES publicada por IBM de Colombia
10 Qué tantos controles, depende del valor de los datos y su contenido informativo, con lo
cual se define el grado de confidencialidad, mediante el cual el propietario de la
información establece quien o quienes pueden hacer uso de ella.
Mientras más alto sea el nivel de confidencialidad, quiere decir que mayor es el valor de la
información para la toma de decisiones y que por lo tanto se hace mas critica la integridad
de los datos.
Que tan eficaz es el sistema PED. Esta en relación con el cubrimiento de las necesidades y
requerimientos de los usuarios.
La acción de Auditoría de Sistemas se enfoca normalmente hacia sistemas en operación
pero deberá ejercerse durante todo el ciclo del desarrollo especialmente para sistemas
complejos o muy costosos donde una evaluación independiente garantice que se tendrán en
cuenta todos los requerimientos del usuario.
Finalmente qué tan eficiente es el sistema, depende de los recursos empleados parar el
logro de los objetivos.
Máquinas, sistemas operacionales, trabajos, etc., son recursos escasos requeridos por los
diferentes programas de aplicación, los cuales no pueden considerarse en forma aislada y
menos aun si se tiene en cuenta la capacidad del sistema que tiende fácilmente a ser
excedida. No es posible optimizar una aplicación en particular a expensas de otras.
El auditor de sistemas debe asistir a la Gerencia con sus recomendaciones en la
racionalización del uso y la adquisición o ampliación de los recursos dedicados al
procesamiento de datos.
Hoy por hoy el auditor de sistemas, o mejor como debería llamarse, el auditor del sistema
de información, requiere de una formación especial y de herramientas técnicamente
dispuestas para el adecuado ejercicio de su actividad.
Con frecuencia muchos se han desanimado para regresar a sus tareas ya sean en el área de
sistemas o de auditoria porque no reciben los recursos adecuados y en algunas ocasiones no
cuentan con el apoyo que la Gerencia debe darles para una labor productiva.
Por esta razón es tan importante hacer una evaluación de los objetivos para que esta función
no se limite, como en el pasado, a la implantación y evaluación de controles.
El auditor de hoy debe tener a su alcance la tecnología del computador como principal
herramienta: capacidad para el muestreo estadístico, programas de consulta,
microcomputadores con facilidad de procesamiento stand alone y en línea, documentación
actualizada, comunicaciones, facilidades integradas de prueba, etc. Es posible que se deba
regresar a una “Auditoria alrededor de...”, pero con una mentalidad diferente.
11 De todas maneras el éxito de la función de auditoria depende del grado de participación
y su contribución para el logro de los más importantes objetivos de la organización. Por lo
tanto para definir sus propios objetivos deberá considerarse:
La estructura y los objetivos corporativos.
Las características del sistema de información.
Las necesidades y los objetivos de otras auditorias.
La capacidad y experiencia del auditor y los recursos con que cuenta.
Establecer objetivos de auditoria es la primera acción dentro de una metodología que
incluyen
13 pasos que serán comentados posteriormente.
Puesto que no existen organizaciones iguales, el auditor deberá seleccionar de una amplia
lista sus propios objetivos pero por lo general corresponden a preocupaciones comunes de
auditoria y que pueden estar asociados con uno o más riesgos.
Las cuatro preocupaciones son:
Suficiencia de control interno para garantizar la integridad de las transacciones, su
autorización, su exactitud, su registro apropiado y la calidad de los resultados.
Continuidad para garantizar la presencia de la organización en el negocio y la
recuperación en caso de desastre. Los peligros asociados son la perdida o destrucción de los
datos y la interrupción del negocio.
Posibilidad de fraude, irregularidades o actos ilegales.
Políticas de operación y suficiencia de los procedimientos. Así se garantiza que la
organización opere efectiva, económica y eficientemente. Los peligros asociados son:
Decisiones erróneas, perdida de ganancias y desventaja competitiva.
Para ayudar al auditor en la preparación de sus propios objetivos, ISACF creo la
metodología Cobit (Governance, Control Objectives for Information and Related
Technology).
Metodología Cobit
Alrededor de los años 90 la Fundación de Auditoría y Control en Sistemas de Información
(ISACF Information Systems audit. And Control Foundation) reconoció la importante que
es la administración efectiva de la información y las tecnologías relacionadas para la
supervivencia y éxito de las organizaciones. De acuerdo con esto, ISACF inició el proyecto
de recopilar
12 información sobre auditoría, control y seguridad en los sistemas de información y
analizar sus procesos. Producto de este estudio apareció Cobit en 1998 COBIT es en
realidad un acrónimo formado por las siglas derivadas de Governance, ControlObjectives
for Information and Related Technology (objetivos de control para tecnología de
información y tecnologías relacionadas).
COBIT es una herramienta que reúne normas y estándares de jure y de facto de la ISO, de
COSO, IFAC, IIA y AICPA entre otros.
COBIT encadena la tecnología de la información con las prácticas de control y crea un
recurso vital para la Gerencia, los profesionales en control y los auditores.
COBIT aplica a todo lo largo de la organización incluyendo personal de sistemas, usuarios,
minicomputadores, mainframes y sistemas cliente servidor, entre otros. COBIT se basa en
que los recursos de tecnología deben ser administrados y agrupados en procesos naturales
con el objeto de proveer información actualizada y confiable para que la organización logre
sus objetivos.
Los usuarios de COBIT son:
La alta Gerencia puede fundamentar decisiones sobre inversiones en TI y el rendimiento
de las mismas
Los usuarios de TI pueden obtener un aseguramiento sobre la seguridad y el control de
productos adquiridos en forma externa
Los auditores pueden fundamentar sus opiniones sobre el control en TI y su impacto en la
empresa
Los responsables de TI pueden identificar los controles que requieren establecer en su
área
COBIT está compuesto por los siguientes productos:
Resumen Ejecutivo
El resumen ejecutivo es un documento dirigido a la alta gerencia, que presenta los
antecedentes y la estructura básica de COBIT. Hace una descripción general de los
procesos, los recursos y los criterios de información que determinan la “columna vertebral”
de COBIT.
Marco Referencial (Framework)
El marco referencial incluye la introducción contenida en el resumen ejecutivo, presentando
las “guías de navegación” que orientan al lector en la exploración del material de COBIT.
El Marco Referencial hace una presentación más detallada de los 34 objetivos de control de
alto nivel (34 procesos) para los cuatro dominios
13 Los Objetivos de Control
Los objetivos de control integran en su contenido el material del resumen ejecutivo y del
marco referencial. Adicionalmente, presenta objetivos de control detallados para cada
objetivo de alto nivel.
Se incluyen de 3 a 30 objetivos detallados por cada objetivo de control de alto nivel,
totalizando
Las Guías de Auditoría
Las guías de Auditoría también incorporan el resumen ejecutivo y el marco referencial.
Hacen una presentación del proceso generalmente aceptado de Auditoría (obtener
entendimiento, evaluar los controles, evaluar el cumplimiento y substanciar los riesgos).
Este documento incluye guías detalladas para auditar cada uno de los 34 objetivos de alto
nivel.
Dominios y Procesos de COBIT
Dominio Planeación y Organización
Definir un Plan Estratégico de Tecnología de Información
Definir la Arquitectura de Información
Determinar la dirección tecnológica
Definir la Organización y las Relaciones de TI
Manejar la Inversión en Tecnología de Información
Comunicar la dirección y aspiraciones de la gerencia
Administrar Recursos Humanos
Asegurar el Cumplimiento de Requerimientos Externos
Evaluar Riesgos
Administrar proyectos
Administrar Calidad
Dominio Adquisición e implementación:
Identificar Soluciones
Adquirir y Mantener Software de Aplicación
Adquirir y Mantener la Arquitectura de Tecnología
Desarrollar y Mantener Procedimientos relacionados con Tecnología de Información
Instalar y Acreditar Sistemas
Administrar Cambios
Dominio Prestación de servicio y soporte:
Definir Niveles de Servicio
Administrar Servicios prestados por Terceros
14 Administrar Desempeño y Capacidad
Asegurar un Servicio Continuo
Garantizar la Seguridad de Sistemas
Identificar y Asignar Costos
Educar y Entrenar a Usuarios
Apoyar y Asesorar a los Clientes de Tecnología de Información
Administrar la Configuración
Administrar Problemas e Incidentes
Administrar Datos
Administrar Instalaciones
Administrar Operaciones
Dominio Monitoreo:
Monitoreo de los procesos
Evaluar qué tan adecuado es el Control Interno
Obtener aseguramiento independiente
Proporcionar Auditoría Independiente.
Para mayor claridad y complementar conocimientos recomiendo remitirse directamente al
COBIT y leer el Sumario Ejecutivo que adjunto.
Objetivos propuestos por William Emory
William Emory ha escrito una lista de 120 puntos que él denominó lista de lavandería. Se
pretende conteste ejercicio recolectar todos los posibles objetivos relacionados con el PED.
Muchos podrían no ser calificados como objetivos sino mas bien como metas de
desempeño o pasos de un trabajo continuado.
Sin embargo se pretende mas bien, ayudar a definir los limites de responsabilidad del
auditor y los puntos de contacto con otros grupos de auditoria o de control.
Cuando el auditor elabore su propia lista, deberá tener en mente uno o más procedimientos
posibles para lograr cada objetivo y proceder a organizarla de tal manera que los
procedimientos sean paralelos a los objetivos y dispuestos de acuerdo a las áreas
funcionales de PED para que se mantenga:
- La integridad de los datos.
- La prevención contra accesos no autorizados a la información.
- La disponibilidad del uso de los recursos.
A manera de ejemplo podría usarse un esquema como este, por áreas:
15 Administrativa
Organización y personal.
Planeación.
Análisis de costos.
Desarrollo de procedimiento y controles.
Aspectos legales.
Soluciones aplicativas y programación
Desarrollo de aplicaciones.
Mantenimiento del software.
Operación
Salón del computador.
Dispositivos de entrada y salida.
Comunicaciones.
Soporte técnico.
Servicios
Soporte de auditoria
LISTA DE ALGUNOS OBJETIVOS
Para ayudar al auditor en la programación de su propia lista, se incluyen algunos de los
objetivos propuestos por W. Emory.
1. Revisar la estructura organizacional para analizar la suficiencia, la separación de tareas,
etc.
2. Probar el cumplimiento de la estructura actual frente a la organización definida.
3. Evaluar el desempeño del personal clave.
4. Revisar el programa de entrenamiento.
5. Establecer si los planes de PED están de acuerdo con los planes corporativos.
6. Revisar los planes de PED.
7. Probar el cumplimiento contra el plan.
8. Verificar que la Gerencia y los usuarios participen en la elaboración de los planes.
9. Participar en el proceso del plan para expresar las preocupaciones de auditoria.
10. Revisar y probar procedimientos de análisis de costos.
11. Determinar si las cifras base se aplican uniformemente.
12. Revisar el presupuesto y los procedimientos para su aplicación.
16
13. Verificar si se han desarrollado estándares para todas las áreas de PED.
14. Verificar el cumplimiento de los estándares.
15. Participar en el desarrollo de los estándares.
16. Revisar contratos de hardware y de software.
17. Revisar contratos de servicio.
18. Verificar el cumplimiento de los contratos.
19. Revisar el cubrimiento de los seguros.
20. Revisar los planes para el desarrollo de aplicaciones.
21. Comprobar que existen y se aplican estándares para el diseño de sistemas y compra de
software.
22. Revisar la participación del usuario en el desarrollo de sistemas.
23. Participar en el desarrollo de sistemas.
24. Revisar controles de nuevos sistemas antes de su implantación.
25. Revisar planes para la implantación de nuevos sistemas.
26. Revisar la selección y uso de lenguajes de programación.
27. Participar en la prueba de sistemas.
28. Revisar los resultados de las pruebas antes de la implantación de un nuevo sistema o de
los cambios a un sistema existente.
29. Conducir revisiones de post-implantación.
30. Evaluar los estándares para el mantenimiento del software aplicativo.
31. Revisar y probar los procedimientos de control para verificar que están acordes con los
sistemas en operación.
32. Probar los procedimientos usados para actualizar la documentación.
33. Probar los dispositivos de seguridad física para proteger la documentación.
34. Probar la documentación de respaldo (Back-up).
35. Revisar la seguridad lógica para archivos de datos y programas.
36. Revisar el uso por parte del programador, de librerías privadas o temporales.
37. Verificar el trabajo de mantenimiento contra requerimientos para mantenimiento o
modificaciones.
38. Revisar las normas para la operación del computador y comprobar su cumplimiento.
39. Determinar si el hardware es usado eficientemente.
40. Revisar los reportes administrativos concernientes a la utilización del hardware.
41. Verificar que el equipo es usado solamente para trabajos autorizados.
42. Revisar los planes para adquisición de equipo.
43. Revisar los procedimientos para organización de actividades.
44. Hacer inventarios de equipos de PED.
45. Revisar los procedimientos para el mantenimiento del hardware.
46. Revisar las condiciones ambientales.
47. Revisar los planes y programas de seguridad física.
48. Revisar los controles de acceso físico.
49. Revisar el procedimiento de la protección contra y/o detección de desastres.
50. Revisar los procedimientos para la recuperación en caso de desastre.
51. Probar los procedimientos de recuperación.
52. Revisar la seguridad para medios que contengan archivos de datos o programas.
53. Probar los procedimientos para la toma de copias de respaldo (Back-up).
54. Revisar los procedimientos para la entrada de datos.
55. Revisar los procedimientos para la distribución de información.
56. Revisar los estándares para el diseño de redes de comunicación.
57. Participar en el planeamiento de la red.
58. Revisar la seguridad física para proteger los componentes de la red.
59. Revisar los dispositivos de seguridad lógica para acceder la red.
60. Revisar los controles para modificación del software.
61. Revisar la documentación.
62. Revisar los controles existentes sobre los utilitarios.
63. Revisar y probar los procedimientos para el mantenimiento de las librerías utilizadas en
producción.
64. Determinar la naturaleza y el impacto de servicios recibidos de fuentes externas.
65. Conducir revisiones de auditoria para los servicios recibidos de terceros.
66. Verificar que los usuarios entienden los programas aplicativos.
67. Probar el conocimiento de los usuarios respecto a los dispositivos del control del
sistema.
68. Revisar la documentación del usuario.
69. Evaluar la satisfacción de los usuarios con las diferentes aplicaciones y con el sistema
en
general.
70. Probar los procedimientos para el control del flujo de los datos del usuario.
71. Revisar los procedimientos para la distribución de reportes.
72. Verificar el contenido de los archivos magnéticos.
73. Desarrollar programas de computador para asistir a los auditores financieros.
74. Servir de enlace entre los auditores financieros y el departamento de procesamiento de
datos.
75. Asistir a los auditores financieros en la interpretación y evaluación de los reportes
generales por el PED.
76. Proveer entrenamiento básico a los auditores financieros.
77. Proveer entrenamiento a la gente de PED relacionados con los objetivos de auditoria.
RECOMENDACIÓN
Empiece por dar respuesta a estas preguntas:
¿ Están formalmente definidos los objetivos de Auditoría de Sistemas?
 Están claramente definidas las relaciones entre los auditores de sistemas y los auditores
Financieros?
Si la respuesta es SI, felicitaciones y a cumplir con sus objetivos... pero si la respuesta es
NO entonc es...
18 Elabore su propia lista de objetivos, sométala a revisión de diferentes niveles de su
organización, revise las recomendaciones y presente un plan definitivo a la Gerencia para
obtener su aprobación y respaldo... y no olvide tener en mente los procedimientos para el
logro de cada objetivo.
19 La Auditoría a través del Computador
A diferencia de la auditoria alrededor del computador, estas técnicas permiten al auditor en
la medida en que conozca mas las operaciones en el computador, tener menos limitaciones
para trabajar.
DEFINICION
Esta técnica da un gran énfasis a probar el sistema de computador que produce la salida en
cambio de probar la salida misma.
El auditor prueba y verifica:
- La efectividad de los procedimientos de control sobre las operaciones de computador y en
los programas del computador.
- Que el procesamiento interno sea correcto.
Esta técnica de auditoria requiere dos tareas básicas que son:
- La revisión y verificación de las transacciones fuente.
- La prueba real de la lógica de los programas de computador y de los controles de
programa.
¿CÓMO ES LA AUDITORIA A TRAVES DEL COMPUTADOR?
En la figura 1 se ilustra como es la auditoria a través del computador. Con esto, el auditor
asume que el computador es una herramienta y que cuando se programa apropiadamente,
produce una salida confiable.
20 Por consiguiente las pruebas de auditoria deben pensarse mas como pruebas lógicas de
programación, que como pruebas de exactitud del computador.
Una de las herramientas clave en la aplicación de esta técnica de Auditoria es la
preparación de una serie de transacciones de prueba, normalmente llamadas DATOS DE
PRUEBA.
El lote de prueba se corre en el computador, en un ambiente de pruebas previamente
instalado y utilizando los mismos programas que fueron utilizados para procesar la
aplicación que esta probando.
La prueba se diseña para determinar la efectividad de los controles, exactitud y generalidad
de los programas.
VENTAJAS Y DESVENTAJAS DE LA AUDITORIA A TRAVES DEL
COMPUTADOR
Ventajas
21 1. Ayuda al auditor a involucrarse mas en el sistema; por consiguiente incrementa su
conocimiento y habilidad para realizar auditorias más complejas en el futuro.
2. Trabaja como una ayuda para realizar pruebas de cumplimiento y en la evaluación de
controles programados.
3. Incremento de servicios a los clientes porque los controles y las operaciones son
probadas o, por lo menos, observadas por el auditor.
4. Los resultados de las pruebas son fácilmente identificables y se pueden utilizar como
medidas de la confiabilidad del procesamiento interno.
5. Utiliza el computador como una herramienta para realizar las funciones de auditoria.
Las desventajas de esta técnica son:
1. Requiere tiempo de computador.
2. Requiere conocimientos técnicos de PED y personal de auditoria más hábil.
3. Representa una prueba “sobre lo hecho” (sobre lo conocido) mas que una prueba
preventiva.
4. Representa solo una prueba limitada del sistema.
DATOS DE PRUEBA
Los datos de prueba son transacciones simuladas que incluyen idealmente todo tipo de
condiciones posibles, incluyendo aquellas que el sistema es incapaz de manejar, debido a la
carencia de controles apropiados. Quiere decir esto que la lista de transacciones
simuladasdebería probar condiciones tanto validas como invalidas.
Los datos de prueba deben ser procesados con los programas regulares del sistema.
Propósito de los datos de prueba.
El auditor no puede ver físicamente las operaciones y los controles dentro de la caja negra
(programas de aplicación), pero puede ver un listado de los resultados de la prueba donde
por ejemplo, algunas transacciones que deberían ser rechazadas no lo fueron, o donde
condiciones de overflow causaron errores o donde transacciones fuera de limite fueron
procesadas como si fueran correctas (Ej. .transacciones de clientes que exceden el limite de
crédito). El auditor también puede determinar si la caja negra esta procesando
apropiadamente las transacciones validas.
El uso de los datos de prueba abre ventanas en la caja negra, porque las transacciones
simuladas se procesan en el sistema de computador y generan resultados que son
comparados por el auditor con resultados esperados manualmente con anterioridad. Es decir
antes de ejecutar el lote de prueba, el auditor calcula los resultados que debería obtener y
luego los compara con los obtenidos en la prueba.
22Como preparar los datos de prueba
Generalmente, los datos de prueba se aplican de la siguiente manera:
1. Se debe revisar todo el sistema de controles.
2. Sobre la base de esta revisión se diseñan las transacciones para probar aspectos
seleccionados del sistema o todo el sistema.
3. Los datos de prueba se transcriben a los formatos de entrada al sistema.
4. Los datos se convierten (graban) a medios utilizables por el computador. El auditor debe
verificar la conversión mediante rutinas de balanceo o en listados de validación que se
produzcan. Además debe guardar el medio magnético que contiene la información hasta
cuando realice la prueba.
5. Los datos deben procesarse con los programas de la aplicación que están vigentes. El
auditor debería estar presente durante el proceso de los datos para asegurar que:
a) no se introduzca información adicional,
b) se utilizan los procedimientos de operación estándar,
c) no ocurra alguna irregularidad cuando se efectúa la prueba,
d) Todos los documentos impresos (hardcopy) que se produzcan sean retenidos por el
auditor.
6. Los resultados obtenidos en el punto 5º, se deben comparar con los resultados
predeterminados.
Controles de auditoria sobre los programas de computador que estén siendo probados.
El principal objetivo del uso del lote de prueba es verificar la operación de los programas
de computador de los clientes para ver si operan como se piensa (desea).
El auditor debe asegurarse que el programa que está probando es el mismo que está
actualmente en producción. Esta seguridad se puede obtener mediante la verificación previa
de los procedimientos de Control de Cambios a Programas y de la fecha de actualización
del programa o programas a probar, las cuales deben coincidir con la fecha de los
programas en Producción.
Aplicación de los datos de prueba
El auditor debe tener el diseño de los registros de transacciones para preparar sus
transacciones
de prueba. Este diseño debe contener el nombre de cada campo, el tamaño y su
configuración (numero o alfanumérico). El auditor incluye sus propios datos en los campos
apropiados para producir resultados predeterminados. Si los resultados de las pruebas no
están de acuerdo con los resultados esperados se debe hacer una investigación mas
profunda para determinar la razón para las variaciones.
23Los siguientes son algunos ítems que normalmente deberían ser incluidos en la
aplicación de datos de prueba.
1. Verificar si se producen totales de control y se devuelven a la mesa de control. Por
ejemplo: si se procesan 100 registros de prueba, el total de control debe indicar 100.
2. Tratar de procesar una transacción sensitiva sin la debida autorización y observar si el
sistema la rechaza (por ejemplo cambiar el limite de crédito).
3. Hacer chequeos numéricos, alfabéticos y caracteres especiales.
4. Entrar a un campo con signo negativo y observar si se procesa realmente con este signo.
En algunos sistemas sin controles apropiados, el signo negativo se convierte en positivo.
Hacer comprobaciones de validez. Por ejemplo entrar un código invalido o un
departamento con código equivocado.
5. Hacer pruebas de racionalidad y de limite.
Ejemplo: empleado que trabaja mas de 48 horas por semana; retiro por mas de $50.000 sin
autorización apropiada.
6. Cuando las transacciones deben estar ordenadas por numero de secuencia, ingresar
transacciones en desorden.
7. Incluir un numero de cuenta dígito de chequeo predeterminado y ver si se procesa
normalmente.
8. Uso de diferentes unidades de medida. Ejemplo: pies por libras.
9. Incluir diversos campos con datos incompletos o inexistentes.
10. Insertar caracteres en campos que causen condiciones de overflow
11. Tratar de leer o escribir un archivo equivocado.
Los archivos que se van a probar, deben ser copiados al ambiente de pruebas como archivos
especiales de trabajo con el fin de permitir todo tipo de pruebas.
Ventajas y desventajas de los datos de prueba.
1. No se requiere que el auditor tenga grandes conocimientos técnicos.
2. Tiene buena aplicación donde son pocas las variaciones y combinaciones de
transacciones.
3. Da una evaluación y verificación objetiva de los controles de programa y de otras
operaciones que serian impracticables por otros medios.
4. Los datos de prueba se podrían correr sorpresivamente para descubrir la posible
modificación de programas sin autorización e incrementar la efectividad de otras pruebas
realizadas.
Las desventajas son:
1. Se requiere bastante tiempo y esfuerzo para preparar y mantener un lote de datos de
prueba representativo. Cualquier cambio en programas, diseño de registros y sistema,
implican cambiar los datos de prueba.
24
2. En algunos casos el auditor puede no probar el sistema que realmente esta en producción.
3. En un sistema complejo con gran variedad de transacciones es difícil anticipar todas las
condiciones significativas y las variedades que deberían probarse.
4. El auditor debe estar bastante relacionado con la lógica de programación que está
probando.
5. La prueba en si misma no detecta todos los errores. Cuando los programas son
complejos, pueden existir infinidad de rutas y es muy difícil seguirlas todas.
6. Hay una probabilidad muy alta que el lote no detecte manipulaciones inadecuadas de una
cuenta o cantidad especifica.
Sugerencias para desarrollar Datos de Prueba.
Para archivos maestros:
1. Duplicar registros.
2. Proceso de registros.
3. Cargar e intentar procesar archivos equivocados.
Para registros nuevos:
1. Crear un registro nuevo antes del primer registro existente en el maestro (test de
lowsequence).
2. Crear un registro nuevo después del ultimo registro existente en el maestro (test de
highsequence).
3. Crear tres o cuatro registros nuevos con llaves consecutivas dentro de registros que no
existen.
4. Crear un registro para una división inexistente, un departamento, una planta, un ítem de
inventario, empleado, cliente, y así sucesivamente.
5. Crear dos o más registros de cabecera, uno inmediatamente después del otro.
6. Crear un registro nuevo con llaves ceros.
7. Crear un registro nuevo con llaves nueves.
8. Crear un registro nuevo, pero incompleto. (Por ejemplo: Solo uno o dos campos de diez
posibles)
Para transacciones:
1. Crear transacciones para el primer registro del archivo.
2. Crear transacciones para el ultimo registro del archivo.
3. Crear transacciones para otros registros diferentes al primero y el ultimo del archivo.
4. Crear transacciones para un registro nuevo creado en la misma corrida.
5. Crear transacciones para varios registros consecutivos.
6. Crear varios tipos de transacciones para un mismo registro.
25
7. Intentar crear transacciones para registros inexistentes que fueron menores en secuencia
que el menor registro existente; mayores en secuencia que el ultimo registro existente, y
entre registros existentes, así como para varios registros consecutivos no existentes.
8. Crear transacciones de tal manera que los totales se hagan negativos y verificar el efecto
en otros campos del registro.
9. Crear cantidades demasiado grandes para crear overflow. Examine los resultados.
10. Si se utiliza un registro de encabezado seguido por registros de detalle, cree registros
detallados para el primer registro del archivo, el ultimo registro, dos registros
consecutivos, un registro no existente y varios registros inexistentes.
Para borrar registros e inactivos:
1. Eliminar el primer registro de cada archivo.
2. Eliminar el ultimo registro de cada archivo.
3. Eliminar 3 o 4 registros consecutivos de cada archivo.
4. Intentar acceder un registrar inexistente.
5. Codificar un registro como inactivo e intentar grabar datos al mismo registro en la misma
corrida.
6. Volver activo un registro inactivo y crearle transacciones en la misma corrida.
Para Fechas:
1. Asegurarse que todos los campos de datos de fechas se han actualizado correctamente.
2. Crear fechas con meses 00 y 13, días 0 y 32 y un año invalido.
3. Crear fechas que estén fuera de los intervalos de actualización. Ejemplo: en un periodo
mensual, hacer intervalos de mas de 30 días.
4. Hacer dos corridas de actualización con la misma fecha.
Para pruebas de lógica y proceso:
1. Verificar todos los cálculos que producen promedios o porcentajes con pequeños,
medianos y grandes valores.
2. Crear una condición para todas las rutinas de división con cero como denominador.
3. Crear datos de prueba para valores menores que el mínimo y mayores que el máximo
permitidos.
4. Crear datos para todas las excepciones y errores.
5. Crear datos que incluyan excepciones múltiples y errores en la misma transacción.
6. Crear datos para los valores mínimos y máximos de cada campo.
Para programas de validación. Los datos de prueba para campos alfabéticos incluirán:
1. Campo completamente lleno de letras.
2. Campo completamente en blanco.
26
3. Únicamente números
4. La primera posición alfabética
5. Primera posición en blanco.
6. Mezcla de caracteres numéricos
Datos de prueba para los campos de cantidad o valor incluirán:
1. Campo lleno de nueves.
2. Campo lleno de ceros.
3. Campo lleno de blancos.
4. Exacto el limite inferior, si lo hay.
5. Exacto limite superior, si lo hay.
6. Una cantidad o valor típica entre los limites.
7. Valor superior al limite, si lo hay (diferente de nueves).
8. Valor inferior al limite, si lo hay (diferente de ceros).
9. Valor con signo errado (+ o -).
10. Datos alfabéticos en cada campo.
Para programas de actualización:
1. Diseñar datos para crear varios registros maestros completos.
2. Crear datos para cambiar un registro maestro inexistente.
3. Diseñar datos para crear datos con la misma llave de otro existente.
4. Crear datos con un registro cuya llave sea ceros.
5. Crear datos con un registro cuya llave sea nueves.
6. Crear uno o dos ítem para establecer un registro del archivo maestro nuevo pero
incompleto.
7. Diseñar datos para crear un nuevo registro en el archivo maestro y hacerle cambios
posteriormente en la misma corrida.
Para programas de proceso:
1. Entrar datos que produzcan resultados de cálculos con valores pequeños, medianos y
muy grandes.
2. Entrar datos que creen condiciones de división o multiplicación por cero.
3. Entrar datos que originen desbalanceo del registro de control de lote. Examinar
resultados.
4. Diseñar varias entradas contables ilógicas (ejemplo: Crédito a gastos de depreciación y
debido a cuentas por cobrar)
5. Entrar datos que causen overflow.
27
Para programas de reportes:
1. Incluir datos de prueba con valores negativos para asegurar que se imprimen los signos
para cada campo, en cada línea de detalle y en las líneas de total.
2. Crear datos con nueves en todo el campo para asegurar que se imprimen y que no se
ponen en otros.
3. Entrar datos de prueba con solo ceros para probar la supresión de ceros no significativos
en la impresión.
4. Verificar todas las sumas y resultados de los cálculos.
Enfoques y Técnicas de Auditoría para probar los sistemas de PED
TÉCNICAS DE AUDITORIA ASISTIDAS POR COMPUTADOR
TIPOS DE PRUEBA DE AUDITORIA
- Sustantivas
con el computador
sin el computador
- De cumplimiento
con el computador
sin el computador
ALCANCE DE LAS PRUEBAS DE AUDITORIA
- Comportamiento del sistema ante situaciones normales.
de normal ocurrencia para la operación o negocio
previstas y establecidas para el funcionamiento normal del sistema
- Comportamiento del sistema ante situaciones “fuera de lo normal”.
generalmente no consideradas ni previstas en el diseño del sistema por ser obvias, de
sentido común
exóticas o extremas, como por ejemplo:
Fechas invalidas.
Insuficiencia de tamaño en campos de valor.
Perdida de dígitos en cargue o traslado de acumuladores.
Validez de campos.
28
Valores negativos.
Inconsistencias entre diferentes campos de un mismo archivo.
ENFOQUES PARA APLICAR PRUEBAS DE AUDITORIA
1. HISTORICO / ESTATICO
Tiempo de la prueba posterior al tiempo de los eventos ( tp no pertenece te)
Auditoria a la información sobre hechos cumplidos.
Generalmente se limita a revisar “ lo conocido” (¿por qué ha ocurrido?)
“Auditoria detrás de lo conocido”.
o ¿Se cumplieron los controles establecidos?
o ¿La información sobre las transacciones que ocurrieron durante un periodo de
tiempo se proceso en forma completa, exacta y oportuna?
Técnicas aplicables en sistemas Batch y On-line.
o Datos de prueba.
o Sistemas de evaluación de un caso base.
o Simulación en Paralelo
o Software de auditoria (paquetes o software hecho a la medida):
Selección de transacciones.
Confirmación de saldos.
Registros extendidos.
Examen de archivos.
Reportes de excepción.
ACL, IDEA, SPSS, SAS
- Programas de utilidad (Utilities).
- Otras sin utilizar el computador.
2. ON-LINE / SIMULTANEO / SOBRE LA MARCHA
Tiempo de prueba = tiempo de los eventos (tp = te).
Auditoria en tiempo real, simultanea a los hechos que son objeto de la auditoria.
Permite un enfoque “más dinámico de la auditoria”, porque la oportunidad de las pruebas
y el trabajo de la auditoria se ejecuta sobre información “actual” no “histórica”.
o La información cumple con los controles establecidos para su procesamiento?
o La información refleja un hecho económico, normal y permisible?
La auditoria puede actuar mas oportunamente, anticiparse a los acontecimientos.
29
Técnicas aplicables en sistemas On-line, tiempo real.
o ITF (Facilidad de la prueba integrada o enfoque de la mini compañía o entidad
ficticia).
o Módulos de auditoria encajados en los programas de aplicación (SARF y
SCARF).
o Simulación paralela encajada en la aplicación On-line.
o Segmento de base de datos del auditor.
o En general, requiere el uso de software de auditoria
Paquetes de software de auditoria.
Programas de computador hechos a la medida.
Uso de programas de utilidad (Utilities).
ENFOQUES DE AUDITORIA PARA LOS SISTEMAS DE APLICACIÓN
A. Para sistemas existentes (aplicaciones en producción)
1. Si el auditor no estuvo involucrado en el desarrollo de la aplicación.
- Uso de herramientas y técnicas aplicables “después del evento”. Paquetes, ITF, datos de
prueba, caso base, simulación paralela, etc.
- Uso de manuales, generalmente anticuados, desactualizados.
2. El auditor estuvo involucrado (participo) en el desarrollo de la aplicación.
- Emplea rutinas de auditoría construidas como parte del sistema. Enfoque al momento,
On-line / simultaneo.
- Complementa con técnicas aplicables para después del evento.
B. Para nuevos sistemas
1. Plan de auditabilidad externa al sistema de aplicación.
- Enfoque después del evento.
- También enfoque al momento, simulación paralela no encajada, pero simultanea.-
2. Creación de auditabilidad en el sistema con módulos.
Incorporados y componentes dinámicos.
30
- Sistema de auditoria por computador.
- Módulos incorporados, registros extendidos, ITF, señalización y rastreo (Snapshot y
Tracing), sistemas duales, etc.
31
PROCEDIMIENTOS DE AUDITORIA PARA APLICACIONES EN
FUNCIONAMIENTO
AREAS DE EXPOSICION ALCANCE PUNTOS DE CONTROL (DE
EXPOSICIÓN)
METODOS DE AUDITORIA
1. Generación de transacciones en la
fuente de información.
Preparación manual y el procesamiento
de las transacciones antes de ser entradas
a computador.
1. Registro de datos en los documentos
fuente.
- Revisión de procedimientos
utilizados.
2. Autorización de transacciones. - Observación en las áreas del usuario.
3. Preparación de entradas para el PED. - Rastreo manual de transacciones.
4. Retención de documentos fuente. - Revisión del transporte de
documentos y registros.
5. Manejo de errores. - Revisión de reportes de errores en el
input, preparados por el computador.
6. Las personas: Identificación,