U.N.C. F.C.E.

UNIDAD N XI
Integrantes: Bustos, Silvia. Cappellani, Mariana. Fabuel, Jimena. Farias, Daniel. Matilla, Ezequiel. Mauri, Romina. Miranda, Carolina. Porqueres, Patricia Vernica. Stolavai, Natalia.

AUDITORA OPERATIVA Y DE SISTEMAS COMPUTARIZADOS

AUDITORA DE SISTEMAS EN DESARROLLO

INTRODUCCIN Segn establece el COBIT en el punto M 4.2 y siguientes el auditor deber ser independiente del auditado tanto en actitud como en apariencia (real y percibida). Los auditores no debern estar relacionados con la seccin o departamento que est siendo auditado, y en la medida de lo posible, deber tambin ser independiente de la propia empresa. De esta manera, la funcin de auditora deber ser suficientemente independiente del rea auditada para concluir una auditora en forma objetiva. La funcin de auditora deber asegurar el cumplimiento de los cdigos aplicables de tica profesional y estndares de auditora en todo lo que lleve a cabo. El debido cuidado profesional deber observarse en todos los aspectos del trabajo de auditora, incluyendo el respeto de estndares aplicables sobre auditora y tecnologa de informacin. La Gerencia deber asegurar que los auditores responsables de las revisiones de las actividades de la funcin de servicios de informacin de la organizacin, sean tcnicamente competentes y cuentan en forma general con las habilidades y conocimientos necesarios para desempear dichas revisiones en forma efectiva, eficiente y econmica. La Gerencia deber asegurar que el personal asignado a tareas de auditora de sistemas de informacin, mantiene su nivel de competencia tcnica mediante un programa adecuado de educacin profesional continua. LA TAREA DEL AUDITOR EN EL DESARROLLO DE SISTEMAS Existe un interesante debate acerca de cul debe ser el papel del auditor en el desarrollo de nuevos sistemas, es decir, si debe participar o no en su elaboracin. Podemos mencionar dos posturas: en contra estn los que sostienen que el auditor no debe intervenir en la etapa de diseo e implementacin de sistemas porque esto atentara contra un requisito indispensable a la hora de hacer auditora, que es la independencia (y tambin la objetividad) de criterio. La labor del auditor comienza para stos recin cuando el sistema est en operacin normal (Auditora Tradicional). Por otro lado encontramos los que estn a favor de su intervencin, quienes postulan que no necesariamente afecta la independencia de criterio y que adems otro de los requisitos para realizar una auditora, es justamente que el sistema sea auditable, y para esto es necesario que en la etapa de su diseo se hayan incorporado controles, de tal manera que den al

auditor pistas de auditora a la hora de realizar la revisin. Sin duda la insuficiencia o carencia de controles que debieron definirse en esta fase inicial dificulta e imposibilita la labor del auditor. Por ello tampoco parece aceptable sacrificar calidad y confiabilidad de un sistema por una exagerada valoracin de la independencia, pues de todos modos puede subsanarse mediante la intervencin de un auditor distinto en la prueba del sistema de aqul que realiz la funcin de consultora en el diseo del mismo. OBJETIVO DE LA AUDITORA DURANTE DESARROLLO DE SISTEMAS: El objetivo de la participacin del auditor en el diseo de sistemas debiera ser identificar, evaluar y analizar los requerimientos de los usuarios; determinar los riesgos existentes y la exposicin del sistema a los mismos, y finalmente identificar controles a ser incorporados a los sistemas de aplicaciones durante la fase de su desarrollo para justamente minimizar los antedichos riesgos. Tambin es importante que asesore a los miembros del equipo encargados del desarrollo del nuevo sistema sobre la incorporacin de controles en el diseo y mdulos de auditora, que permitan una vez en funcionamiento del sistema la revisin de rutina a travs de las pistas de auditora. LA SELECCIN DE LOS AUDITORES INFORMTICOS Segn Yann Derrien, para poder realizar la labor de auditora es imprescindible contar con un equipo interdisciplinario de profesionales que posean la idoneidad e independencia necesaria para desarrollar eficazmente dicha funcin. La seleccin de un equipo de auditora podra ser realizada por alguno de los siguientes mtodos: Anuncios en la prensa diaria nacional. Anuncios en la prensa de informtica. Recurrir a gabinetes especializados. Participacin en foros. Envo de fichas de la oficina a los departamentos de alumnos de escuelas superiores o universidades y asociaciones de antiguos alumnos. Envo de cartas a alumnos especializados en informtica. Toda organizacin no confa en auditores jvenes, salvo que posean experiencia previa. No es recomendable que el auditor se especialice en un tipo especfico de actividad, sino que debe evolucionar para progresar y as adquirir competencias y fortalecer su experiencia. La evolucin del auditor puede ser: TCNICA: ser asignado a misiones que requieran capacidad tcnica mayor. JERARQUICA: ser responsable de misiones simples, para luego, progresivamente estar a cargo de las ms complejas. EN LA NATURALEZA DEL OBJETIVO: se le asignan a auditores con experiencia las tareas de asesora y asistencia, debido a que las mismas exigen capacidad tcnica elevada y aptitudes comunicativas.

