AUDITORIA DE SISTEMAS CON ENFOQUE EN PROCESOS (SUSTANTIVOS Y DE APOYO) RIESGOS Y CONTROLES rea V: Administracin y Sistemas rea v.

2: Sistemas de Informacin y Gestin Tema: 2. Auditora y seguridad: auditora en ambientes computarizados Congreso Nacional de Profesionales de Ciencias Econmicas, Ciudad Autnoma de Buenos Aires, 16 al 18 de junio de 2010 Cdigo de Identificacin: 5.2.2.2 PDF created with pdfFactory Pro trial version www.pdffactory.com

ndice

Procesos. Riesgos y Controles.......................................................................................3 Introduccin Conceptual...........................................................................................3 Los Procesos.........................................................................................................3 Los Procesos y el Auditor de Sistemas..................................................................6 Desarrollo Conceptual...............................................................................................8 Relevamiento y Evaluacin de Cumplimiento......................................................... 12 Sistemas Aplicativos................................................................................................... 16 Introduccin Conceptual......................................................................................... 16 Los Sistemas Aplicativos.................................................................................... 16 Desarrollo Conceptual............................................................................................. 17 Relevamiento y Evaluacin de Cumplimiento......................................................... 19 Relacin Procesos y Sistemas de Aplicacin...................................................... 21 Transacciones............................................................................................................. 22 Introduccin Conceptual......................................................................................... 22 Las transacciones................................................................................................ 22 Desarrollo Conceptual............................................................................................. 24 Anlisis de Riesgos segn la modalidad en el ingreso y segn el tipo de Transacciones y volumen.................................................................................... 26 Relacin Procesos, Sistemas de Aplicacin y Transacciones.............................. 28 Pruebas sustantivas..................................................................................................... 29 Desarrollo Conceptual............................................................................................. 29 Planificacin de las pruebas sustantivas............................................................... 31 Procedimientos de auditora................................................................................ 32 Diseo de Pruebas Sustantivas............................................................................ 33 Pasos para disear Pruebas Sustantivas............................................................... 35 Conclusiones.............................................................................................................. 38

Procesos. Riesgos y Controles Introduccin Conceptual Los Procesos La norma internacional ISO-9001 define al proceso como una actividad que utiliza recursos, y que 1 se gestiona con el fin de permitir que los elementos de entrada se transformen en resultados . En ellos se observan numerosas actividades que en realidad estn interrelacionadas segn una secuencia predeterminada. Estas actividades se realizan de un modo determinado en cada organizacin, es decir con una determinada metodologa. Esa forma de realizarse cada una de esas actividades es lo que se denomina procedimiento en s. Se dice que cuando el mismo se formaliza en algn medio est documentado. Este conjunto de procedimientos es la base de una organizacin para el logro de sus objetivos. Se destaca en esa definicin el concepto de resultado esperado, y en base a ste es que se debern evaluar todos los eventos que pudieran generar (con determinada probabilidad de ocurrencia) desvos con relacin a ese resultado, es decir el objetivo del proceso en s. De este modo, se incorpora el concepto de riesgo subyacente en cada proceso. Se focaliza por lo tanto en esos resultados esperados y en base a ellos deber estimarse y evaluarse el riesgo. Se ha definido el control como el proceso de ejercitar una influencia directiva o restrictiva sobre las 2 actividades de un objeto, organismo o sistema . Cuando se refiere a directiva apunta al modo en que deben realizarse las actividades para que produzcan un resultado deseado, y al mencionar restrictiva refiere al impedimento que esas actividades produzcan resultados no deseados. Asociando los conceptos de procesos (y procedimientos) con riesgos y controles, nos encontramos con que algunas de las actividades que componen un proceso tienen funciones puntualmente de control para mitigar el nivel de riesgo que subyace en alguna parte del proceso y que impedira obtener los resultados esperados o disminuir los beneficios de los mismos (si ocurriera alguno de los eventos que origina dicho riesgo). Este conjunto de procedimientos de control son la base sobre la que descansa una organizacin 3 para el cumplimiento de los objetivos del sistema de control interno , a saber: Eficiencia y Eficacia de las Operaciones Cumplimiento del Marco Normativo (Leyes, Decretos y Normas vigentes y aplicables) Confiabilidad de la Informacin producida por su sistema de informacin. Para finalizar esta introduccin quisiramos mencionar una clasificacin de los procesos por considerar que clarifican el enfoque que intentamos dar a lo largo de todo el escrito.
1 ISO (2000) Norma Internacional ISO 9001 -Sistemas de gestin de la calidad Requisitos- Impreso en la Secretara Central de ISO en Ginebra, Suiza. 2 Cushing, Barry E.:Accounting Information Systems and Business Organizations. 2da edicin. Addison Wesley Publishing Company, 1978. Pg. 1 3 Internal Control Integrated Framework. Committee of Sponsoring Organizations of the threadway Commission.

Los procesos se pueden agrupar del siguiente modo: Aquellos cuyas actividades se relacionan directamente con el core (ncleo) del negocio. Son los que se denominan primarios o sustantivos. El objetivo de estos procesos se vincula de modo

directo con el producto (bien o servicio) que una organizacin provee. El producto del proceso est orientado al cliente externo. Aquellos cuyas actividades proveen apoyo para el cumplimiento de los objetivos de los procesos referidos anteriormente. Las actividades que componen estos procesos apuntan a lograr con mayor eficiencia y eficacia las actividades sustantivas que se realizan para brindar un producto. Son los procesos que suelen denominarse de apoyo o secundarios. Apuntan al cliente interno mayoritariamente. Aquellos que se realizan para dar orientacin a la organizacin -como unidad -en plazos de tiempo prolongados. Definen los aspectos ms generales de una organizacin como la misin, objetivos estratgicos, planes y polticas. Son la base de los dos procesos mencionados anteriormente y les condicionan fuertemente. Son los denominados de gestin aunque preferimos denominarles procesos de orientacin estratgica. Se incluyen en esta clase tambin aquellos que se vinculan directamente con el rea de Sistemas y TI que tienen fines de orientacin estratgicamente obviamente. Ejemplo: El Dr. Leopoldo Caller trabaja en el rea de Recaudacin Tributaria de un organismo. Es especialista en todo lo referido a Administracin Tributaria. Necesita una PC para trabajar. Y con determinados programas instalados. Necesita un acceso a la red corporativa y a un servidor de archivos donde almacena toda la informacin de su gestin. A un servidor de aplicaciones donde estn las aplicaciones que alguien desarrollo para que realice sus actividades. Y que alguien mantiene cuando Leopoldo requiere alguna modificacin por alguna nueva ley o cambio en la normativa aplicable. Esta aplicacin almacena informacin de la cual l es propietario y que no puede perder. Tambin tiene que tener certeza que solo l puede acceder o en todo caso, a quien el designe. Necesita una impresora en su estacin de trabajo para imprimir listados de cuentas corrientes de los contribuyentes o acceso a un servidor de impresin donde podr localizar alguna de las impresoras a las cuales enviar su solicitud de impresin. Necesita una cuenta de correo electrnico. Leopoldo necesita poder realizar sus operaciones de modo eficiente y eficaz. Este proceso primario (Recaudar tributos) necesita del apoyo de otros tipos de procesos: pero son de incumbencia del rea de Sistemas y TI. Algunos de stos de apoyo pero no todos procesos podran ser Administrar los Bienes Informticos: le brinda la PC con todos los componentes, incluyendo lo intangible: licencias de software, Administrar antivirus: le asegura que ningn antivirus este desactualizado y por ende funcione eficazmente ante cualquier ataque malintencionado, Atender requerimientos de Hardware del usuario: le asegura que personal de soporte especializado pueda instalarle y configurarle de modo correcta una impresora, Administrar los usuarios: le asegura que tendr una cuenta de usuario y sern protegidos todos los recursos del cual es propietario este usuario, Existirn mecanismos eficaces para autenticar a este usuario, y por ende asegurarle que no cualquiera puede acceder con su cuenta de usuario y realizar actividades no permitidas.,

 Administrar los resguardos y la recuperacin de la informacin crtica: le aseguraran que ante cualquier evento contingente su informacin podr ser recuperada. En tiempo. Y en forma, Desarrollar y Mantener Aplicaciones. Existen procesos. Pero tambin existen servicios brindados por el rea de Sistemas Informticos. Nosotros adherimos al enfoque propuesto por las normas 4 ISO 20000-1 (Requisitos) e ISO 20000-2 Cdigos de Prctica cuando promueven la adopcin de un enfoque hacia procesos integrados y cuyo fin es prestar eficazmente servicios gestionados a fin de cumplir con los requerimientos de las empresas y de los clientes.
