Está en la página 1de 2

UNA BREVE HISTORIA DE CMO AUDITAR CONTROLES DE APLICACION En un contexto en el cual las empresas cada vez ms dependen de los

sistemas como medio para alcanzar los objetivos definidos, el auditor interno cada vez ms debe interiorizarse del funcionamiento de dichas aplicaciones... En un contexto en el cual las empresas cada vez ms dependen de los sistemas como medio para alcanzar los objetivos definidos, el auditor interno cada vez ms debe interiorizarse del funcionamiento de dichas aplicaciones, de los riegos que las mismas acarrean as como la forma de monitorear y mitigar dichos riesgos.

Bajo este razonamiento, un aspecto principal a la hora de analizar el control interno dentro de una organizacin es poder diferenciar que es Un control de aplicacin vs. Controles generales del ambiente de computo.
En primer trmino, los Controles de aplicacin son aquellos controles que son aplicables para un determinado proceso de negocio o aplicacin, entre ellos podemos encontrar la edicin de registros, segregacin de funciones, totales de control, logs de transacciones y reportes de errores. El objetivo principal de los controles de aplicacin es asegurar: y y y y y Que el ingreso de los datos es exacto, completo, autorizado y correcto Que los datos son procesos en tiempo oportuno Los datos son almacenados de forma adecuada y completa Que las salidas del sistema son adecuadas y completas Que registros son mantenidos para realizar un seguimiento de las entradas y eventuales salidas del sistema.

En este sentido pueden existir distintos tipos de controles de aplicacin como ser: Controles de Ingreso: Los cuales son utilizados para mantener la integridad de los datos que son ingresados al sistema, Controles de Procesamiento: Estos controles, principalmente automticos proveen una manera automtica de asegurar que el procesamiento de las transacciones es completa, adecuado y autorizado. Controles de salida: Bsicamente estos controles direccionan a que operaciones fueron realizadas con los datos. Y comparando tambin bsicamente las salidas generadas con los ingresos realizados. Controles de integridad: Estos controles permitan verificar la integridad y consistencia de los datos procesados. Logs: Principalmente utilizados como Audit Trail, permiten a la gerencia identificar hechos inusuales para posterior investigar los mismos. Adicionalmente como otra clasificacin podemos estar encontrando los controles preventivos, bsicamente asociados a los controles automticos de una aplicacin. Y los controles detectivos, principalmente asociados a controles de aplicacin y manuales posteriores. Por otro lado tenemos los controles generales del ambiente de cmputo (ITGC). Estos controles aplican a todos los sistemas, controles y datos.

Los ms comunes controles ITGC son: y y y y y y Acceso lgico sobre infraestructura, aplicaciones y datos, Controles sobre el desarrollo y ciclo de vida de los aplicativos, Controles sobre cambios a programas, Controles sobre seguridad fsica en los centros de cmputos, Backup de sistemas y controles de recuperacin de datos, Controles relacionados con operaciones computarizadas.

Un aspecto importante a considerar para el Auditor Interno, es que la confianza que tengamos sobre los Controles de aplicacin estar directamente asociada con la confianza que depositemos en los ITGC. El segundo aspecto a considerar es la complejidad del ambiente de sistemas que tengamos. Un ambiente menos complejos, tendr un menor volumen de transacciones, y no tendremos un gran nmero de controles inherentes o configurables en que la gerencia pueda confiar. Un ambiente ms complejo requerir por parte del Departamento de Auditora Interna, una mayor evaluacin de riesgos, un mayor conocimiento de los procesos y de las aplicaciones que lo soportan. Ejemplo de un enfoque de evaluacin de riesgo En un ejemplo de un mtodo de evaluacin de riesgos de control deberemos considerar los siguientes aspectos:

1. Definir el universo de aplicaciones, bases de datos y tecnologa de soporte que utilizan


los controles de aplicacin,

2. Definir los factores de riesgo asociados con cada aplicacin. Por ejemplo:
Es control clave? El diseo es efectivo? Es un software pre configurado o bien desarrollo propio? La aplicacin soporta ms de un proceso crtica? Cul es la frecuencia de los cambios de la aplicacin? Cul es la complejidad de los cambios? Cul es el impacto financiero? Cul es la efectividad de los ITGC? Todos estos elementos ponderados terminarn dando para cada aplicacin un total que determinar el ranking del nivel de riesgo para cada aplicacin, considerando tanto factores cuantitivos como cualitativos, como por ejemplo: -Controles con Bajo, medio o alto impacto -Por ejemplo 1= Control fuerte a 5= inadecuado control Una vez rankeada todas las aplicaciones, y evaluado los resultados, debemos generar un plan de accin basado en la evaluacin de riesgos enunciada anteriormente, que tienda a mitigar los riesgos asociados con las aplicaciones que tuvieron un mayor score en el ranking.

También podría gustarte