ALCANCE DE LA PARTICIPACIN DEL AUDITOR:1 La participacin de los auditores debe enfocarse en determinados puntos de control que debieran estar insertos en el cuerpo de los sistemas. Estos puntos son los que justamente permiten al auditor lograr adecuar los controles con el cumplimiento de polticas y procedimientos de la organizacin. Cada uno de estos controles debe permitir cumplir con un objetivo especfico de auditora. El auditor tendr en las distintas etapas de desarrollo del nuevo sistema un papel activo de consultora, que contribuya a la calidad y confiabilidad del proyecto de sistema y tambin de anlisis de riesgos de cada fase. Para realizar esta tarea deber contar con documentacin elaborada de cada fase y mantener reuniones peridicas con el equipo del proyecto. Todo esto sin olvidar el principio de economa que debe estar presente en todo control (relacin Costo/Beneficio), para lograr la mayor eficiencia en el uso de los recursos asignados. INTERVENCIN DEL AUDITOR EN LAS DISTINTAS FASES DE DESARROLLO DEL SISTEMA A continuacin se mencionan las distintas etapas en las que debera participar el auditor al desarrollar un sistema. 1. Desarrollo del Plan Maestro: Contiene los elementos para dar estructura a un sistema, los cuales son: Proyecto Prioridad u orden de desarrollo Recursos necesarios El auditor aqu debe verificar: Que exista compatibilidad entre el Plan Maestro y los objetivos corporativos fijados en el Planeamiento Estratgico de la organizacin. Que el Plan Maestro no incluya aplicaciones que produzcan esfuerzos duplicados y costos innecesarios. Que tienda a la integracin de aplicaciones actuales y de propuestas de manera que los recursos sean eficientemente utilizados y evitar as duplicaciones. Que sea flexible, de manera que pueda adaptarse si cambian prioridades. Que los sistemas propuestos sean realmente tiles para los usuarios y que se mantengan las necesidades del negocio que motivaron su desarrollo. Que se hayan contemplado soluciones alternativas antes de decidir el desarrollo del nuevo sistema, como recurrir al servicio de un proveedor o utilizar un prototipo. Que se haya hecho un estudio de justificacin econmica del proyecto, que la gerencia lo haya aprobado y que, adems, est comprometida en su desarrollo. En definitiva que se haya adoptada la decisin adecuada valorando: Necesidades de usuarios. Disposicin de recursos financieros, tcnicos y operativos. Limitaciones de tiempo de desarrollo y oportunidad.

LARDENT, Alberto D., Sistemas de Informacin par la Gestin Empresaria. Procedimientos, Seguridad y Auditoria (2001,Bs. As. Prentice Hall), 363/379 pg.

2. Definicin y anlisis de requerimientos de usuarios: Esta fase tiene por objetivo responder al interrogante: qu necesita el usuario? Es decir, que caractersticas debe incluir el sistema para que sea til a sus objetivos. La realizacin de todo proyecto exige el acuerdo entre informticos y usuarios sobre el contenido de la aplicacin a desarrollar. Este acuerdo se materializar por medio de un documento escrito denominado pliego de condiciones, que incluye el conjunto de especificaciones funcionales del futuro sistema de informacin, incluyendo las peticiones de mantenimiento de programas. Una participacin activa del usuario, es fundamental para evitar construcciones errneas o incompletas de los sistemas. La mala formacin de los mismos causa la aplicacin anrquica del sistema, originando riesgos, desinters o rechazo. El papel del auditor aqu consiste en: Determinar quines son los miembros que intervienen en el proyecto de desarrollo del nuevo sistema y de ellos, a quines los usuarios les han manifestado (con claridad y precisin) sus necesidades. Revisar el diseo conceptual para cerciorarse que cubra con esas necesidades. Verificar que la gerencia aprob el proyecto, presupuesto y recursos asignados. Verificar que se hayan contemplado los requerimientos que aseguren la preservacin del control interno y las evidencias auditables del sistema. Determinar si se debe incorporar una rutina de auditora para fines de revisin, luego de su implementacin. Determinar la efectividad del sistema verificando si los requerimientos de los usuarios contemplan la emisin de informes de gestin. 3. Diseo lgico del sistema: Esta fase tiene por objetivo responder a la pregunta de qu manera se pueden satisfacer esos requerimientos de los usuarios? El diseo tiene dos etapas: Diseo lgico: Es la construccin funcional del sistema. (Especificaciones sobre salidas de informacin, entradas de datos, archivos, base de datos, procedimientos; observables en un diagrama de flujos de datos). Las funciones del auditor aqu consisten en: Observar si los temas de auditora se cubren satisfactoriamente. Asegurarse que el diseo se ajuste a bases establecidas originariamente y a estndares que se apliquen en la empresa. Verificar que se respeten criterios de separacin de funciones. Con respecto a las especificaciones no informticas sobre datos de entrada el auditor verificar que: El diseo de los formularios y su utilizacin garanticen contener los datos adecuados. Los formularios contengan numeracin que facilita el control de su procesamiento. Se hayan definido las condiciones que permiten la aceptacin de la calidad de los datos de entrada, como tambin el tratamiento para los rechazados, condiciones de correccin y reingreso al proceso. Existan adecuadas condiciones de control para el ingreso de datos online.

La salida se presente de manera que cubra necesidades de informacin del usuario sin que ste deba procesar o seleccionar manualmente la informacin que necesita. Con respecto a las especificaciones informticas el rol del auditor es asegurar en cuanto a: a) Controles: Que en cada paso del proceso computarizado se generen totales de control que puedan ser cotejados con otros totales provenientes de clculos obtenidos de manera independiente (controles cruzados). Que el sistema prevea la presencia de evidencias que faciliten la tares de la auditora. Que existan controles que protejan al sistema contra usos no autorizados. b) Entrada de datos: Que los controles de validacin y consistencia sean adecuados y completos. Que los errores detectados en datos que intentan ingresar al proceso sean comunicados al responsable que los ingres, para que los corrija y reingrese. c) Archivos: Que los archivos maestros y de transacciones sean protegidos adecuadamente. d) Salida de informacin: Que la salida responda a necesidades reales del usuario (contenido, forma, oportunidad). Que la entrega de documentacin de salida o en la pantalla sea precedida por controles de validacin y deteccin de errores. Que se tomen medidas de seguridad respecto a informacin calificada como confidencial.