4 Information Technology Service Management Part 1: Specification. Part 2. Code of practice. ISO IEC 20000

Los Procesos y el Auditor de Sistemas El ciclo de Edward Deming Plan, Do, Check, Act aplica en su totalidad para reflejar las actividades que realiza el auditor de sistemas. Es decir: 1) Planificacin de sus actividades basado en un enfoque de procesos con sus respectivos riesgos. El evento disparador ser el acuerdo de realizacin de actividades de auditoria en una fecha pautada para inicio de las actividades. El input para este proceso es el anlisis que el auditor realice de los procesos sustantivos y de apoyo y los riesgos estimados. Adems de por supuesto todo otro conocimiento que obtenga del ente (estructura, sector industrial, tamao, marco normativo aplicable, etc.). En esta instancia se definen los objetivos y el alcance de la auditoria. Y tambin se explicitan los procedimientos que habrn de ser utilizados. El output es un documento donde se comunica a los mximos directivos de la organizacin auditada las actividades que han de ser llevadas a cabo en un plazo de tiempo determinado y acordado previamente. Se incluye el plan detallado de trabajo. 2) Ejecutar las actividades focalizando en los procesos ms crticos para la organizacin auditada, es decir aquellos vitales para el desempeo normal de la operatoria. Algunos de los procedimientos (como se explicar posteriormente) tienen fines de control mientras que otros sern operativos. En esta instancia, se realizan las actividades de relevamiento y evaluacin de cumplimiento de esos procedimientos de control. El objetivo es emitir una opinin sobre cun razonablemente mitigan los riesgos a los cuales est expuesto el proceso. La naturaleza, oportunidad y alcance de sus procedimientos dependern del anlisis de riesgos de los procesos sustantivos que hubiera realizado previamente, y ms puntualmente en aquellas actividades crticas del proceso. El input es el plan de auditoria y los recursos necesarios para cumplir con los objetivos de la auditoria. El output es el conjunto de elementos de prueba vlidos y suficientes que permiten respaldar la opinin del auditor de sistemas. El informe de auditora de sistemas (con las observaciones y recomendaciones) es otro de los outputs y el que se constituye en el producto final principal de todo el proceso de auditoria visto integralmente. 3) Controlar lo planificado vs. Lo realizado. El output del primero de los procesos y el detalle de las actividades realizadas con sus resultados generarn el input para este proceso. El resultado ser un informe de control de auditora con la explicitacin de los desvos, constituyndose en el output. 4) Mejora continua de los propios procesos de auditora y respectivas actividades (procedimientos). El input de este proceso lo constituye todo el anlisis realizado en el proceso anterior y la transformacin consiste en el propio rediseo de actividades que permitan incrementar la efectividad. El output lo constituye el rediseo de los propios procesos de auditora.

Sintetizando y desde una perspectiva integral, el auditor debe abordar el conocimiento y dominio de todos los procesos con las actividades de control incorporadas a los mismos; como as tambin las responsabilidades de quienes intervienen y roles, las acciones o eventos que disparan el inicio de cada proceso como los que lo finalizan, y todas las excepciones que se pudieran observar y debieran por ende considerar. Si puede de ese modo comprender la secuencia de actividades que componen cada proceso, con aquellas actividades que tienen funciones de control, le permitir en primer lugar planificar sus actividades basadas en un enfoque de procesos y riesgos, ejecutar (hacer) de modo correcto sus actividades de auditora a travs de la prueba de los controles y realizar las observaciones y recomendaciones adecuadas y pertinentes. De este modo, se generar un proceso de mejora continua donde el auditor contribuye a travs de sus observaciones y recomendaciones a todo el proceso integral, involucrando a varias reas (tanto del rea de Sistemas Informticos como generales, como se explicar a continuacin) de la organizacin auditada. E incluyendo sus propios procesos. Desarrollo Conceptual A modo de ejemplo de un modo sintetizado y bajo un enfoque tradicional , el auditor de sistemas realiza las siguientes actividades:
5 Se basa en el procedimiento del Auditor reglado en la Resolucin Tcnica Nro. 7 FACPCE (la Federacin Argentina de Consejos Profesionales de Ciencias Econmicas) y Internal Control Integrated Framework. Committee of Sponsoring Organizations of the threadway Commission. 5

I. Conocimiento del Ente (Estructura y Operaciones). Estimacin de Riesgos. Planificacin, definicin de objetivos y alcance de la Auditoria de Sistemas. II. Relevamiento y Evaluacin de todos los Controles Generales del rea de Sistemas y TI. III. Relevamiento y Evaluacin de todos los sistemas Aplicativos implementados en las diversas reas (agrupadas funcionalmente) de la organizacin auditada. Es decir, desde una perspectiva funcional vertical. IV. Evaluaciones Sustantivas de los Datos segn criterios de criticidad y sensibilidad, significacin econmica. V. Control de lo ejecutado. Anlisis de Evidencias. VI. Emisin de Opinin. Informes Preliminares y Especiales finales (incluyendo el descargo del auditado). El enfoque que deseamos dar se realiza desde una perspectiva transversal de las actividades y no ya desde una visin funcional de las actividades que se desarrollan en cada rea de la organizacin auditada (la visin funcional vertical). Como se mencion anteriormente, los procesos se clasifican en: 1) Primarios o Sustantivos 2) De Apoyo o Secundarios 3) De Orientacin Estratgica o de conduccin El auditor inicia sus actividades solicitando y procediendo al anlisis del mapa de procesos de la organizacin y del rea de Sistemas y TI. As tambin el anlisis de la matriz de procesos y reas

(donde podr visualizar rpidamente la participacin de las reas en cada uno de los procesos). Luego, debera estimar el riesgo inherente a cada uno de estos procesos y construir su matriz de riesgos. Una vez realizadas estas actividades, podr proceder a la planificacin de sus actividades de auditoria dado que ya tiene conocimiento de las reas de riesgos mayores en las cuales reforzar sus pruebas. Entonces, retomando el enfoque de auditora por procesos, el auditor de sistemas focalizar su conocimiento inicial del siguiente modo: 1) Procesos Primarios o Sustantivos. Es decir, la revisin objetiva de todos los procesos de negocios que atraviesan distintas reas funcionales y por donde fluye informacin y/o bienes. Todo lo referido a estos procesos del negocio (Por ejemplo el otorgamiento de un prstamo de consumo o de una tarjeta de crdito por parte de una organizacin) que pudieran ser soportados por las tecnologas de informacin y ms concretamente por sistemas de aplicacin deben ser objeto de examen por el auditor de sistemas, dado que algunos de stos procesos tienen reas de riesgos mayores y por lo tanto debern relevarse (localizarse) y evaluarse los niveles de riesgos y los controles implantados dentro los aplicativos que les soportan. En este caso especial el auditor de sistemas deber tomar un conocimiento preliminar (como modo de relevamiento) de los procesos de negocios, de los flujos de informacin entre cada subproceso, quienes son sus propietarios, evaluar la criticidad de los mismos y focalizar su atencin en aquellos con mayores niveles de riesgo. Toda esta informacin podr obtenerse del inventario tecnolgico de la organizacin auditada si lo tuviera y estuviere actualizado. A partir de este conocimiento del proceso de inicio a fin, continuar analizando cuales componentes del sistema debern ser objeto de revisin. Merece la aclaracin que aquellos procedimientos de control que no estuvieran automatizados o soportados por alguna aplicacin pero que integran el sistema de informacin tambin estn alcanzados por las revisiones. 2) Procesos de Apoyo o Secundarios. Nos encontramos con procesos compuestos por todas aquellas actividades que se realizan en el rea de Sistema que poseen cortes de control y que insertos en dichos procesos tambin existen determinadas actividades que tienen funciones de control que han de ser relevadas y evaluadas por el auditor de sistemas. En este caso nos referimos a los procesos del rea de Sistemas y TI. Muchos de estos objetivos de control estn especificados por leyes, resoluciones, normas y decretos y son mandatarios en cuanto su existencia. Como sostiene el Reporte Coso, la existencia de los mismos tiene su razn de ser en el cumplimiento del marco normativo por parte de la organizacin auditada. Estos procesos dan soporte a los procesos primarios y en consecuencia tambin deben ser verificados por el auditor en cuanto la efectividad de los controles insertos en cada parte del 6 proceso integral. Siguiendo el enfoque de Cobit 4.0 , los procesos de TI seran los siguientes: Planear y Organizar Adquirir e Implementar Entregar y Dar Soporte Monitorear y Evaluar

