Una prueba de cumplimiento es una prueba que reúne evidencia de auditoría para indicar
si un control funciona efectivamente y logra sus objetivos [37]. El auditor obtiene
evidencia de auditoría mediante pruebas de cumplimiento [38] de:
Existencia, que el control existe
Efectividad, que el control está funcionando con eficiencia
Continuidad, que el control ha estado funcionando durante todo el periodo.
Las pruebas de cumplimiento son aquellas que determinarán la naturaleza, el alcance y oportunidad de los procedimientos de auditoría a aplicar en la información almacenada en el sistema de información. El auditor deberá verificar los siguientes puntos:
La existencia de una estructura organizativa adecuada, mediante inspección de
manuales, perfiles de usuario, entrevistas, entre otras herramientas.
La existencia escrita y correcta actualización de normas y procedimientos.
La continuidad del procesamiento (planes de contingencia, políticas de respaldo).
Los controles del teleprocesamiento (funciones del administrador de red, criptografía).
Los controles en las aplicaciones pueden verificarse a través de medidas de documentación, niveles medios de fallas, calidad de diseño, cantidad de usuarios, complejidad, cantidad de transacciones, modalidades del procesamiento, estabilidad, escalabilidad. Para reflejar estas medidas se podría usar una matriz de riesgo con sus respectivas ponderaciones.
Para llevar a cabo las pruebas de cumplimiento de un sistema puede o no utilizarse una computadora. Las pruebas de cumplimiento, usando una computadora, pueden clasificarse en:
Post-operación.- Si se verifican los controles luego del procesamiento:
o Puede usarse el sistema real con transacciones reales: se comparan resultados
predeterminados con resultados reales
o Puede usarse el sistema real con transacciones simuladas: en este caso se
comparan resultados predeterminados con resultados simulados. La técnica se denomina lote de prueba. Se podrá utilizar el mismo lote para probar todas las
funcionalidades del sistema pero el mismo tendrá que estar actualizado y debe ser pensado de tal forma que represente todas las condiciones de posible ocurrencia
o Puede usarse un sistema simulado construyendo un sistema paralelo al real con
las funcionalidades que se desean probar. La técnica se denomina simulación en paralelo y se comparan resultados de transacciones reales en el sistema real con resultados de transacciones reales en el sistema simulado. Este método permite saber si la información resultante del sistema real fue modificada “por el costado” del sistema pero tiene como desventaja que sólo se pueden realizar pruebas parciales y que requiere la suficiente pericia técnica para construir el sistema simulado.
En la operación.- Aplicación de pruebas concurrentes:
o En el sistema real se ingresan transacciones reales y transacciones simuladas. La
técnica se denomina ITF (integrated test facilities o mini compañía).
o Se generan registros especiales de auditoría dentro de los registros principales del
procesamiento (debiendo estar debidamente identificados).
La técnica sólo es aplicable en organizaciones que cuentan con organismos de supervisión que lo permiten, de otro modo podría ser considerada como fraude.
Requiere baja pericia técnica y le aporta al auditor el factor sorpresa pero puede tener inconvenientes en su implementación o en su control si las transacciones simuladas no son debidamente identificadas
5.1.1. Segregación de Tareas
El auditor debe tomar en cuenta para la prueba de la segregación de tarea, incluir los siguientes aspectos:
o Realizar un análisis de las responsabilidades asignadas a empleados que son
encargados de partes más significativas del procesamiento de información. Así, se determinará si la responsabilidad por la iniciación de las transacciones está apartada de las responsabilidades por la aprobación, procesamiento y registro de ellas. Hay que asegurar que todos los procedimientos realizados para iniciar o ingresar las transacciones para su procesamiento, hayan sido evaluados,
inclusive si hubieren reingresos de transacciones rechazadas.
o Se debe determinar si los usuarios autorizados revisan periódicamente los
informes de excepción de transacciones rechazadas y si realmente se toman medidas apropiadas para resolverlas.
o El auditor observará a los empleados en su entorno de trabajo para establecer si
están cumpliendo con las responsabilidades asignadas.
5.1.2 Controles de Acceso a los Programas
Las pruebas de códigos de identificación, contraseñas y dispositivos de seguridad de los monitores de teleprocesamiento, software de seguridad y software de DBMS probablemente requieran coordinación con un especialista en auditoría de sistemas. Sin embargo, el auditor podrá utilizar uno o más de los siguientes procedimientos:
o Observar cómo los usuarios acceden al sistema, de tal manera que se confirme su
comprensión de los mismos.
o Obtener, revisar y analizar los perfiles de seguridad o tablas de autorización de
seguridad del monitor de teleprocesamiento, software de seguridad o software de DBMS. El propósito de esta prueba es determinar si los usuarios no autorizados y aquellos a quienes se hayan asignado funciones incompatibles, están limitados de forma apropiada en su acceso a las funciones de procesamiento del software de aplicación.
o En el caso de sistemas de DB, se puede obtener una copia del diccionario de
datos para comparar los perfiles de seguridad, contraseñas, identificaciones de usuario y funciones que los usuarios están autorizados a llevar a cabo, para determinar que sean consistentes. El auditor puede intentar conectarse con el sistema e intentar violar intencionalmente (junto con el personal apropiado del cliente) los niveles de seguridad autorizados y tratar de eludir los dispositivos de seguridad de las terminales. Esta prueba tiene como fin la confirmación de la existencia de los controles de acceso, así como de una mejor comprensión de los mismos. Las violaciones deben ser rastreadas hasta los informes de seguridad, si dichos informes se van a utilizar para propósitos de auditoría.
Cuando se terminan de aplicar las pruebas, el auditor debe estar en condición de determinar si el uso del paquete de software de sistemas es el adecuado y si,
conjuntamente con el sistema de identificaciones/contraseñas, restringe eficazmente el acceso no autorizado a las funciones de procesamiento del software de aplicación.
5.1.3 Pruebas para los Controles de Edición y Validación
En el caso de las pruebas de los controles de edición y validación, el auditor deberá incluir los siguientes pasos:
o Comprobar si las rutinas de procesamiento programadas que contienen los
controles de edición y validación funcionan de la manera esperada.
o Determinar que los controles programados que aseguran que las transacciones
rechazadas sean identificadas y mantenidas en archivos en suspenso, funcionen de la forma que se espera y que no puedan ser eludidos.
o Establecer si los empleados autorizados de los departamentos usuarios han
tomado las medidas adecuadas con respecto a las excepciones o errores incluidos en los listados de errores y transacciones rechazadas, generados por el computador.
o Así mismo, si se considera que las funciones y controles programados son
importantes a fines de la evaluación del riesgo o si se estima que son funciones de procesamiento y controles clave, el auditor debe asegurarse de que los controles sobre los programas de aplicación pertinentes también sean adecuados. A menudo, el uso de transacciones de prueba es el método más directo y eficiente para probar funciones de procesamiento y controles programados. El auditor deberá probar cada función de procesamiento y control programado que sea relevante. Se requieren transacciones de prueba para determinar que las rutinas programadas funcionan de la manera esperada. Sólo es necesario probar cada función una vez, a menos que esa característica del programa sea posteriormente cambiada. Una vez que se confirma la validez de las instrucciones programadas, puede confiarse en el computador procese las transacciones uniformemente.
Pueden desarrollarse otros enfoques distintos de la utilización de transacciones de prueba, para determinar que las transacciones sean adecuadamente procesadas por las rutinas programadas. Por ejemplo, una muestra de transacciones puede ser reprocesada manualmente, para confirmar que las funciones de procesamiento trabajaron adecuadamente para dichas transacciones.
Cuando se utiliza este enfoque, deberán diseñarse otras pruebas para asegurarse de que las transacciones no autorizadas efectivamente no sean aceptadas y de que las transacciones rechazadas o parcialmente procesadas sean adecuadamente aisladas, analizadas y corregidas. Estos factores también deberán ser considerados en el diseño de las transacciones de prueba.
En el caso de que se utilicen transacciones de prueba, deben ser diseñadas de forma tal de determinar que los controles clave realmente existen y asegurar que las transacciones son procesadas en la forma prevista. Las rutinas programadas son probadas mediante el intento de ingreso de datos específicamente seleccionados o preparados para confirmar la existencia de las funciones de procesamiento y controles.
Las transacciones válidas son adecuadamente procesadas a través del software de aplicación y las salidas son representaciones exactas de las transacciones procesadas. Las transacciones inválidas son rechazadas e incluidas en archivos de ítems en suspenso para su control, así como también en informes de excepciones que deberán ser analizados posteriormente.
Los criterios de edición y validación y otras funciones de procesamiento y controles importantes, existen realmente y funcionan apropiadamente y los informes de excepción son generados cuando se presentan condiciones de excepción.
El desarrollo de transacciones de prueba lo suficientemente amplias para probar controles y funciones de procesamiento programadas requiere bastante tiempo cuando se utiliza esta técnica por primera vez. Sin embargo, en períodos futuros puede lograrse un significativo ahorro de tiempo si el software de aplicación del cliente no es modificado frecuentemente. Se podrá volver a utilizar el mismo conjunto de transacciones en exámenes posteriores, en tanto los programas o la naturaleza de las transacciones ingresadas a la aplicación no se modifiquen.
Alternativamente, puede tomarse como punto de partida el uso de transacciones auténticas elegidas al azar o datos de prueba desarrollados y utilizados por el cliente durante la etapa de prueba del proceso de desarrollo de programas (si así fuera el caso). Así, el tiempo requerido para el desarrollo de las transacciones de prueba puede reducirse. Sin embargo, aún así el auditor deberá evaluar la corrección e integridad de las transacciones de prueba utilizadas para alcanzar los objetivos de la prueba. La selección al azar de transacciones auténticas no proporciona usualmente un lote de
transacciones de prueba que cubra todas las posibles condiciones de error, dado que una selección previa de dichas transacciones predispone el universo hacia aquellas transacciones que serían aceptadas por el sistema.
Los principales tipos de técnicas de transacciones de prueba son la utilización de datos de prueba o lotes de prueba, instalaciones de prueba integradas (ITF) y pruebas on-line.