Desarrollo fsico o ingeniera del software: Se refiere a la elaboracin de programas y a la organizacin y carga de archivos. Tambin incluye la conversin de datos del sistema vigente hacia el nuevo.

Las tareas del auditor en esta instancia son entre otras: Asegurar que se efecten pruebas completas de cada uno de los programas. Revisar los flujogramas de cada programa para verificar la coherencia con el diseo general del sistema. Verificar que controles de entrada/salida diseados para cada programa sean los apropiados para cada situacin.

Verificar que los programas que se encuentran en desarrollo estn separados de los que ya se encuentran operativos, para evitar confusiones. Evaluar los rastros de auditora que se programan en el sistema para rastrear informacin clave.

4. Prueba del sistema: Se realiza una vez finalizada las pruebas de cada programa y efectuadas las correcciones. Los programas que integran el sistema deben entrelazarse y formar una secuencia, la que debe probarse mediante datos de prueba. El auditor debe controlar todo el operativo. Sus tareas son: Que el plan de prueba sea completo, es decir, contemple todas las posibilidades. Verificar resultados de procesos cclicos (de cierre de mes, cierre de ejercicio). Intentar accesos indebidos al sistema para verificar como funcionan las condiciones de seguridad.

5. Implantacin: Esta fase solo se realiza si result exitosa la etapa prueba del sistema. Un tema importante a tener en cuenta por al auditor es la conversin de archivos del sistema anterior al nuevo, analizando riesgos, quin tendr a cargo esa tarea, que controles existen para evitar errores, etc. Este es un punto que debe ser de especial cuidado y atencin por el auditor. La migracin a un nuevo sistema puede hacerse en paralelo (permite comparaciones) o en forma directa. Segn el COBIT, en la etapa de adquisicin e implementacin del sistema se deben tener en cuenta los siguientes objetivos de control: 11.13 Estndares para Pruebas de Sistemas La metodologa del ciclo de vida de desarrollo de sistemas de la organizacin debe proporcionar estndares que cubran los requerimientos de pruebas, verificacin, documentacin y retencin para probar el sistema total, como parte de cada proyecto de desarrollo o modificacin de sistemas de informacin. 1.10 Diseo de Pistas de Auditora La metodologa del ciclo de vida de desarrollo de sistemas de la organizacin debe asegurar que existan mecanismos adecuados para pistas de auditora o que dichos mecanismos puedan ser desarrollados para la solucin identificada y seleccionada. Los mecanismos debern proporcionar la capacidad de proteger datos sensitivos (ej. identificacin de usuarios contra divulgacin o mal uso). 6. Post-instalacin: (Mantenimiento) La auditoria de sistemas debe cumplir con sus planes de revisin. Este examen debe ser realizado por auditores distintos a los que actuaron como consultores en el proceso de desarrollo, para mantener el requisito de independencia.

Funciones especficas: Determinar si luego de que el nuevo sistema ha operado durante un lapso prudente, ste cubre satisfactoriamente los requerimientos y objetivos definidos en etapas iniciales del proyecto. Es imprescindible para esto conocer la opinin de los usuarios. Verificar que existan elementos de medicin que permitan identificar los beneficios proyectados en el estudio de factibilidad y analizar resultados de aplicacin del nuevo sistema. Examinar controles y ver si actan conforme al diseo y requerimientos. Utilizar el mdulo de auditoria que debi incorporarse al sistema para probar el comportamiento de operaciones clave.

Riesgos de desarrollo inadecuado: Si el desarrollo fue incompleto o dbil puede crear situaciones de riesgo, por ejemplo que: El resultado final no satisface al usuario. El sistema implementado no acompaa el desarrollo del negocio. El sistema es poco utilizado y desaprovecha la inversin realizada. No existen controles o son dbiles.

AUDITORIA DE SISTEMAS EN FUNCIONAMIENTO.

CONTROLES PROGRAMADOS Son aquellos concebidos durante la etapa de anlisis y concretados, luego, en los programas de aplicacin correspondientes. De la cantidad, calidad y etapa del procesamiento que cubran, depender la exactitud e integridad de la informacin. CONTROLES PARA VALIDAR LA INFORMACIN DE ENTRADA Destinados a detectar los errores contenidos por la informacin que se ingresa a un sistema de computacin. stos pueden establecerse en varias etapas del flujo de la informacin a travs de un sistema: cuando los datos son ledos por una lectora de tarjetas u otro dispositivo, o bien en el momento en el que la informacin es ingresada mediante una terminal inteligente, o bien una terminal de otro tipo en lnea con el computador. La validacin deber realizarse en el momento ms prximo a la entrada de informacin, en algunas ocasiones esto no resulta posible por razones tcnicas. Cuando los datos deben ser convertidos previamente a un soporte legible por el computador, la tendencia es instalar dispositivos de validacin en las mquinas que practican la conversin, en lugar de esperar que el programa de validacin realice esa tarea. Los controles para validar la informacin pueden realizarse en los siguientes niveles: Verificacin de Caracteres: el control de cada carcter es practicado usualmente examinando los caracteres como un grupo o campo. De blancos: debe existir una indicacin sobre cules son los campos que estarn en blanco y se verifica la existencia de una condicin de igualdad, de no ser as hay un error. En principio es deseable reemplazar los blancos por ceros. Como norma general, los campos deberan ser perfograboverificados con ceros, en lugar de ser dejados en blanco.