Es importante volver a resaltar que el rea de Sistemas y TI brindan servicios fundamentalmente a las reas para que puedan realizar sus actividades sustantivas y para ello disean sus procesos de modo que sus operaciones se realicen de modo eficiente y eficaz. Y por supuesto aportando sus 7 activos. La norma espaola MAGERIT en Metodologa de Anlisis y Gestin de Riesgos en

Sistemas de Informacin detalla cuales son los activos que componen un sistema informacin y que consideramos importante tener presente. A saber: 1) Datos (Informacin) 2) Los servicios que se pueden prestar gracias a aquellos datos, y los servicios que se necesitan para poder gestionar dichos datos. 3) Las aplicaciones informticas (software) que permiten manejar los datos. 4) Los equipos informticos (hardware) y que permiten hospedar datos, aplicaciones y servicios. 5) Los soportes de informacin que son dispositivos de almacenamiento de datos. 6) El equipamiento auxiliar que complementa el material informtico. 7) Las redes de comunicaciones que permiten intercambiar datos. 8) Las instalaciones que acogen equipos informticos y de comunicaciones. 9) Las personas que explotan u operan todos los elementos anteriormente citados.
6 Cobit 4.0 IT Governance Institute. ISBN 1-933284-37-4 7 MAGERIT Metodologa de Anlisis y Gestin de Riesgos de IT. Ministerio de Administraciones Pblicas.

3) Procesos de Orientacin Estratgica, de conduccin o Gestin: Interesan a los fines de la auditora de sistemas aquellas actividades referidas a la planificacin de los procesos y actividades dentro del rea de Sistemas y TI y la organizacin que se realiza para el cumplimiento de los objetivos definidos. En esta instancia, se relevarn los siguientes objetivos de control: Existencia de Plan Estratgico, con listado de proyectos con un horizonte de planeamiento de 4/5 aos. El mismo debe estar en consonancia con el Plan Estratgico Organizacional. Debe estar actualizado. Debe contemplar el presupuesto. Existencia de un Plan Operativo Anual. El mismo debe estar en consonancia con el Plan Estratgico de Sistemas y TI. Debe contemplar proyectos, responsabilidades, plazos de cumplimiento y revisin, costos. Planificacin y Organizacin de los servicios, procesos y procedimientos del rea de Sistema y su estructuracin (delimitacin precisa de posiciones y funciones, separacin de funciones por oposicin de intereses, contemplar que no se sobre asignen funciones en un mismo puesto). Relevamiento y Evaluacin de Cumplimiento El auditor de sistemas deber por lo tanto relevar tanto los procesos de negocios de la organizacin auditada, es decir los procesos sustantivos, como as tambin todos los procesos existentes en el rea de Sistemas y TI (apoyo y de orientacin estratgica) y respecto los de apoyo

focalizar sus esfuerzos en aquellos considerados crticos. Una vez tomado este conocimiento inicial continuar con el relevamiento de todos aquellos eventos que puedan afectar negativamente el cumplimiento del fin del proceso relevado y luego analizar y evaluar las actividades de control que existan y su nivel de efectividad en ese momento. Segn sea el tratamiento observado realizar sus recomendaciones, siempre teniendo en cuenta que deber evaluar si el nivel de riesgo residual (en caso de existencia de controles implantados) es menor o igual que el que debiera haber sido aceptado como dispuesto a tolerar por los mximos niveles jerrquicos. Se deduce lgicamente que si fuese mayor, debiera el auditor emitir una recomendacin para que se tomen las acciones preventivas o correctivas pertinentes. El auditor inicia sus actividades de relevamiento de informacin utilizando algunas tcnicas que son pertinentes a los fines de esta primera parte de sus procedimientos de auditoria: Encuestas (con cuestionarios cerrados y abiertos). Entrevistas Anlisis de Documentacin de Procesos, incluyendo toda la documentacin asociada a cada uno de los procedimientos involucrados Se incluye la lectura que da marco referencial y normativo a los procesos como por ejemplo, Planes, Polticas y Manuales de Normas y procedimientos, Manual de Misiones y Funciones, Leyes y Decretos aplicables. Uno de los elementos documentales fundamentales es el proceso propiamente dicho documentado, de donde se analizar entre otros aspectos los siguientes: o Narrativa de los procesos, con las actividades que se realizan en cada uno de ellos, focalizando en las actividades de control; como as tambin tomando un conocimiento de quienes son los responsables y los roles que intervienen en cada actividad. Anlisis de las situaciones excepcionales. Esto inicialmente puede ser logrado entrevistando a los niveles gerenciales quienes darn una narrativa con un nivel de detalle general de cada proceso. Y luego bajar en el nivel de detalle. o Diagramas de Flujos de Procesos (curso gramas), donde grficamente puede tener una nocin sobre todos los procesos, las interrelaciones, los puntos de control, los mecanismos de entrada y salida, medios de almacenamiento, operaciones manuales y automatizadas, etc.

Observacin Directa de las actividades. La primera parte de las actividades se centra en la recopilacin de informacin sobre la documentacin de los procesos y el grado de actualizacin de los elementos documentales. Si se encuentra debidamente aprobado por todos los responsables (incluyendo los mximos responsables de la organizacin en cuanto nivel jerrquico) y versionado. Si se encuentra correctamente comunicado. Se focaliza tanto en la forma como en el contenido del documento. El auditor podr realizar las recomendaciones que considere pertinentes segn las buenas prcticas pero debe tenerse en mente que la documentacin puede no reflejar el estado real de las actividades de control, que en

la realidad (que lo verificara en una instancia posterior) se estn realizando correctamente, sean efectivas pero no haya sido actualizada la documentacin. Sintetizando entonces, desde lo general, se debe relevar la existencia de un mapa de todos los procesos y la relacin de cada uno de los procesos con los sectores implicados. Desde lo particular, cada proceso documentado debe contemplar mnimamente los siguientes aspectos: Datos Generales Nombre del Proceso. Objetivos y Alcance del Proceso. Responsable Operativo. Roles en el proceso. Marco Normativo cuyo cumplimiento es mandatario; entre ellos las polticas a las cuales debe estar alineado o en consonancia. Eventos o Acciones Disparadoras (punto de inicio del proceso) Narrativa del Proceso: reas que intervienen con las actividades de control. Secuencia de Actividades e interfaz entre actividades. Acciones o Eventos Finales (punto de finalizacin del proceso) Documentos Relacionados. Por ejemplo la referencia a los procedimientos documentados que aplican en cada una de sus actividades. Estos tendrn un mayor nivel de detalle en cuanto como se realiza cada operacin, documentos y registros que se utilizan, etc. Sistemas de Aplicacin Involucrados. Diagramas de Procesos (curso gramas) con las actividades que tienen finalidad de control. Tomado conocimiento de las actividades de control y recolectado los elementos de pruebas vlidos, pertinentes y suficientes, el auditor contina con la comprobacin que la informacin recopilada con relacin a los controles que intervienen en cada proceso funciona como lo define la documentacin. Estamos entonces en una etapa de pruebas de cumplimiento. Las tcnicas para evaluar cumplimiento que puede utilizar el auditor a su criterio son: Realizando una prueba integral de cada proceso, de inicio a fin. Es aconsejable que se obtenga la autorizacin correspondiente y tomar todas las medidas pertinentes para que la prueba del auditor no afecte la operatoria normal de la organizacin. El auditor verificar el funcionamiento de todos los controles (polticas y procedimientos). Observando cmo se ejecuta un proceso (inspeccin visual) y recopilando evidencias vlidas, pertinentes y suficientes. El auditor tambin puede analizar cmo se ha ejecutado un proceso en el pasado y emitir un juicio sobre el funcionamiento de los controles o puede realizar visitas de modo sorpresivo (lo aconsejable) o con aviso previo en una fecha actual y observar como ejecuta cada actividad el responsable. Entrevistas con todos los responsables para obtener una explicacin de cmo realizan sus actividades y obtener evidencias de formularios y documentos en general que se utilicen en cada actividad del proceso. Independientemente del modo en que evale la efectividad de los controles el auditor se debe asegurar que su intervencin sea influenciada en el menor grado posible por los