De signos: se verifica para asegurar que se emplee el signo algebraico adecuado para el tipo de transaccin procesada. De informacin numrica: se verifica para determinar que no contenga blancos dentro del campo y/o bits de zona errneos. Los blancos son reemplazados por ceros. De informacin alfabtica: normalmente no se producir un inconveniente serio si se omite informacin alfabtica, dado que puede agregarse en el registro la leyenda sin descripcin y emitirse un mensaje para la correccin posterior del error. De tratarse de informacin vital para la aplicacin (nombre de un empleado en el control de la liquidacin de una nmina de haberes) debe indicarse inmediatamente la condicin de error. Verificacin de Campos: Controles de Secuencia: se emplean para verificar que la secuencia que siguen los campos es la correcta. Es necesario que exista una clara definicin sobre lo que se entiende por secuencia, la misma puede ser ascendente o descendente. Secuencia puede significar que cada campo no es inferior al previo, que es superior al previo, o que es superior al previo en una unidad. Un problema que puede presentarse en el control de una secuencia, es la capacidad del sistema para continuar el procesamiento despus de la aparicin de un error. Un nmero incorrecto interrumpe la base de comparacin y el impacto de dicha circunstancia depender, fundamentalmente, de la manera que se haya contemplado en las etapas previas de anlisis y programacin. Este tipo de controles combinados con la emisin de formularios con numeracin de imprenta secuencial y unido a un estricto control sobre las existencias y utilizacin de dichos formularios, puede proporcionar un excelente control sobre una serie de aspectos de la parte no computarizada del sistema. De razonabilidad (o racionalidad): consiste en la programacin de un juicio formulado previamente con respecto a la normalidad de cierta informacin. En la prctica puede resultar difcil establecer lmites correctos de razonabilidad, por lo que la mejor solucin a esto es experimentar y realimentar las constantes fijadas en funcin de la experiencia recogida. Ej.: el total de pedido por un cliente se compara con sus pedidos promedio, si el pedido excede tres veces este promedio, se emite un mensaje de excepcin. Consistencia: un control de esta naturaleza establece relaciones que deben existir entre dos o ms campos de un registro. En funcin de ello se determina la coherencia, congruencia o consistencia de la informacin respectiva. Es problema del analista la determinacin de los campos que deberan verificarse en cuanto a su consistencia. En general, una cierta redundancia en este tipo de control no parece desaconsejable. Ej.: en el campo de horas trabajadas no hay informacin por cuanto el obrero estuvo enfermo, de acuerdo con la indicacin del campo respectivo, no es posible que se liquiden horas extras a ese obrero, correspondientes a la quincena en cuestin. De rango: este control se aplica usualmente a un cdigo, a efectos de verificar que est comprendido dentro de un conjunto dado de caracteres o nmeros. Lmites: este control se emplea cuando es factible fijar topes superiores y/o inferiores a los valores, para ser aceptados. Cuando es posible establecer ambos lmites, mximo y mnimo, el control se conoce con el nombre de rango. Este control es usado corrientemente y ofrece adecuada proteccin contra errores significativos, obviamente el grado de proteccin depende de la manera en que haya sido instrumentado el control. Una debilidad del mismo

es que el lmite debe ser suficientemente amplio para poder aceptar toda la informacin vlida posible. Este control no verifica que la informacin sea correcta, nicamente asegura que los valores se mantengan dentro de ciertos lmites. Este tipo de control deber emplearse para asegurar la correccin de informacin de entrada, actualizar y validar la informacin de salida. El empleo del control de lmites se ver afectado por la accin prevista para el caso que la informacin no cumpla con los estndares fijados. Pueden darse dos circunstancias: 1) rechazo de toda informacin invlida; 2) emisin de un mensaje, pero la informacin contina con el tratamiento previsto, teniendo en cuenta que en este caso los lmites deben ser ms estrictos. Ej.: el tiempo de horas extras no podr exceder las 24 hs. semanales o el salario bruto mensual con bonificaciones no podr ser superior en un 15% al salario anual. De existencia de un cdigo: verificar la validez y existencia de un cdigo, para ello se emplean tablas cuyo tamao depender del nmero de cdigos vlidos a ser controlados. En el momento del diseo de las tablas, deber reservarse la memoria suficiente para las futuras expansiones. De completamiento: este tipo de control verifica que no se hayan omitido campos de un registro. De fechas: su finalidad es determinar que la fecha del registro sea aceptable. Adicionalmente debern fijarse lmites para fechas futuras y pasadas. Ej.: la fecha puede consignarse en los registros utilizando dos dgitos para los das, mes y ao (31/12/02).Los controles practicados sobre la fecha verifican que el mes caiga entre 01 y 12, el da entre 01 y 31, y el ao de acuerdo con el ao en curso. Dgitos de control: la tcnica de dgito control es un importante medio para evitar los errores que pueden producirse en la transcripcin o ingreso de los nmeros de identificacin (cdigos) respectivos. Un dgito de verificacin es un dgito redundante que se aade al nmero base como consecuencia de la aplicacin de una frmula matemtica. El dgito puede agregarse como prefijo, sufijo (el ms conocido y empleado) o insertarse dentro de los caracteres que componen el cdigo. Cuando la informacin identificada por su cdigo ingresa al sistema computarizado, el dgito control es separado del nmero bsico, al cual se le aplica la frmula matemtica respectiva. El resultado obtenido es comparado con el dgito de control. En caso de coincidencia se asume la correccin del cdigo ingresado y el procesamiento contina. De existir discrepancia, se ha producido un error y hasta que el mismo no sea salvado no se procesa el registro. El dgito control se emplea para detectar errores accidentales como objetivo primario y subsidiariamente aquellos intencionales, ya fueran fraudulentos o maliciosos. Por todo lo anterior el desarrollo y empleo de frmulas efectivas y eficientes de dgitos de control, contribuir notablemente a reforzar la confiabilidad del sistema de control interno. Verificacin de lotes o batches: Lote o batches: es uno de los mtodos de control ms simple y efectivo sobre la captura de datos, preparacin y proceso de los mismos. El loteo consiste en el agrupamiento de transacciones que tienen algn tipo de relacin entre s. Es de suma importancia para el auditor el conocimiento de los variados controles que pueden ejercerse sobre el lote. Existen dos tipos de lote: lotes fsicos, grupos de transacciones que constituyen una unidad fsica (ej.: documentos), y lotes lgicos, son un conjunto de transacciones reunidas de acuerdo con un principio lgico, ms

que por el hecho de su continuidad fsica (ej.: varios empleados pueden ingresar informacin a un sistema empleando una terminal en-lnea. Cada empleado lleva el control de las transacciones introducidas. El programa de ingreso de informacin agrupa la misma de acuerdo con el nmero de identificacin de cada persona y, una vez transcurrido el lapso establecido prepara totales de control, los que debern ser reconciliados con los totales de control individuales). Diseo de lotes: tener en cuenta el tamao y la naturaleza de los lotes a emplear. Deberan respetarse estos principios: 1) El lote debe ser lo suficientemente pequeo para la ubicacin de los errores si los controles de lote no balancean. 2) El lote debe ser lo adecuadamente grande, de tal forma que constituya una unidad de trabajo razonable-mente dimensionada. 3) El lote debera constituir una unidad lgica, por ejemplo, un conjunto de documentos representativos de un nico tipo de transaccin. Control de lote: su finalidad es asegurar la exactitud y completamiento de su contenido y confirmar que no se hayan perdido durante su movimiento fsico. Para esto es necesario una tarjeta (hoja) de lote y un registro de control de lotes. La tarjeta para un lote fsico generalmente contiene: n de lote, totales de control de lote, informacin comn para las diversas transacciones integrantes del lote, fecha de preparacin del lote, informacin sobre los errores detectados en el lote, firma de los intervinientes en el tratamiento del lote. Para un lote lgico para de la informacin anterior quedar registrada. Controles sobre lotes: 1) Recuento de registros (o de documentos fuente): se practica un conteo de todos los registros comprendidos en un lote, el cual debe coincidir con el recuento que consta en la hoja. La no coincidencia indicar que se ha producido una omisin, adicin o duplicacin de los registros que deben someterse a control. 2) Totales del control: se trata de totales financieros. Todos los campos con informacin de tal naturaleza son acumulados y controlados con los totales del lote. Es una verificacin tpica que se ha practicado siempre sobre la informacin procesada por un sistema electrnico. Excepto que existan errores compensados, la coincidencia es una prueba que el lote es correcto y completo en cuanto a sus campos con montos financieros. 3) Totales de comprobacin: es una acumulacin de dgitos tomados de un campo de identificacin o de control. Este tipo de control se establece nicamente con finalidades de verificacin. Aunque las discrepancias determinadas proporcionan medios rpidos y seguros para localizar la transaccin incorrecta, podra ocurrir que su acumulacin ocasionar una carga adicional e inaceptable para el usuario. Este control debera implantarse solamente en los casos en los que la exactitud de la informacin de entrada se vea comprometida por problemas especiales. CONTROLES SOBRE EL PROCESAMIENTO: Verificaciones cruzadas (cross footing): en el sentido de control denota la suma cruzada o sustraccin de dos o ms campos y el balanceo del resultado a cero contra el resultado original (o previsto). Este es un control efectivo cuando los totales por dbitos, crditos y el saldo de arrastre se mantienen para cada cuenta; los totales de dbitos y crditos pueden cruzarse para verificar que la diferencia es igual al saldo. Este control puede emplearse tambin como base de recmputo o reclculo, mediante la reversin de las sumas y las restas.