responsables o involucrados en el proceso. Es esperable que una persona que sabe que est siendo observada y evaluada realizar sus actividades como cada uno de los procedimientos especifica. A continuacin analizaremos como es el tratamiento de los procesos para con aquellas actividades que son realizadas con ayuda de soluciones tecnolgicas. Sistemas Aplicativos Introduccin Conceptual Los Sistemas Aplicativos Las aplicaciones pueden ser: Sistemas Integrados (de todos los mdulos) y desarrollados por la organizacin auditada. Las interfaces son entre mdulos del mismo sistema. El mantenimiento puede ser realizado internamente o por proveedor externo. Sistemas Integrados (de todos los mdulos) y desarrollados externamente (personal ajeno a la organizacin auditada). Las interfaces son tambin entre mdulos del mismo sistema. El mantenimiento puede ser realizado internamente o por proveedor externo. Varios Sistemas desarrollados con fines determinados, con o sin interrelacin entre s. En el caso de que exista interrelacin cobra relevancia la interfaz entre los mismos (por ejemplo el intercambio de datos a travs de web services). Pueden ser mantenidos internamente o por proveedor externo. Con seguridad administrada desde cada aplicacin o integrada. Sistemas Enlatados o Paquetes, sin customizacin para la organizacin auditada. Puede ser considerado software de terceros por ser la propiedad de los fuentes de una organizacin distinta a la auditada. Aplicativos utilitarios o paquetes ofimticas (para las funciones de sistemas como para los empleados para la realizacin de funciones cotidianas). Una aclaracin y a modo de ejemplo, un procesador de texto lo consideramos un utilitario de ste ltimo tipo y un aplicativo como el toad (administracin de bases de datos) un aplicativo utilizado en el rea de Sistemas. Pueden ser incluidos tambin dentro de la categora software de terceros. Aplicativos que no aportan valor tanto para los procesos primarios, secundarios o de orientacin estratgica y que de hecho hasta pueden atentar contra polticas organizacionales. Por ejemplo, el kazaa o emule utilizados por lo general para descargar archivos ilegales (software propietario y no gratuito) desde internet. Los aplicativos constituyen uno de los aspectos principales que han de ser verificados de modo objetivo y crtico por el auditor de sistemas. Estos pueden soportar cualquiera de los tres tipos de procesos pero se priorizar el anlisis de los sistemas que apoyen los procesos sustantivos, es decir los procesos del negocio. Desarrollo Conceptual Las aplicaciones con los controles existentes en cada uno de los sub mdulos que se relatan a continuacin tienen absoluta relevancia dentro de cada uno de los procesos primarios. Como sostiene el Reporte COSO el funcionamiento de los controles de aplicacin es ms eficaz cuando

descansan o se ejecutan en un entorno de controles generales fuerte y donde los riesgos se encuentran tratados de modo razonable. En nuestro trabajo focalizaremos en la consideracin de aquellos sistemas aplicativos involucrados en los procesos sustantivos. A los fines del anlisis dentro estos sistemas aplicativos existirn distintos subsistemas con sus controles que han de ser relevados y evaluados por el auditor, a saber: Controles en la documentacin de los sistemas Controles en el Ingreso de datos y para la salida de informacin del sistema Controles en interfaces de mdulos del mismo sistema o de distintos sistemas (se incluyen los denominados Web Services para el intercambio de datos y consultas). Controles implantados para la administracin de la seguridad lgica a nivel aplicativo Controles para el procesamiento de los datos Los aplicativos interactan con las bases de datos a la cual realizan peticiones de conexin con el fin de realizar determinadas operaciones con los datos almacenados como una lectura, modificaciones o eliminaciones. Sin embargo el auditor debe tener en cuenta a la hora de sus verificaciones que tambin hay lgica a nivel base de datos. Es muy frecuente que se invoquen determinados procedimientos (los denominados Stored procedures) que ejecutan determinadas operaciones. En otros casos el sistema de administracin de base de datos es quien realiza determinadas operaciones como por ejemplo el registro de actividades por parte de determinados usuarios cuando por medio de un disparador o triggers actualiza una o varias tablas ante la ocurrencia de algn evento (por ejemplo, la modificacin de un dato sensible en una tabla o el alta de un nuevo registro genera el alta en otra tabla que tiene fines de control posterior). Es comn que los denominados logs de auditoria se generen bajo esta modalidad ltima. Dada entonces esta situacin los controles que han de ser verificados ya no son nicamente los que estn implantados a modo de rutinas en el sistema aplicativo sino tambin en la base de datos a modo de procedimientos almacenados y/o de triggers (que tambin son procedimientos complejos). Por lo tanto, tambin debern ser punto de atencin por parte del auditor, y entre otros, los siguientes controles: Controles en Procedimientos Almacenados en Bases de datos Controles implementados a travs de Disparadores para asegurar que cumplen correctamente con su cometido ante la ocurrencia del evento disparador. Controles que aseguren la integridad de los datos (cuando ya no por parte de rutinas en el aplicativo sino por parte del Sistema de Administracin de la base de datos) a nivel entidad, referencial, etc. Relevamiento y Evaluacin de Cumplimiento

Cuando el auditor de sistemas realiz inicialmente el relevamiento de los procesos recab la informacin sobre el catlogo de aplicaciones que estaban involucradas en cada uno de los procesos. En esta segunda instancia de sus actividades inicia la recopilacin de informacin ms detallada de las aplicaciones y los controles que interesa verificar en cuanta efectividad. Para sta ltima actividad facilitara su tarea si existieran en la organizacin auditada curso gramas de donde pueda identificar rpidamente donde se localizan stas actividades de control. Si no existiera un diagrama de ste tipo, deber recurrir a otros elementos documentales que citaremos posteriormente. El auditor de sistemas debiera solicitar mnimamente los siguientes documentos: Manuales del Sistema: Tcnicos, de Administracin, Funcionales y de Usuario. Permitir verificar tanto la documentacin en s como tomar conocimiento de la aplicacin a verificar en cuanto el diseo y funcionamiento de sus controles (ingreso de datos, procesamiento, salida de datos, almacenamiento, etc.) Todo elemento documentado en la etapa de Anlisis, como requerimientos formales, casos de uso, etc.) y de Diseo (diagramas conceptuales, lgicos y fsicos, diagramas de flujo de datos, etc.) que le permita inferir los controles que debieran haber sido diseados e implementados. Todo registro de pruebas realizadas tanto por el rea de Testing de Aplicaciones como del usuario final al momento de aceptacin del desarrollo, mantenimiento o paquete. Informes de Auditoria pasados cuyo alcance sean los aplicativos a revisar: ello permitir tener una nocin de controles que ya hubieran sido revisados y no hubieran sido satisfactorias las pruebas y debieran haber sido mejorados. Entrevistas con usuarios claves y finales. Documentacin donde se reflejen las reglas de negocios. Reportes, reclamos, quejas y sugerencias realizadas y que consten en registros o en algn sistema de incidentes si existiera. Polticas de Seguridad Lgica y toda otra documentacin que permita tomar conocimiento de los controles que deben existir en cuanto la implementacin en la aplicacin de los mecanismos de seguridad. Cualquier otra documentacin que el sentido comn del auditor le dicte como pertinente a los fines de recabar informacin. Una vez realizada la recopilacin de los elementos documentales y el anlisis de todos ellos, el auditor ya estar en condiciones de pasar a la siguiente instancia en su procedimiento: la realizacin de las pruebas de cumplimiento. Existen aplicaciones que permiten la automatizacin de las pruebas pero usualmente el auditor de sistemas realiza la confeccin de sus casos de prueba documentando todos los valores que ha de ingresar reflejando cual es el resultado esperado. En la experiencia de quienes escriben la prueba de aplicaciones desarrolladas en lenguajes estructurados (como cobol por ejemplo) tiene menos complejidad que las aplicaciones desarrolladas en lenguajes orientados a objetos (como Visual Basic 6 o Microsoft .Net).