Ej.: los totales de control pueden ser calculados para los salarios brutos, deducciones y neto a pagar. Al trmino del procesamiento, el monto neto debera ser igual al monto bruto menos las deducciones, o el monto neto ms las deducciones, resultar igual al monto bruto. Balanceo de los archivos procesados parcialmente: por las caractersticas del disco magntico, nicamente es necesario consultar los registros necesarios para el caso. Desde que los registros inactivos no son tratados, el procedimiento de balanceo debe reposar sobre la premisa bsica que la informacin contenida en ellos es correcta. Esta premisa es verificada a intervalos peridicos, mediante los controles de los saldos que permitan la adopcin de las medidas correctivas necesarias. En el caso que el sistema de computacin no realice este control automticamente, el restante problema de verificacin consiste en la determinacin de si los registros activos son procesados correctamente y que un error producido en un registro puede ser detectado en el trata- miento previsto para el sistema. El medio de localizar errores a travs de esta tcnica, consiste en el establecimiento de los campos de saldos globales en adicin a los campos con el detalle individual. Cada vez que se produce el tratamiento de un registro se procede a un control cruzado antes y despus de su procesamiento, para obtener la seguridad que el registro estaba y permanece balanceado. Un total de todos los saldos de los registros afectados antes es conciliado con las modificaciones y el total de saldos despus. Una vez practicada dicha conciliacin, el total de las modificaciones es grabado en los registros que mantienen saldos de control que, de tal manera, reflejan el total correcto de saldos de todos los registros. Control sobre redondeos: los problemas de redondeo se producen cuando el nivel de precisin requerido en un clculo aritmtico es menor que el grado de precisin con el cual el clculo se realiza efectivamente en la prctica. Existe un algoritmo muy conocido para el tratamiento de este problema. El auditor debera cerciorarse que tal algoritmo haya sido empleado por dos motivos. En primer lugar, podra no ser del conocimiento de un programador sin la experiencia suficiente. En segundo lugar, por cuanto una simple modificacin a tal algoritmo pueda dar lugar a un delito informtico. PROCEDIMIENTOS PARA EL CONTROL DE SALIDA. Anteriormente, la informacin de salida de un procesamiento computarizado se reflejaba en listados impresos en papel o formularios. El avance tecnolgico ha introducido a los mensajes en pantalla como una nueva modalidad de salida. De manera que a los tpicos controles del material impreso deben adicionarse los controles sobre los usuarios que estarn autorizados a acceder a informacin por pantalla, como tambin, bajo qu circunstancias. Algunos de los controles de salida ms habituales son: Custodia de los formularios crticos o negociables: Los formularios en blanco deben estar protegidos contra robos o daos. Debern mantenerse adecuados registros sobre la existencia y uso de los mismos, y cumplirse con planes de recuentos fsicos. Conciliacin entre formularios salidos del inventario y aquellos procesados: Una persona ajena a quien genere la impresin deber conciliar y fundamentar las razones de las diferencias por errores de impresin, mutilaciones, etc. Conciliacin de importes totales contenidos en las salidas: Deben conciliarse los importes totales de salida con los respectivos importes totales de datos de entrada al proceso asociado con esa salida. Al auditor le interesar verificar el procesamiento de transacciones en caso de ausencia de balanceo.

Control de distribucin y verificacin de recepcin: Es necesario diferenciar los informes confidenciales de los generales. El control de distribucin contribuye a mantener la confidencialidad de informacin reservada. Por otra parte, ser necesario cerciorarse de la recepcin correcta. Tiempo de retencin de informes: Se debern determinar los tiempos fijados desde el punto de vista legal y desde la normativa interna de la empresa. Informacin de salida para correccin de errores: Normalmente los programas prevn mtodos de deteccin de errores, lo cual no implica que los procesos se interrumpan por esa circunstancia. En estos casos, los errores se imprimen en un listado o bien se muestran por pantalla, pero lo importante es verificar que los mismos queden registrados en almacenamiento transitorio hasta tanto se verifique su correccin y reingreso al proceso. El auditor revisar el procesamiento que utiliza el usuario para corregir y retornar los datos al proceso. PARTICIPACIN DEL PROFESIONAL EN LA ELABORACIN DE NORMAS INTERNAS, DESARROLLO Y MANTENIMIENTO DE LOS SISTEMAS. MEDICIN DEL DESEMPEO En toda empresa, cualquiera sea su naturaleza o tamao, siempre hay una necesidad de medir los esfuerzos y realizaciones hechas. El resultado de planear, organizar y dirigir puede ser medido. El establecimiento de metas, medidas o normas, el planear cmo alcanzarlos y luego poner en marcha el plan constituye una buena forma, prctica y organizada, de progresar. La tarea posterior consiste en comprobar lo bien que se ha hecho todo eso, precisar hasta dnde se alcanzaron las metas y establecer claramente los diferentes medios para inspeccionar la obra. Cmo medir el desempeo? Para el auditor, cuya funcin consiste en evaluar, las normas constituyen un instrumento de importancia. El hecho de la evaluacin implica realizar mediciones. Al llevar a cabo su estudio, el auditor no slo deber familiarizarse bien con las normas de desempeo, sino que debe estar alerta a todo factor o factores adicionales que incluyan el determinar si las normas son atinadas, revisadas con frecuencia y modificadas para acomodarlas a las situaciones cambiantes, as como debidamente encauzadas, entendidas y aceptadas por los departamentos y personas involucradas. Cul es la unidad de medida, el estndar o la norma con la cual voy a medir o comparar el sistema de informacin? Este suele ser otro problema que surge a los auditores de sistemas de informacin, al no existir un patrn nico aplicable. En trminos generales podemos mencionar: Normas internas del ente: Algunas organizaciones de cierta envergadura suelen generar su propio conjunto de normas de funcionamiento materializadas en manuales de procedimientos, cursogramas, flujogramas, organigramas, documentacin de sistemas, etc. lo que resulta ms difcil es que estas normas reflejen el impacto que la informtica a causado en sus sistemas, e incluyan pautas especficas sobre el tema. An en los casos en los que existan, deben mantenerse actualizadas por la velocidad de los cambios en este tipo de sistemas (actualizaciones en el equipamiento, en los sistemas operativos, en las aplicaciones y en las comunicaciones) Normas de organismos de control: Algunos organismos de control ya han emitido normas especficas referidas a Tecnologa de la Informacin (TI) ejemplos de ellos en nuestro medio son: el Banco Central de la Repblica

Argentina con su Comunicacin A 2659, la Sindicatura General de la Nacin con las Pautas de Control Interno para Sistemas Computadorizados y Tecnologa de Informacin, el gobierno de la Provincia de Mendoza con sus Normas de Seguridad de Sistemas de Informacin y a travs de la adopcin de COBIT, etc. En algunos casos es necesario complementarlas con otras pautas o normas referidas a los otros componentes de un sistema de informacin distintos de la TI. Estndares emitidos por organizaciones especializadas: Organizaciones internacionales de profesionales han emitido normas aplicables a este tipo de auditoras, entre las ms relevantes se pueden mencionar: Informe C.O.S.O. 5(Committee of Sponsoring Organizations) elaborado por la Treadway Commission, (EEUU 1.992) referido a pautas de control interno en general; C.O.B.I.T Objetivos de control para la informacin y la tecnologa relacionada desarrollado por la I.S.A.C.A. Asociacin de Auditora y Control de Sistemas de Informacin. Ambos estndares se complementan abarcando prcticamente todos los aspectos relevantes de un S.I. Criterio del Auditor: es el menos recomendable y en general el ms utilizado, la principal crtica que se le puede hacer como sensor es la falta de objetividad, ya que es la opinin del auditor sobre lo que debera ser, y por lo general suele ser muy discutida, salvo casos de observaciones muy evidentes, o una muy buena fundamentacin del criterio utilizado. HERRAMIENTAS Y TCNICAS PARA LA AUDITORA INFORMTICA:2 CUESTIONARIOS: Las auditoras informticas se materializan recabando informacin y documentacin de todo tipo. Los informes finales de los auditores dependen de sus capacidades para analizar las situaciones de debilidad o fortaleza de los diferentes entornos. El trabajo de campo del auditor consiste en lograr toda la informacin necesaria para la emisin de un juicio global objetivo, siempre amparado en hechos demostrables, llamados tambin evidencias. Para esto, suele ser lo habitual comenzar solicitando la cumplimentacin de cuestionarios preimpresos que se envan a las personas concretas que el auditor cree adecuadas, sin que sea obligatorio que dichas personas sean las responsables oficiales de las diversas reas a auditar. Estos cuestionarios no pueden ni deben ser repetidos para instalaciones distintas, sino diferentes y muy especficos para cada situacin, y muy cuidados en su fondo y su forma. Sobre esta base, se estudia y analiza la documentacin recibida, de modo que tal anlisis determine a su vez la informacin que deber elaborar el propio auditor. El cruzamiento de ambos tipos de informacin es una de las bases fundamentales de la auditora. Cabe aclarar, que esta primera fase puede omitirse cuando los auditores hayan adquirido por otro medios la informacin que aquellos preimpresos hubieran proporcionado.

ACHA ITURMENDI, J. Jos, Auditora informtica en la empresa (1994, Madrid, Paraninfo), 67/73 pg.

ENTREVISTAS: El auditor comienza a continuacin las relaciones personales con el auditado. Lo hace de tres formas: Mediante la peticin de documentacin concreta sobre alguna materia de su responsabilidad. Mediante entrevistas en las que no se sigue un plan predeterminado ni un mtodo estricto de sometimiento a un cuestionario. Por medio de entrevistas en las que el auditor sigue un mtodo preestablecido de antemano y busca unas finalidades concretas. La entrevista es una de las actividades personales ms importante del auditor; en ellas, ste recoge ms informacin, y mejor matizada, que la proporcionada por medios propios puramente tcnicos o por las respuestas escritas a cuestionarios. Aparte de algunas cuestiones menos importantes, la entrevista entre auditor y auditado se basa fundamentalmente en el concepto de interrogatorio; es lo que hace un auditor, interroga y se interroga a s mismo. El auditor informtico experto entrevista al auditado siguiendo un cuidadoso sistema previamente establecido, consistente en que bajo la forma de una conversacin correcta y lo menos tensa posible, el auditado conteste sencillamente y con pulcritud a una serie de preguntas variadas, tambin simples. Sin embargo, esta sencillez es solo aparente. Tras ella debe existir una preparacin muy elaborada y sistematizada, y que es diferente para cada caso particular. Su objeto es conocer la opinin que tienen los usuarios sobre los servicios proporcionados, as como la difusin de las aplicaciones de la computadora y de los sistemas en operacin. Las entrevistas se debern hacer, en caso de ser posible, a todos los usuarios o bien en forma aleatoria a algunos de los usuarios, tanto de los ms importantes como de los de menor importancia, en cuanto al uso del equipo. CHECKLIST: El auditor profesional y experto es aqul que reelabora muchas veces sus cuestionarios en funcin de los escenarios auditados. Tiene claro lo que necesita saber, y por qu. Sus cuestionarios son vitales para el trabajo de anlisis, cruzamiento y sntesis posterior, lo cual no quiere decir que haya de someter al auditado a unas preguntas estereotipadas que no conducen a nada. Muy por el contrario, el auditor conversar y har preguntas normales, que en realidad servirn para la cumplimentacin sistemtica de sus Cuestionarios, de sus Checklists. Hay opiniones que descalifican el uso de las Checklists, ya que consideran que leerle una pila de preguntas recitadas de memoria o ledas en voz alta descalifica al auditor informtico. Pero esto no es usar Checklists, es una evidente falta de profesionalismo. El profesionalismo pasa por un procesamiento interno de informacin a fin de obtener respuestas coherentes que permitan una correcta descripcin de puntos dbiles y fuertes. El profesionalismo pasa por poseer preguntas muy estudiadas que han de formularse flexiblemente. El conjunto de estas preguntas recibe el nombre de Checklist. Salvo excepciones, las Checklists deben ser contestadas oralmente, ya que superan en riqueza y generalizacin a cualquier otra forma. El auditor deber aplicar la Checklist de modo que el auditado responda clara y escuetamente. Se deber interrumpir lo menos posible a ste, y solamente en los casos en que