En todo caso el auditor podr utilizar la tcnica de lote de prueba entonces donde planifica cuidadosamente todos los controles que ha de validar en cuanto su funcionamiento esperado. Otra de las tcnicas usualmente utilizadas es la denominada lagging que se complementa con la de tracing. El denominado tagging consiste en la marca segn determinado criterio (por ejemplo una transaccin con un monto superior a uno predefinido donde se desee validar si funcionan correctamente las polticas de autorizacin) de alguna transaccin que ingresa al sistema. Esta marca lgica le permite al auditor realizar el seguimiento de sta transaccin a lo largo de todo el circuito (tracing) y de ese modo recopilar evidencias vlidas y suficientes sobre el funcionamiento de los controles en cada etapa. Esta tcnica le permite no solo probar los controles en cuanto ingreso, procesamiento y salida sino tambin de las interfaces existentes entre distintos mdulos de un mismo sistema de aplicacin o de distintas aplicaciones (que pueden de hecho estar desarrolladas en lenguajes de programacin diferentes y estar siendo ejecutadas en distintas plataformas). Estas actividades permiten al auditor de sistemas comprender todo el flujo en lo referido a iniciacin, autorizacin, registro, procesamiento y reporte. Lo que es importante resaltar es que el auditor deber realizar sus pruebas en un ambiente controlado por l y donde no exista probabilidad que afecte el normal desenvolvimiento de las operaciones en el ambiente de produccin. Pero para ello deber poder asegurarse que la versin del aplicativo que est probando es igual a la existente en el ambiente de produccin. El auditor entonces realiza las pruebas y va recolectando elementos de prueba que permitan demostrar luego de modo fehaciente el modo en que arrib a sus conclusiones sobre el funcionamiento de los controles. Relacin Procesos y Sistemas de Aplicacin Un proceso determinado est integrado por varias actividades interrelacionadas y secuenciales como se mencion anteriormente. Cada una de estas actividades se realiza de un modo determinado siguiendo un procedimiento que puede ser manual o estar automatizado por medio de algn aplicativo. Alguna de estas actividades mencionadas tendr fines de control y por ende son objeto de auditora. Algunas de estas actividades son claves para el resultado final del proceso y si estas fueran en las que estn apoyadas por los sistemas aplicativos, entonces el nivel de criticidad se incrementa de ese aplicativo/modulo/funcionalidad del aplicativo y por ende el Auditor deber realizar pruebas ms exhaustivas y completas. Este es el enfoque que el auditor ya conociendo los procesos no debe perder al momento de planificar sus actividades de prueba en esta instancia a nivel de la aplicacin. Por lo tanto para el sistema -o el modulo del mismo se definir mayor nivel de riesgo, cuando mayor riesgo exista inherente a esa parte del proceso que soporta. Inclusive la dependencia sobre el correcto funcionamiento del aplicativo es un factor que debe evaluarse en cuanto riesgo y los procedimientos de contingencia para que no se produzcan desvos en cuanto el logro de lo objetivos del proceso ante una falla del sistema.

Reiteramos, el auditor al planificar sus actividades deber analizar donde focalizar sus esfuerzos, basado en un enfoque de riesgos. Transacciones Introduccin Conceptual Las transacciones Desde un punto de vista amplio y general una transaccin puede considerarse como una operacin comercial en la cual se produce algn tipo de intercambio; por ejemplo una transferencia de un monto de dinero por parte de un cliente de una empresa por una deuda que mantiene con la misma, un cambio de una divisa, etc. Bajo esta interpretacin se halla implcito el concepto de voluntad por las partes para realizar ese intercambio y que producido este evento debe registrarse contablemente en el sistema de informacin. Hay por lo tanto una visin desde el lado de cliente (usuario) y otra desde el lado de la organizacin y su sistema de informacin. Desde una ptica exclusivamente de sistemas una transaccin es una unidad de ejecucin de un programa que accede y posiblemente actualiza varias tablas en una base de datos. Esta compuesta por varias operaciones elementales que se ejecutan o todas o ninguna entre un punto 8 de inicio y uno de finalizacin . Se dice que estando la base de datos en un estado de consistencia la misma conserva ese estado si fue ejecutada exitosamente la transaccin. Cada transaccin tiene una funcin especfica del sistema, como se ejemplific anteriormente puede ser el alta de un cliente a la base de datos de una compaa, una transferencia de dinero de una cuenta de un banco X a otra cuenta de otro banco. Normalmente se realizan dos operaciones distintas: la primera que genera una disminucin en un monto determinado en una cuenta del banco X y otra en la que incrementa el saldo de la cuenta en banco y por ese mismo monto. En ste ltimo ejemplo, o bien se realizan ambas operaciones o no se realiza ninguna. Si nos ubicamos en cualquier aplicativo, nos encontraremos que distintos tipos de transacciones pueden componer un mdulo de ese sistema; por ejemplo, cuando en un men se visualizan todas las transacciones para la gestin de un impuesto determinado, por ejemplo el de Ingresos Brutos (alta de contribuyente, modificacin de datos personales, cese de actividades, bajas, consultas, impresiones, etc.). Como por ejemplo las transacciones procesadas por un gestor transaccional como CICS en una plataforma IBM y en las cuales su ejecucin se encuentra facultada a determinados grupos de usuarios a partir de las tablas de seguridad del sistema (para este ejemplo, RACF). Desde la ptica del usuario, estas operaciones conforman una sola tarea (por ejemplo, la acreditacin de una suma de dinero en la cuenta corriente de un cliente por el pago de un tributo). El usuario desconoce todas las actualizaciones que se producen en cada una de las tablas implicadas y que se encuentran idealmente-relacionadas.
8 Fundamentos de Bases de Datos. Abraham Silberschatz. Tercera Edicion. Mc. Graw Hill

Estas transacciones son, por definicin, procesos cortos que generan tiempos de respuestas cortos (dado que se necesita rendimiento elevado) y que realizan muy pocos accesos a pocas tablas ya que si estn compuestas por demasiadas operaciones insumen mucho tiempo y generan demoras cuando principalmente el procesamiento es online. Este tipo de transaccin es usualmente ejecutada por un usuario del sistema de informacin, sin embargo tambin existen otro

tipo de actualizaciones en la base de datos que se produce por disparadores automticos como se mencionaron anteriormente. Existen determinados tipos de riesgos con relacin a la ejecucin de transacciones, por ejemplo con relacin al acceso concurrente para realizar determinadas operaciones. Ante la posibilidad de estos riesgos deben ser implementados determinados tipos de controles de concurrencia. Siguiendo con el ejemplo citado anteriormente, debera poder asegurarse que se realicen las dos operaciones y de ese modo se garantice la consistencia del sistema y que ningn evento que suceda genera que una de las operaciones se haya efectivizado pero no la otra. En estos casos mencionados anteriormente, existen por lo tanto ciertos riesgos que deben ser mitigados con determinados controles. Y que el auditor deber relevar y evaluar en cuanto cumplimiento. Algunos tipos de transacciones son clasificadas usualmente como crticas, por tener alta influencia patrimonial y financiera para la organizacin. Estas debern ser foco de atencin por parte del auditor tanto a travs de la realizacin de pruebas de los controles a nivel aplicacin como a de las pruebas de los datos de esas tablas que actualizan posteriormente (pruebas sustantivas). Desarrollo Conceptual En un sistema existen diversos modos de ingreso de transacciones al sistema, por ejemplo de modo interactivo, donde se produce el evento, el usuario ingresa el dato que refleja dicho evento, el sistema realiza las validaciones correspondientes y en caso de no existir algn tipo de error en el ingreso, se procede al procesamiento y se actualizan las diferentes tablas de la base de datos (tanto previo como posterior al procesamiento). Bajo esta modalidad pueden darse dos casos: El primero es donde el evento sucede, se registra en algn tipo de formulario (documento fuente) y luego ingresan los datos al sistema. El segundo caso se da cuando las transacciones se ingresan al sistema cuando sucede el evento pero no existe un documento que respalde esa transaccin. Otra modalidad de ingreso se produce cuando se agrupan varias transacciones de acuerdo a algn criterio (por ejemplo, el tipo de transaccin, el operador que la gener, una determinada sucursal, la fecha del evento, la fecha de ingreso al sistema, etc.). Cada determinada frecuencia se ingresa todas al sistema, se realizan las validaciones respectivas para el ingreso. Se procesaran en ese mismo momento o se archivarn temporalmente para un procesamiento posterior (de todas en el mismo momento) y donde luego se actualizarn las diversas tablas de la base de datos. Cabe la aclaracin que este concepto de lote de transacciones puede ser fsico o lgico y los resultados del procesamiento se visualizan una vez procesado todo el lote. Lo mencionado anteriormente trae aparejado distintos tipos de riesgos y por lo tanto, sern necesarios distintos tipos de controles que validen lo ingresado y procesado. Es importante no perder el marco de anlisis, donde estas transacciones se corresponden a eventos que suceden en alguna parte del proceso, de hecho hasta pueden ser el evento que dispara el inicio de un proceso o por supuesto ser parte de algunas de las secuencias del mismo.