las respuestas se aparten sustancialmente de la pregunta. En algunas ocasiones, se har necesario invitar a aqul a que exponga con mayor amplitud un tema concreto, y en cualquier caso, se deber evitar absolutamente la presin sobre el mismo. Algunas de las preguntas de las Checklists utilizadas para cada sector, deben ser repetidas. En efecto, bajo apariencia distinta, el auditor formular preguntas equivalentes a las mismas o a distintas personas, en las mismas fechas, o en fechas diferentes. De este modo, se podrn descubrir con mayor facilidad los puntos contradictorios; el auditor deber analizar los matices de las respuestas y reelaborar preguntas complementarias cuando hayan existido contradicciones, hasta conseguir la homogeneidad. El entrevistado no debe percibir un excesivo formalismo en las preguntas. El auditor, por su parte, tomar las notas imprescindibles en presencia del auditado, y nunca escribir cruces ni marcar cuestionarios en su presencia. Los cuestionarios o Checklists responden fundamentalmente a dos tipos de filosofa de calificacin o evaluacin: Checklist de rango: Contiene preguntas que el auditor debe puntuar dentro de un rango preestablecido (por ejemplo, de 1 a 5, siendo 1 la respuesta ms negativa y el 5 el valor ms positivo). Ejemplo de Checklist de rango: Se supone que se est realizando una auditora sobre la seguridad fsica de una instalacin y, dentro de ella, se analiza el control de los accesos de personas y cosas al Centro de Clculo. Podran formularse las preguntas que figuran a continuacin, en donde las respuestas tienen los siguientes significados: 1: Muy deficiente. 2: Deficiente. 3: Mejorable. 4: Aceptable. 5: Correcto. Se figuran posibles respuestas de los auditados. Las preguntas deben sucederse sin que parezcan clasificadas previamente. Basta con que el auditor lleve un pequeo guin. La cumplimentacin de la Checklist no debe realizarse en presencia del auditado. -Existe personal especfico de vigilancia externa al edificio? -No, solamente un guarda por la noche que atiende adems otra instalacin adyacente. <Puntuacin: 1> -Para la vigilancia interna del edificio, Hay al menos un vigilante por turno en los aledaos del Centro de Clculo? -Si, pero sube a las otras 4 plantas cuando se le necesita. <Puntuacin: 2> -Hay salida de emergencia adems de la habilitada para la entrada y salida de mquinas? -Si, pero existen cajas apiladas en dicha puerta. Algunas veces las quitan. <Puntuacin: 2> -El personal de Comunicaciones, Puede entrar directamente en la Sala de Computadoras? -No, solo tiene tarjeta el Jefe de Comunicaciones. No se la da a su gente mas que por causa muy justificada, y avisando casi siempre al Jefe de Explotacin. <Puntuacin: 4> El resultado sera el promedio de las puntuaciones: (1 + 2 + 2 + 4) /4 = 2,25 Deficiente.

Checklist Binaria: Es la constituida por preguntas con respuesta nica y excluyente: Si o No. Aritmticamente, equivalen a 1(uno) o 0(cero), respectivamente. Ejemplo de Checklist Binaria: Se supone que se est realizando una Revisin de los mtodos de pruebas de programas en el mbito de Desarrollo de Proyectos. -Existe Normativa de que el usuario final compruebe los resultados finales de los programas? <Puntuacin: 1> -Conoce el personal de Desarrollo la existencia de la anterior normativa? <Puntuacin: 1> -Se aplica dicha norma en todos los casos? <Puntuacin: 0> -Existe una norma por la cual las pruebas han de realizarse con juegos de ensayo o copia de Bases de Datos reales? <Puntuacin: 0> Las Checklists de rango son adecuadas si el equipo auditor no es muy grande y mantiene criterios uniformes y equivalentes en las valoraciones. Permiten una mayor precisin en la evaluacin que en la checklist binaria. Sin embargo, la bondad del mtodo depende excesivamente de la formacin y competencia del equipo auditor. Las Checklists Binarias siguen una elaboracin inicial mucho ms ardua y compleja. Deben ser de gran precisin, como corresponde a la suma precisin de la respuesta. Una vez construidas, tienen la ventaja de exigir menos uniformidad del equipo auditor y el inconveniente genrico del <si o no> frente a la mayor riqueza del intervalo. No existen Checklists estndar para todas y cada una de las instalaciones informticas a auditar. Cada una de ellas posee peculiaridades que hacen necesarios los retoques de adaptacin correspondientes en las preguntas a realizar.

CONCLUSION
La Auditora de Sistema en Desarrollo compromete la condicin bsica para el ejercicio de la auditora, que es justamente la independencia de criterio del auditor con respecto al sistema objeto de examen. Existen muchos que estn a favor de la intervencin del auditor en el desarrollo del sistema. Entendemos que esto es posible, siempre y cuando se mantenga dicha condicin bsica.

BIBLIOGRAFA
LARDENT, Alberto D., Sistemas de Informacin par la Gestin Empresaria. Procedimientos, Seguridad y Auditoria, Prentice Hall. DERRIEN, Yann, Tcnicas de la Auditoria Informtica (1995, Colombia, Alfaomega Marcombo). ACHA ITURMENDI, J. Jos, Auditora informtica en la empresa (1994, Madrid, Paraninfo).