En los prrafos anteriores se introdujo el concepto de transacciones y lo referido a la operacin de alta (ingreso de datos al sistema). Con relacin al procesamiento de datos (ingresados previamente) existen dos tipos distintos de procesamiento:

 Procesamiento de Transacciones en Lnea (OnLine Transaction Processing OLTP): Para la entrada, procesamiento y recuperacin de transacciones. Procesamiento analtico en lnea (On-Line Analytical Processing OLAP): Para consultas de grandes volmenes de datos. En este escrito apuntaremos a mencionar los controles con relacin al primero de los sistemas de procesamiento que administran las aplicaciones transaccionales y especficamente referidas al ingreso de transacciones en una primera parte y al procesamiento y recuperacin posterior. Otro punto que se hubiera introducido anteriormente y que es importante resaltar refiere a la criticidad de las transacciones, es decir, existen determinadas transacciones que son consideradas crticas y que por lo general son aquellas que impactan de modo significativo en aspectos financieros y patrimoniales, o dicho en otras palabras, son aqullas que ejecutan altas, bajas y/o modificaciones con significacin econmica para la organizacin auditada. En estos casos el nivel de riesgos si se realizaran operaciones no autorizadas es mayor o se ingresan errneamente los datos (o en un momento incorrecto) y tambin en este caso debern existir controles que permitan realizar una supervisin de este tipo de operaciones. Y el auditor deber ser quien verifique su adecuado funcionamiento. Anlisis de Riesgos segn la modalidad en el ingreso y segn el tipo de Transacciones y volumen Cuando se procede al anlisis de cada transaccin deberan tenerse en cuenta diferentes criterios de riesgos aunque el fundamental es el financiero. Es decir, analizar como un ingreso de algn dato monetario errneo, o ingresado por una persona no autorizada con fines de realizar algn tipo de fraude o que no se corresponde con la realidad pueda afectar financiera y/o patrimonialmente a la organizacin. En este caso habr que analizar la posibilidad de ocurrencia de este evento tanto como evento nico en un periodo de tiempo (por ejemplo, en un plazo por ejemplo diario) pueda afectar negativamente la situacin patrimonial o varios eventos de este mismo tipo en ese mismo periodo de tiempo. Puede que una misma transaccin que se realiza indebidamente varias veces en periodo de tiempo determinado termine al cabo de un por ejemplo trimestre generando prdidas financieras considerables. Es decir, es importante la correcta estimacin del riesgo, no solo a travs del anlisis de impacto sino de la probabilidad de ocurrencia del evento que provoque una degradacin en el valor de alguno/s activo/s. Una vez producido el evento el mismo debe registrarse (sea directamente en el sistema o en algn documento fuente que ser el documento que respalde dicho evento y que luego sus datos sern ingresados al sistema de aplicacin). Podrn entonces darse los siguientes eventos: Que el evento se haya producido (ejemplo la venta de un producto) y no se registre. Que el evento se haya producido (por ejemplo la cobranza de un crdito de un cliente) pero los datos que registran tal situacin no son reales, sea por un error en quien los ingresa o por intencionalidad de registrarlos incorrectamente. Que el evento se haya producido, pero esta situacin se registre ms de un vez y por ende los datos tampoco son reales (por ejemplo, el pago de una deuda)

 Que el evento se haya producido y los datos sean ingresados correctamente pero no alcancen a actualizarse todas las tablas por alguna situacin contingente (por ejemplo el dbito en una cuenta corriente de un cliente) Que el evento se haya producido, los datos se ingresen y procesen correctamente. Para todas estas posibilidades de ocurrencia de eventos se deber analizar la probabilidad de ocurrencia de las mismas y el perjuicio econmico que generara para poder de este modo evaluar el nivel de riesgo para cada transaccin. Usualmente se confecciona una matriz donde vuelcan estos datos. En todas estas situaciones mencionadas entonces habr riesgos inherentes al tipo de evento que el auditor deber considerar para planificar sus pruebas en cuanta extensin, naturaleza y oportunidad. Tambin existir el denominado riesgo de control donde el auditor deber evaluar la probabilidad existente que el propio sistema de control interno no detecte alguna de las situaciones mencionadas anteriormente. En base a estos dos conceptos de riesgos, entonces, el auditor deber evaluar cuanto nivel de riesgo se puede permitir tolerar en sus actividades, es decir se incorpora el concepto de riesgo de deteccin. En base a estos tres conceptos el auditor planificar sus pruebas, en cuanto como se dijo recientemente naturaleza, extensin y oportunidad de las pruebas a realizar. Los tres conceptos por lo tanto conforman el riesgo de auditoria. Relacin Procesos, Sistemas de Aplicacin y Transacciones Todo proceso sustantivo involucra a varias reas funcionales que realizan determinadas actividades. Algunas de ellas son crticas en cuanto como influyen en la obtencin del resultado en el tiempo deseado y en la forma esperada por el cliente externo (aunque pudiese tambin ser interno). Los sistemas de aplicacin brindan soporte para realizar de un modo ms eficiente y eficaz algunas de las operaciones. Considerando un nivel de anlisis ms atmico encontramos el concepto de transaccin, considerado como la unidad elemental de ejecucin simple en una aplicacin. Existe una relacin en cuanto la criticidad de la operacin que ha de realizarse por un usuario y la importancia que cobra la transaccin que le permite realizarla. Y que el auditor debe asegurar que funcione de modo efectivo, se actualicen las tablas correspondientes, etc. Este anlisis realizado toma la ptica de transaccin desde el punto de vista del sistema. Sin embargo si tomamos la ptica mas general de la transaccin como el intercambio producido entre un cliente y una organizacin podemos arribar a una visin ms general y completa de todo el ciclo donde no solo se tiene el dato que respalda ese intercambio y visualiza el producto (bien o servicio) sino tambin la incorporacin a la visin del proceso en su totalidad. El auditor de sistemas debe poder tener esa visin amplia del objeto de anlisis para que desde su propio proceso de planificacin se base en un conocimiento completo del objeto de examen y una evaluacin correcta de los riesgos a nivel integral. Y el auditor de sistemas en su propio proceso de ejecucin de las actividades de auditoria pueda abordar las pruebas de un modo correcto y completo. Pruebas sustantivas Desarrollo Conceptual Para finalizar el abordaje se hace necesario introducir el concepto de Pruebas sustantivas y diferenciarlo de lo que en varias ocasiones antes referimos como Pruebas de Cumplimiento.

El Dr. Leopoldo Cansler , en su magnfica obra Auditora en Contextos Computarizados define claramente ambos conceptos. La auditora de cumplimiento abarca la identificacin, relevamiento y evaluacin de la eficacia de controles vigentes diseados por la compaa. En cambio, la auditora sustantiva tiene como objetivo final emitir una opinin sobre la razonabilidad (existencia, integridad, exactitud) de la informacin que manejan los sistemas. Se trata de dos enfoques complementarios que el auditor combina en distintas proporciones segn su criterio profesional, para hacerse de evidencia vlida y en cantidad suficiente que le permita emitir su dictamen. Si bien la auditora de cumplimiento tiene como mbito de actuacin cada uno de los procesos mencionados anteriormente con sus procedimientos de control (computarizados o no) y la sustantiva, los datos en s mismos, ambas se encuentran ntimamente ligadas. Esto se manifiesta a travs de la relacin que existe entre los resultados de las pruebas de cumplimiento y la naturaleza, oportunidad y alcance de las pruebas sustantivas. Es decir que si las pruebas de controles han dado resultados insatisfactorios es lgico pensar que, ya sea para corroborar nuestras sospechas o bien para reducir de alguna manera el riesgo de auditora, encaremos pruebas sustantivas un poco ms exhaustivas que apunten a esos mismos controles en las partes de los procesos sustantivos donde se manifieste ese nivel de riesgo mayor. El objeto de las pruebas sustantivas, esto es, la informacin a ser auditada, puede tomar la forma de partidas que componen la totalidad o una porcin representativa de un saldo contable expuesto en los Estados Financieros de una compaa, o bien cualquier otra informacin que genere un sistema de la compaa, por ejemplo los datos contenidos en las tablas de cuentas corrientes, deudores por ventas, clientes, ordenes de compra, ventas, etc. Merece la aclaracin que no necesariamente nos estamos refiriendo a informacin contable de modo exclusivo. En el primer caso, la auditora de cumplimiento otorga indicios fehacientes de aqullos rubros con mayor probabilidad de contener errores, pudiendo identificarlos y consiguientemente cuantificarlos slo a partir de las pruebas sustantivas. De resultar significativos el auditor proceder a hacer mencin de tales errores en su informe destinado a terceros interesados en los Estados contables de la compaa. O de aquellas tablas donde existiendo operaciones crticas pueden datos de clientes, proveedores, rdenes de compra, etc. Con mayor posibilidad de errores. En el segundo caso, la auditora sustantiva por lo general se encuentra orientada a la evaluacin de la calidad de una base de datos, o bien, como menciona Leopoldo Cansler en su obra, puede tener como objetivo completar la evaluacin de un sistema contra otras fuentes documentales o fsicas que no se encuentran en medios computarizados. Es decir, extraer pistas de situaciones a ser analizadas y probadas con procedimientos no automatizados.
9 Cansler, Leopoldo. Auditora en contextos computarizados Gua Prctica Profesional Ediciones Cooperativas. 2da versin.

En relacin a este ltimo punto se exponen algunos ejemplos de situaciones que pueden llegar a motivar este tipo de pruebas: 1. Obtener evidencia adicional frente a determinada observacin o problema detectado durante la auditora de cumplimiento.

2. Visualizar la subsanacin de errores u omisiones que en determinadas ocasiones se ve obligado a realizar manualmente un usuario administrador debido al mal funcionamiento o inexistencia de controles. 3. Visualizar si existen casos donde las tablas se actualicen por parte de un usuario que accede de modo directo a ellas y no a travs del aplicativo. 4. Necesidad de extender el perodo objeto de la auditora en el caso de Auditoras de cumplimiento, sobre el cual se expide el auditor en relacin a la efectividad de los controles generales y de aplicaciones a determinada fecha. Por todo lo anteriormente expuesto, es importante destacar que la auditora de cumplimiento no suplanta la auditora sustantiva, sin importar cuan eficiente resulten los controles de la compaa. Esto acompaa el texto de la RT 7, la cual no pareciera dar lugar a obviar este tipo de pruebas. El caso especial reside cuando el auditor inicialmente no confa en las actividades de control, asigna riesgo mximo y pasa directamente a la evaluacin sustantiva. Ello resulta bien evidente en situaciones donde del relevamiento resulta la inexistencia de controles y que lgicamente el auditor de sistemas no realizar pruebas de cumplimiento de algo que no existe. Planificacin de las pruebas sustantivas En su obra, Leopoldo Cansler hace referencia a la Planificacin como el procedimiento racional que permite identificar, asignar prioridades para su realizacin y establecer la naturaleza, extensin y oportunidad de las pruebas a realizar. El auditor planificar sus pruebas sustantivas en funcin al: - El objetivo de auditora a cubrir - La significatividad de los saldos contables que son objeto de auditora. - La significatividad de las partidas individuales en relacin con los movimientos y saldos de las cuentas contables. - Los resultados surgidos de la realizacin de las pruebas de cumplimiento, si las hubo. - Posibilidades de emplear el computador para la obtencin de elementos de prueba para las comprobaciones. - El nivel de interdependencia que tienen los objetivos buscados, con los sistemas de informacin relacionados. Puede suceder que los sistemas que inciden en un rubro, provengan de ms de un aplicativo, con lo que aumentan la complejidad. En el caso de una auditora que se expedir sobre la calidad de una base de datos, la planificacin de pruebas sustantivas se orientar en cambio a cubrir aquellos perodos o conceptos que tienen mayor grado de participacin en la conformacin o actualizacin de la base. Procedimientos de auditora Entre las tcnicas a ser aplicadas en pruebas sustantivas se mencionan el uso de criterios de comparacin, confirmacin de la informacin con otras fuentes que manejen datos relacionados o bien con fuentes ajenas al ente auditado (operen o no con l) y/ o recalculo o reproceso de la

misma. En todos los casos el objetivo de es evaluar su razonabilidad, esto es su existencia, 10 integridad y exactitud. En lo que se refiere a recalculo o reproceso el auditor podr recurrir tanto a planillas de clculo, consultas a travs de algn lenguaje procedural como por ejemplo Microsoft SQL, consultas en bases relacionales (Microsoft Access) o Software especfico (IDEA, ACL en sus distintas versiones), segn el grado de complejidad de la prueba y el volumen de registros que necesiten ser analizados.
10 Cansler, Leopoldo. Auditora en contextos computarizados Gua Prctica Profesional Ediciones Cooperativas.

Diseo de Pruebas Sustantivas Consideraciones previas a) Conclusiones obtenidas en las pruebas de cumplimiento sobre los aplicativos relacionados Cualquier rubro de los Estados Contables se compone de saldos que han sido el resultado del procesamiento llevado a cabo por determinados aplicativos, siendo uno de ellos el Sistema Contable. Por lo general saldos como el de Deudores por Venta que acumula los crditos que la entidad tiene a su favor por la venta a sus distintos clientes suele derivar del trabajo conjunto de diversos aplicativos tales como Facturacin, Cobranzas, Cuentas Corrientes e Inventarios. As, las conclusiones que se deriven de las pruebas de cumplimiento sobre tales aplicativos ayudarn al auditor a definir la naturaleza, alcance y oportunidad de las pruebas sustantivas que restarn llevar a cabo sobre ese saldo. b) Relevamiento previo en cuanto a los archivos y tablas requeridos Con el objetivo de disear sus pruebas el auditor precisar conocer los distintos archivos y tablas con las que interacta cada aplicativo. Gran parte de ese conocimiento proviene de la etapa de relevamiento y la etapa posterior de pruebas de cumplimiento sobre aplicativos. De lo contrario, el auditor deber familiarizarse con los distintos archivos y tablas, as como tambin su estructura mediante la lectura de documentacin tcnica y funcional que pueda facilitarle la compaa. c) CAATs (Computer Assisted Audit Techniques and Tools) Bajo este trmino se conoce a todas aquellas tcnicas y herramientas de Auditora llevadas a cabo con la ayuda de un computador. Tal definicin va ms all de los programas de extraccin y anlisis de bases de datos (IDEA, ACL, Microsoft Access, entre otros). Las TAACs pueden ser aplicadas en distintas etapas de una auditora tales como Planificacin; Ejecucin -Supervisin; Anlisis de Riesgos; Anlisis y Evaluacin de Base de Datos; Herramientas Integradas y Programas para propsitos especficos. Conocidas mayormente en la etapa de anlisis y evaluacin de bases de datos sus principales ventajas residen en que: Herramienta orientada a la auditora.

Facilidad de uso mediante interfaz amigable que le permitan al auditor enfocarse en aplicar su experiencia, en vez de estar aprendiendo a cmo utilizar el software.

 Convierta un conjunto de datos almacenados en un medio digital, en informacin que sea analizable. Importar diversos tipos de archivos mediante un sistema de importacin y manejo de especificacin de criterios de importacin. (Archivos en formato plano y archivos con formato propietario) Extraccin de datos desde bases de datos relacionales (Oracle, SQL Server 2000, Informix). Posibilidad de poder realizar trabajos en lnea mediante conexin directa a la Base de Datos del software aplicativo mediante conexiones ODBC. Capacidad de anlisis interactivo, amigable e intuitivo. Manejo de grandes volmenes de datos no importando su complejidad o configuracin in afectar el rendimiento de la base de datos. Capacidad de elaborar diferentes tipos de anlisis estadsticos. Localizar errores e inconsistencias, comparando y analizando los archivos segn los criterios especificados por el usuario. Realizar validaciones iniciales de integridad de los datos entregados al auditor (totales de control, recuento de registros, anlisis de tipo de dato correcto para cada uno de los campos). Funciones de estratificacin, identificacin de variaciones y duplicidad de datos, faltantes en datos. Archivos de registro (Pistas de Auditoria) que reflejen todo el trabajo realizado de desarrollar aplicaciones personalizadas que se puedan Posibilidad ejecutar automticamente (Macros, Scripts, etc.) creando as una metodologa de auditora continua. Capacidad para trabajar simultneamente con varios archivos. Compatibilidad de exportacin con aplicaciones ofimticas, por ejemplo Microsoft Office. Permite manipular fcilmente grandes volmenes de informacin al tiempo que va generando en forma automtica un log de actividades que resulte de utilidad para quien desee hacer un seguimiento de los pasos tenidos en cuenta para llevar adelante cada prueba. Su uso ms generalizado es para la seleccin de muestras, extracciones, ordenamientos, filtros con criterio, entre otros. Pasos para disear Pruebas Sustantivas 1) Listar los procesos sustantivos a ser considerados en el anlisis, identificando claramente aquellas actividades crticas. 2) Detectar los sistemas que tienen ms incidencia en la conformacin del saldo contable a auditar, incluyendo el Sistema de administracin de Bases de datos, de corresponder. O en el caso de informacin no contable, aquellas transacciones del sistema que revisten mayor criticidad en cuanto los resultados del proceso. 3) Si los aplicativos fueron sujetos a pruebas de cumplimiento, permitirn asignar grado de confiabilidad sobre los saldos o informacin no contable influyendo en la naturaleza, extensin y oportunidad de los procedimientos. 4) Identificar las tablas o archivos que sern objeto de tratamiento.

5) Examinar si los archivos entregados cumplen con los requisitos especificados por el auditor en cuanto a diseo de registro, formato, campos de informacin a incluir, contenido de los mismos, grado de apertura, perodo a cubrir. El objetivo es evitar comenzar a trabajar sobre bases que no cruzan con la contabilidad, incompletas o no vigentes a la fecha. Aclarar el tratamiento dado a aquellos valores que si bien se dieron de alta con posterioridad a la fecha de anlisis, deben ser tomados como formando parte del perodo (la fecha de procesamiento difiere de la fecha real de la operacin). 6) Tomar los recaudos necesarios para asegurarse que los datos recibidos son fiel reflejo de las tablas o archivos utilizados por el auditado. Existen distintas pruebas a realizar para cubrir tales propsitos: Chequear la cantidad de registros de la base objeto de auditora con la cantidad informada por la compaa o bien con su peso en bytes. Verificar la coincidencia de la sumatoria de columnas numricas tales como Importe, Saldo con los totales informados por la compaa. Ordenar los registros por fechas para verificar que se incluyen registros generados durante todo el perodo o espectro de operaciones solicitadas. Soporte de almacenamiento de slo lectura. Chequear los totales de la base con los importes informados por las salidas del sistema para esa misma fecha. Identificar posibles casos de registros con datos invlidos o imposibles de leer.

7) Tareas de captura y vuelco de loggings y/o tablas: Traduccin codificacin EBCDIC de IBM a ASCII. su procesamiento en la modalidad cliente-servidor, que resulta la arquitectura ms eficiente y es la generalizadamente aplicada a estos fines. 8) Realizar estratificaciones o subdividir el universo de registros con el objetivo de facilitar el anlisis de la informacin y poder abocarse a probar objetivos especficos. Los ms comunes son, entre otros Discriminar, de corresponder, los registros a ser analizados por modo de procesamiento (en lnea o en lote), ya que la informacin estar sujeta a distintos factores de riesgo. Estratificar por da de la semana, por horario, por tipo de modificacin practicada, por estado, por usuario, por aplicativo, etc. Esto brinda un perfil de la poblacin que puede resultar particularmente til al auditar activos tales como deudores, inventarios, prstamos o para definir una distribucin de las transacciones. Adicionalmente, la informacin puede resumirse por cdigos determinados o por sub-cdigos. Las cantidades pueden 11 compararse tambin con las de aos anteriores, para analizar tendencias
11 Lic. Daniel Vargas Madrid -CAATTs -Computer Assisted Audit Techniques and Tools - http://www.scribd.com/doc/4656571/CAATTs

9) Determinar objetivos de auditora que se persiguen, para poder definir el tipo de pruebas a realizar. a. Existencia: ausencia de informacin errnea, invlida, inconsistente, duplicada. Algunos ejemplos: i. Extraccin segn criterios (Filtros, queries) ii. Identificar datos duplicados, faltantes o errneos iii. Muestreo y contrastacin con documentacin de respaldo b. Integridad: denota que la informacin es completa, que incluye todas las partidas que debera. Algunos ejemplos: i. Identificacin de saltos en la numeracin que identifica documentacin o nmero de partida que se asigna en forma correlativa ii. Totalizaciones y cruce con inventarios. c. Exactitud: hace referencia al correcto clculo de conceptos y codificacin de partidas que se informan en las bases o archivos auditados. Por ejemplo: el agregado de columnas virtuales y recalculo de conceptos mediante el agregado de frmulas d. Valuacin: comprobar que la compaa utiliza el criterio de valuacin determinado por las normas profesionales en la materia en lo que respecta a registracin contable. Algunos ejemplos: i. Realizacin de agings ii. Reclculos y comparacin con saldos contables 10) Establecer y documentar el modo en que se convertirn y procesar el contenido de los archivos analizados por el auditor. Documentar en forma detallada la metodologa utilizada, fuentes consultadas, procedimientos llevados a cabo. Conclusiones A lo largo de este escrito hemos querido abordar las actividades del auditor de sistemas con una visin que debera tener transversal de las actividades que se realizan en las organizaciones. Hemos adherido a la idea que el sistema de control interno es un proceso (como sostiene el Reporte COSO) y que las actividades del auditor deben tambin reflexionarse como un proceso. Uno de los objetivos que nos planteamos inicialmente fue lograr transmitir a aquellos profesionales ajenos a disciplinas de sistemas, como Contadores Pblicos Nacionales o Licenciado en Administracin de empresas, etc.; una nocin de un enfoque (nuevo) sobre lo que es auditora de sistemas. Ha intentado ser nuestro aporte a modo de devolucin de todo lo que han aportado a nuestra disciplina desde nuestros inicios. Dedicado al Dr. Leopoldo Cansler quien merece nuestra mayor admiracin Resumen Ejecutivo

Como sostiene el Committee of Sponsoring Organizations of the Threadway Commission en su publicacin ERM Enterprise Risk Management, La premisa subyacente en la gestin de riesgos corporativos es que las entidades existen con el fin ltimo de generar valor para sus grupos de inters. Esta presentacin tiene como objetivo introducir el concepto de procesos y servicios con los riesgos asociados en las actividades de auditora de sistemas. De este modo apostamos a la aplicacin de procedimientos de auditora sobre organizaciones que tienen una visin transversal de las actividades que se realizan y han dejado atrs la idea de la visin tradicional funcional y vertical. Por este motivo, es que ya el auditor debe en su anlisis inicial poder comprender los procesos sustantivos de la organizacin auditada y teniendo dominio de este mapa, recin en ese momento poder continuar hacia los procesos de apoyo que brinda el rea de Sistemas y TI (Tecnologa de la Informacin) a todas las reas usuarias. La planificacin de sus actividades de auditoria deben necesariamente basarse en un enfoque de procesos y el anlisis de sus riesgos inherentes. La gestin (relevamiento y evaluacin de cumplimiento) con las observaciones y recomendaciones que concluyan su labor al emitir su opinin objetiva e independiente de criterio, pueden aportar mayor valor agregado a las actividades crticas de la organizacin. Gran parte de los procesos sustantivos referidos son hoy da, realizados por medio de soluciones tecnolgicas. Como se explayar posteriormente en el escrito existe una gran interrelacin entre los procesos y los sistemas aplicativos. Pero ya no basta con realizar las pruebas de las aplicaciones aisladamente. En las organizaciones actualmente existen gran cantidad de aplicaciones desarrolladas en diversos lenguajes de programacin que se ejecutan en diversas plataformas y que intercambian datos a travs de distintas modalidades, por ejemplo web services. Estas aplicaciones son utilizadas por varias reas, incluyendo la participacin del cliente externo. El auditor solo puede realizar una labor completa y profesional cuando parte, como se mencion al inicio, de un conocimiento total del objeto de examen, que en nuestra postura se logra cuando obtiene un dominio de todo el mapa de procesos. Las propias actividades de auditoria deben tambin ser analizadas como procesos realizados con el fin de obtener un resultado determinado que aporte valor a la organizacin auditada. Es importante entender que las actividades se interrelacionan estrechamente y tienen ese objetivo final. Queda mucho camino por recorrer an en pos de perfeccionar y lograr modificar la metodologa con que tradicionalmente y bajo nuestra experiencia profesional trabajaba el auditor. Este escrito es nuestro primer aporte para lograr un cambio metodolgico en pos del beneficio de la disciplina. Y en beneficio de las organizaciones que sean auditadas de este modo. Las organizaciones hoy necesitan que todos sus integrantes aporte valor para todos los grupos de inters. Y el auditor de sistemas debe ir en esa misma direccin. Este es nuestro aporte.