Técnicas de la
auditoría
Amigo lector:
La obra que usted tiene en sus manos posee un gran valor. En ella, su autor, ha vertido conocimientos, experiencia y mucho trabajo. El editor ha procurado una presentación digna de su contenido y está poniendo todo su empeño y recursos para que sea ampliamente difundida, a través de su red de comercia- lización.
Usted puede obtener fotocopias de las páginas del libro para su uso personal. Pero desconfíe y rehúse cualquier ejemplar "pirata" o fotocopia ilegal del mismo porque, de lo contrario, contribuiría al lucro de quienes, consciente o inconscientemen- te, se aprovechan ilegítimamente del esfuerzo del autor y del editor.
La reprografía indiscriminada y la piratería editorial, no solamente son prácticas ilegales, sino que atenían contra la creatividad y contra la difusión de la cultura.
PROMUEVA LA CREATIVIDAD RESPETE EL DERECHO DE A UTOR
marcombo
BOIXAREU EDITORESESTRATEGIA Y GESTIÓN
COMPETITIVA
Técnicas de la
auditoría
informática
Yann Derrien
Título de la obra original
Les techniques de l'Audit informatique Copyright by Dunod, París
Traducción de
José Ribamar Rodrigues Silva Coordinación de la colección Juan Luis Segurado Llorente
© Reservados todos los derechos de publicación, reproducción, préstamo, alquiler o cualquier otra forma de cesión del uso de este ejemplar de la presente edición en español por MARCOMBO, S.A. 1994
Gran Via de les Corts Catalanes, 594 08007 Barcelona (España)
Quedan rigurosamente prohibidas, sin la autorización escrita de los titulares del «Copyright», bajo las sanciones establecidas en las leyes, la reproducción total o parcial de esta obra por cualquier medio o procedimiento, com- prendidos la reprografía y el tratamiento informático, y la distribución de ejemplares de ella mediante alquiler o préstamo públicos, así como la exportación e importación de esos ejemplares para su distribución en venta, fuera del ámbito de la Unión Europea.
ISBN: 978-84-267-0960-8
ISBN: 2-10-001154-5, Dunod, París, edición original Depósito Legal: B-12.670-94
Impreso en España Printed in Spain
Composición, compaginación y fotolitos: ApG - Entenza, 218 - 08029 Barcelona Impresión: Gersa, Industria Gráfica, Tambor del Bruc, 6,08970 Sant Joan Despf
Índice general
Advertencia ... 1
PRIMERA PARTE. OBJETIVOS Y MÉTODOS DE LA AUDITORÍA INFORMÁTICA Capítulo 1. Los objetivos de la auditoría informática ... 5
1.1 El estudio de fiabilidad del entorno informático... 7
1.2 El estudio de la eficacia y de las actuaciones de la actividad informática ... 11
1.3 Estudio de fiabilidad de una aplicación informatizada ... 12
1.3.1 Los objetivos de la auditoría... 12
1.3.2 Los demandantes de una auditoría de aplicación informatizada ... 15
1.3.3 Las dificultades de la auditoría de una aplicación informatizada ... 16
1.3.4 Los métodos de auditoría de una aplicación informatizada... 17
1.3.5.Los principales grupos de aplicaciones ... 25
1.4 Utilización del instrumento informático en el marco de una misión de auditoría ... 25
SEGUNDA PARTE. AUDITORÍA DE LA ACTIVIDAD INFORMÁTICA Capítulo 2. La organización general del servicio informático... 29
2.1 La estructura del servicio informático ... 29
2.2 La planificación de la actividad informática... 35
2.3 El seguimiento de costes... 36
2.4 Las prácticas contables y financieras ... 38
2.5 Las relaciones con los servicios de usuarios... 39
2.6 La separación de funciones... 40
2.7 El control de la actividad ... 41
2.8 El entorno social ... 42
2.9 Las relaciones con los proveedores... 45
Capítulo 3. Los procedimientos de desarrollo y de mantenimiento del software ... 50
3.1 La metodología de desarrollo de las aplicaciones ... 50
3.2 La calidad del software... 59
3.3 La documentación... 61
3.4 El mantenimiento... 62
3.5 Los procedimientos de puesta en explotación del software... 62
Capítulo 4. El entorno de producción ... 63
4.1 Los procedimientos de puesta en explotación ... 63
4.2 Los procedimientos de toma de datos... 66
4.3 La ejecución de los procesos en tiempo diferido... 68
4.4 El control de supervisión del entorno de producción ... 71
4.5 El control de la calidad de la producción informática ... 71
4.6 La gestión del espacio en disco ... 73
4.7 La gestión de las bibliotecas de programas ... 73
4.8 La gestión de las copias de seguridad... 74
4.9 Los procedimientos de recuperación en emplazamientos externos (back-up)... 80
4.10 La seguridad física... 81
4.11 Los seguros ... 83
4.12 Las obligaciones legales de declaración ... 84
Capítulo 5. Las funciones de asistencia técnica ... 90
5.1 Las bases de datos ... 90
5.2 La gestión de redes ... 92 5.3 La microinformática ... 95 5.4 Los métodos... 101 5.5 El infocentro ... 102 5.6 La función sistema... 103 5.7 La función seguridad ... 104
Capítulo 6. La protección y la confidencialidad de los datos ... 106
6.1 El acceso no autorizado a los datos que se encuentran en el emplazamiento central... 106
6.1.1 Medidas de prevención por la identificación del individuo recurrente... 107
6.1.1.1 El modo de identificación del individuo recurrente... 107
6.1.1.2 Las técnicas de software de protección... 109
6.1.2 Las medidas de prevención de acceso por identificación del terminal recurrente ... 115
6.1.3 Las medidas de prevención de acceso a las formas de datos y su soporte de almacenamiento... 116
6.2 El robo o la copia de ficheros o software que se encuentran en un soporte de papel o magnético ... 117
TERCERA PARTE. EL CONTROL DE LAS APLICACIONES INFORMATIZADAS
Capítulo 7. La contabilidad general, analítica y auxiliar... 124
7.1 Presentación general de la aplicación ... 124
7.1.1 Los principales ficheros ... 124
7.1.2 Los procesos... 126
7.2 La auditoría de la aplicación ... 130
7.2.1 La auditoría de las posibilidades funcionales... 130
7.2.2 La auditoría de la utilización de la aplicación ... 137
Capítulo 8. El ciclo de las ventas ... 139
8.1 Presentación general de la aplicación ... 139
8.1.1 Los principales ficheros... 139
8.1.2 Los procesos... 141
8.2 La auditoría de la aplicación ... 141
8.2.1 La adecuación de las prestaciones a las necesidades de los usuarios ... 141
8.2.2 La separación de funciones ... 142
8.2.3 Los medios del control jerárquico ... 142
8.2.4 El seguimiento del riesgo-cliente ... 143
8.2.5 El seguimiento de la cifra de negocios y de los márgenes ... 143
8.2.6 El registro de los pagos de clientes ... 144
8.2.7 La exhaustividad de las facturas y abonos emitidos ... 144
8.2.8 La separación de los ejercicios contables... 145
8.3 La utilización de los programas de auditoría ... 146
Capítulo 9. El ciclo de las compras ... 149
9.1 Presentación general de la aplicación ... 149
9.1.1 Los ficheros principales ... 149
9.1.2 Los procesos... 151
9.2 La auditoría de la aplicación ... 153
9.2.1 La adecuación de las prestaciones a las necesidades de los usuarios ... 153
9.2.2 La separación de funciones ... 153
9.2.3 Los controles jerárquicos ... 153
9.2.4 La separación de los ejercicios contables... 154
9.2.5 El registro y el pago de las facturas de proveedores ... 154
Capítulo 10. La gestión de existencias ... 156
10.1 Presentación general de la aplicación ... 156
10.1.1 Los principales ficheros... 156
10.1.2 Los procesos ... 157
10.2 La auditoría de la reaplicación ... 158
10.2.1 La valoración de las existencias ... 158
10.2.2 El inventario físico ... 160
10.2.3 La introducción de las regularizaciones de existencias ... 161
10.2.4 La gestión de reaprovisionamientos ... 162
10.2.5 Las ediciones periódicas ... 162
10.3 La utilización de los programas de auditoría ... 163
Capítulo 11. La nómina y la gestión del personal ... 165
11.1 Presentación de la aplicación... 165
11.1.1 Los ficheros principales ... 165
11.1.2 Los principales procesos ... 166
11.2 La auditoría de la aplicación... 169
11.3 La utilización del software de auditoría... 173
Capítulo 12. La gestión de las inmovilizaciones ... 175
12.1 Descripción de la aplicación... 175
12.1.1 Los ficheros principales ... 175
12.1.2 Los procesos principales ... 176
12.1.3 Los listados principales... 176
12.2 La auditoría de la aplicación... 177
12.3 La utilización del software de auditoría ... 179
CUARTA PARTE. LA GESTIÓN DE LA AUDITORÍA INFORMÁTICA Capítulo 13. Presentación general de la gestión ... 183
13.1 Los participantes... 183
13.1.1 El auditor de cuentas ... 183
13.1.2 El auditor externo contratado... 186
13.1.3 El auditor interno ... 187
13.1.4 El controlador fiscal ... 187
13.2 El plan plurianual de auditoría informática ... 187
13.3 El programa anual de trabajo... 189
13.4 Las herramientas del auditor informático... 190
13.4.1 Los métodos de análisis de riesgos informáticos ... 191
13.4.2 El software de auditoría ... 192
Capítulo 14. La dirección de la misión de auditoría ... 195
14.1 La preparación de la misión... 195
14.1.1 La propuesta de intervención ... 196
14.1.2 El programa de trabajo... 199
14.2 Los métodos de investigación... 199
14.2.1 La gestión general de la evaluación del control interno... 199
14.2.2 La evaluación del control interno de la función informática .... 200
14.2.3 La auditoría de la aplicación ... 202
14.3 La valoración del volumen de intervención... 204
14.4 La presentación de las conclusiones ... 206
Capítulo 15. La utilización de los programas informáticos de auditoría.... 208
15.1 Los objetivos del desarrollo de un software de auditoría ... 208
15.1.1 Desarrollo de un software de auditoría en el marco de una misión de auditoría de una aplicación informatizada... 209
15.1.2 La asistencia a la revisión contable... 210
15.2 La elección de un software de auditoría ... 211
15.3 Las principales fases de la intervención ... 215
15.4 La planificación de la intervención ... 218
Capítulo 16. El auditor informático: perfil, contratación y perspectivas de evolución ... 219
16.1 Perfil del auditor informático y naturaleza de la misión... 219
16.2 La constitución del equipo de auditoría informática ... 221
16.3 La selección de los auditores informáticos... 224
16.4 El control de los equipos ... 224
16.5 Perspectivas de evolución de los auditores informáticos... 226
Bibliografía... 229
Advertencia
La auditoría informática no se parece en nada a la cocina. Esta obra no tiene por vocación ser un libro de recetas. Muy a menudo, tenemos la ten- dencia a juzgar la calidad de los programas de evaluación de un entorno in- formático por el número de preguntas que lo componen. ¿Quién no habrá oído decir alguna vez: «El software Y, que acaba de salir, está compuesto por ¡más de 800 preguntas! Luego, el software X es obsoleto»?
Uno de los efectos dañinos más desastrosos de esta actitud reside en estos escuadrones de auditores júnior «desembarcados» ante los responsables in- formáticos veteranos teniendo como único equipaje los cuestionarios, algu- nas veces de calidad mediocre, y, de todos modos, dominando sólo superfi- cialmente el significado de sus preguntas.
He escuchado muy a menudo a los auditores hacer la misma pregunta bajo dos formas diferentes, sin tan sólo darse cuenta. El resultado es siempre catastrófico. O se dan cuenta inmediatamente los responsables informáticos de la falta de formación de sus interlocutores, o bien sospechan que utilizan procedimientos maquiavélicos destinados a llevarlos a contradecirse. En ambos casos, la imagen de la misión es deplorable. Y lo que es más, como el auditor no domina del todo ni el significado de las preguntas propuestas ni el de las respuestas dadas, la relación es muy a menudo imprecisa y algunas ve- ces equivocada.
En otras palabras, aun siendo el cuestionario de auditoría un soporte me- todológico del todo eficaz, no podrá jamás paliar una experiencia insufi- ciente.
¿Por qué esta advertencia? Para explicar que más que ahorrar al lector un aluvión de preguntas, mi objetivo, al final de los capítulos, ha sido justificar el interés de la auditoría informática, pero también hacer tomar conciencia de sus límites. No hay peor publicidad para la profesión que una incursión en objetivos poco precisos, donde el mandatario, neófito en la materia, se en- contrará en definitiva decepcionado por los resultados obtenidos.
Por supuesto, una buena comprensión del proceso necesita que éste sea ilustrado por varios modelos, por ejemplo, por medio de cuestionarios. Pero,
tratándose de una iniciación, mi interés radica en la presentación y la expli- cación de los objetivos básicos (en suma poco numerosos), y no en enumerar las sartas de preguntas, muy parecidas las unas a las otras, que se desprenden del mismo.
Por último y en especial, mi interés primordial será hacer entender bien al lector que la auditoría informática no es un fin en sí mismo, sino que se trata más bien de un conjunto de técnicas muy diversas que permiten dar res- puesta a objetivos también muy variados.
Primera parte
OBJETIVOS
Y MÉTODOS
DE LA AUDITORÍA
INFORMÁTICA
¿Qué es la auditoría informática? Si bien el concepto de la auditoría in- formática está hoy día ampliamente difundido, este término genérico en rea- lidad abarca objetivos y métodos de trabajo muy variados.
Para el Director general poco versado en la materia, se trata a menudo de una forma de «ver un poco más clara» la actividad de uno de los servicios clave de su empresa. Para el Director informático, la auditoría informática aporta, además de un asesoramiento sobre la organización, dado por especia- listas externos, el medio de seguir y justificar la aplicación de nuevas estruc- turas o de nuevos métodos. El Director financiero, en lo que le concierne, verá más a menudo el medio de estimar la fiabilidad de las cadenas del pro- ceso, de las cuales él es el usuario. Por último, el Interventor de cuentas, in- dependiente de la empresa y cuyo trabajo consiste en certificar las cuentas, se interesará, en particular, por los medios de utilización del instrumento in- formático para establecer y fundamentar su opinión.
Estos pocos ejemplos ilustran muy bien que, bajo un mismo término, se escondan objetivos totalmente diferentes. Por lo mismo, los métodos de tra- bajo y los instrumentos utilizados también serán diferentes. Esta heteroge- neidad se dará incluso dentro del perfil de los auditores informáticos. Aun- que algunos encargos serán llevados a cabo por auditores habituales o
comunes que hayan tenido una formación complementaria de corta dura- ción, por ejemplo en la utilización de software especializado, otros necesita- rán imperativamente la presencia de «hiperespecialistas». Pero, ¡es necesa- rio no equivocarse!
Esta primera parte de la obra, tiene como finalidad establecer una tipolo- gía de los objetivos de la auditoría informática y de los medios a utilizar para obtener estos objetivos.
Capítulo 1
Los objetivos de la
auditoría informática
Si exceptuamos el caso en el cual el término de auditoría informática de- signa, además de una manera impropia, la utilización del instrumento infor- mático en el marco de una misión más amplia (auditoría contable, auditoría financiera, auditoría operacional), el objetivo principal de una auditoría in- formática es siempre el mismo: comprobar la fiabilidad de la herramienta informática y la utilización que se hace de la misma.
Desgraciadamente, este objetivo fundamental es difícil de alcanzar. La complejidad de un entorno informático y de las cadenas de proceso que se manejan es tal, que es imposible para un auditor tener la seguridad de la fia- bilidad de este entorno, por más competente que sea e incluso al final de un estudio de larga duración.
De este modo, un software de facturación en una empresa industrial puede ser, aparentemente, de una fiabilidad total, gracias a una redacción clara y funcional de los programas, una documentación precisa y detallada, unos procedimientos de utilización sin imperfecciones y, sin embargo, ocul- tar en realidad graves lagunas. Por ejemplo, la falta de capacidad de una única zona de trabajo puede falsear centenares de facturas, por supuesto, aquellas cuyos importes son los más elevados, y poner de esta manera la em- presa en una situación de ventas con pérdida verdaderamente involuntaria. Ahora bien, el auditor, a través del análisis y de la relectura de los programas (software), tendrá poquísimas oportunidades de descubrir esta anomalía.
A la inversa, un software puede estar mal documentado, ser poco accesi- ble, ser utilizado en condiciones deplorables y revelarse en el uso perfecta- mente fiable!
Además, la paradoja sólo es aparente. La informática, a pesar de las evo- luciones de los dos últimos decenios, continúa siendo un ámbito de fuerte tecnicidad y cuyos especialistas son bastante celosos de sus prerrogativas y los programadores más competentes y los más activos no están siempre muy motivados a documentar los programas de los cuales son autores.
Además, el imperativo dado por la Dirección General de una utilización rápida puede contribuir a la insuficiencia de la documentación en aplicacio- nes que, sin embargo, son fiables. Más allá de cualquier medida, el desarro- llo de programas (software) «superficiales», poco documentados, pero de coste medio y de corta durabilidad es, algunas veces, un objetivo fijado por la dirección.
Y lo que es más, es sabido que, al igual que el hombre, ningún software es perfecto. Los buenos programas no son los que no tienen fallos, sino los que no tienen fallos «graves», y los incluidos en los campos más sofisti- cados.
De este modo, se sabe que en los sectores de actividades tan estratégi- cas como la espacial, la militar o la aeronáutica, el número de bugs1 en los
programas está lejos de ser cero, aunque éstos sean desarrollados por los técnicos más capacitados, disponiendo además de presupuestos consi- derables.
¿Cómo podría, en estas condiciones, nuestro pobre auditor informático, en un período de tiempo limitado, elaborar la clasificación entre los errores que pueden atentar contra la integridad de las aplicaciones y los errores me- nores?
Tanto más cuanto el auditor, aun siendo un especialista de informática, no siempre es un especialista en los campos funcionales que controla. El auditor externo, perteneciente a una empresa de servicios o a un bufete de auditoría, intervendrá en los sectores de actividades diversas, y pasará de empresas in- dustriales a empresas comerciales hasta incluso a bancos o compañías de se- guros. Incluso el auditor interno, aparentemente mejor favorecido, no puede, por lo general, tener un conocimiento perfecto de la actividad del grupo en el cual participa. Esto sería debido a la diversidad de actividades de las filiales de la mayoría de los grupos nacionales o multinacionales.
Las conclusiones de estas cuestiones preliminares pueden parecer bastante sombrías. ¿Tiene la auditoría informática alguna utilidad desde el momento en que ninguna tarea, aunque sea difícil y costosa, no puede dar certeza alguna en cuanto a la fiabilidad del software? ¿Puede llegarse a la conclusión que las aplicaciones más fiables son las menos documen- tadas?
En realidad, y a pesar de todas las reservas precedentes, la auditoría infor- mática tiene, sin ninguna duda, su razón de ser. En primer lugar porque, in- cluso si no puede dar ninguna exactitud, puede suministrar opiniones serias sobre la Habilidad de un entorno. Una aplicación, aunque sea mal documen- tada, puede ser fiable si el programador que la ha desarrollado es competente y si él asegura el mantenimiento. No obstante, esta insuficiencia de docu- mentación tendrá en todos los casos una consecuencia casi segura que es que el mantenimiento de la aplicación se hará extremadamente delicado desde el momento en que el mismo no estará ya asegurado por su autor. Peor todavía, además éste habrá estado «genial» y además el mantenimiento será difícil, pues habrá utilizado técnicas de programación lo más sofisticadas, de difícil dominio por parte de sus sucesores.
Por otro lado, una cosa esencial que puede hacer la auditoría informática es comprobar que el servicio informático aplique la política que le ha sido dictada por la Dirección General. Es del todo admisible que una empresa no disponga permanentemente de un emplazamiento de emergencia para sus aplicaciones, a condición de que se trate de una decisión de la Dirección mo- tivada por la comparación entre el coste de las consecuencias de un siniestro (y de la indisponibilidad del equipo que resultará de éste) y el coste del man- tenimiento de un emplazamiento de emergencia.
La auditoría informática es útil, pero no constituye una ciencia exacta. Debe apoyarse en un conjunto de suposiciones. Esta es la razón por la cual los objetivos precisos asignados a una misión de auditoría y las técnicas uti- lizadas son tan variables. Son estos objetivos los que especificaremos a con- tinuación en este capítulo.
1.1 EL ESTUDIO DE FIABILIDAD DEL
ENTORNO INFORMÁTICO
a) El interés de un buen control interno
Antes de nada, especifiquemos la noción de control interno, que estará presente a lo largo de esta obra. El colegio de expertos contables lo define como «el conjunto de medidas que contribuyen al dominio de la empresa. Tiene como finalidad, por un lado, asegurar la protección y salvaguarda del patrimonio y la calidad de la información, y por otro, la aplicación de las, ins- trucciones de la dirección y favorecer la mejora de las actuaciones. Se mani- fiesta por medio de la organización, los métodos y procedimientos de algu- nas de las actividades de la empresa para mantener la perennidad de la misma».
A la vista de esta definición se comprende fácilmente el interés de un buen control interno de la función informática. Una buena organización de conjunto de esta actividad, la existencia de procedimientos y métodos satis- factorios constituyen, de hecho, un primer supuesto de fiabilidad y de peren- nidad del software desarrollado.
A título de ejemplo, en ausencia de la definición de una política de salva- guarda de los ficheros y del software, los riesgos que no hayan sido previstos para la salvaguarda de ciertos datos vitales no deben excluirse.
Otro ejemplo es que la inexistencia de normas de programación deja a cada programador la libertad de elección de su método, lo que origina una mayor dificultad de mantenimiento de las aplicaciones y, por consiguiente, una degradación progresiva de la fiabilidad de las mismas.
Por el contrario, la existencia de procedimientos de control y de autoriza- ción de acceso a las aplicaciones limita innegablemente, incluso sin supri- mirlos, los riesgos de manipulaciones fraudulentas por parte de los usuarios. De la misma manera, una gestión seria de las bibliotecas de programas en uso, la implantación de software dedicado a la seguridad y a la confidenciali- dad de los datos, o aun la realización sistemática de un control de explota- ción a posteriori, están encaminados a reducir los riesgos de operaciones equivocadas o fraudulentas de parte de los informáticos.
Los retos de la puesta en marcha de un buen control interno en el seno de un servicio de informática deben, además, estar claramente explicitados. Los procedimientos demasiado formalistas son, a menudo, interpretados por los informáticos como un signo de desconfianza, incluso como una sospecha con relación a ellos. Son susceptibles de dañar la motivación de los grupos de trabajo, con lo que se consigue el efecto contrario al deseado.
En realidad, estos procedimientos apuntan mucho más a reducir los ries- gos de errores lamentables, en otras palabras, proteger a los informáticos ante ellos mismos, que revelar operaciones malévolas. En este sentido, los procedimientos formalizados bien entendidos, aun cuando en un principio implican algunas tareas complementarias, constituyen a la larga un factor de mejora de la eficacia de la actividad informática.
b) Los demandantes de una auditoría de la actividad informática
Los demandantes potenciales de una auditoría de la actividad informática son múltiples.
En primer lugar, la Dirección de la empresa ha entendido bien las razo- nes evidentes que le llevan a cuestionarse sobre la calidad de un instru- mento que hoy día es la piedra angular de muchas empresas. Esta inquie- tud es tanto más comprensible en cuanto que, si existen los medios
cuantitativos y cualitativos eficaces para evaluar la mayoría de los demás sectores de la actividad (producción, comercial, compras, etc.), el director de empresa está a menudo en inferioridad de condiciones ante una activi- dad técnica en la cual, generalmente, no ha sido formado. Por lo tanto, es del todo legítimo que haga uso de las competencias necesarias para com- probar el seguimiento de las directrices que, en principio, fueron definidas por él mismo.
El responsable informático igualmente puede recurrir a la auditoría de su servicio. De esta forma, podrá obtener la opinión motivada de especialistas, al contacto con varios emplazamientos, sobre su propia organización. En un contexto de reorganización, la auditoría será también para él una forma de ratificar algunas de sus constataciones y, por lo tanto, de justificar, y de hacer aceptar a sus colaboradores, la nueva estructura y los nuevos procedimientos introducidos.
Por último, los controladores ajenos de la empresa (interventores de cuentas, administración fiscal, comisión bancaria en los establecimientos fi- nancieros, Tribunal de Cuentas, etc.) tienen igualmente la vocación de inte- resarse por la calidad del entorno informático, ya que ella es la condición primordial de la fiabilidad de los programas, y de los datos cifrados que es- tán obligados a utilizar o a controlar.
De este modo, la función informática, al igual que las demás funciones de la empresa, debe ser auditada regularmente. Además, se puede constatar que, si hace una década los auditores eran, a menudo, vistos en los servicios informáticos con sorpresa y a veces con recelo, el primer sentimiento ha de- saparecido y hoy en día la auditoría informática es aceptada al mismo nivel (o casi) que la auditoría financiera.
También ahí conviene estar vigilante y aclarar bien las razones de la audi- toría. Encargada por la Dirección general en un contexto de relación tensa con la Dirección informática, el auditor será considerado (a veces con razón) como un «cortacabezas». Encargada por la Dirección de informática hacién- dose cargo de sus funciones, ¿no es la auditoría el pretexto para una crítica o para poner en tela de juicio la labor del predecesor en dicho cargo, sino que es el medio para un estado de cosas objetivo?
En un contexto de desconfianza, la auditoría informática pierde una buena parte de su interés técnico y se transforma tan solo en el medio de rati- ficar las decisiones ya tomadas hace mucho tiempo.
c) Los componentes de una auditoría de la actividad informática
Por lo general, en la auditoría de un entorno informático se distinguen cuatro componentes:
— El examen de la organización general del servicio.
— El examen de los procedimientos relativos al desarrollo y al manteni- miento de las aplicaciones.
— El examen de los procedimientos relativos a la utilización de las cadenas de tratamiento.
— El examen de las funciones técnicas.
Incluiremos igualmente los controles técnicos específicos relativos a la protección y a la confidencialidad de los datos.
Volveremos más detalladamente sobre estos diferentes aspectos en la se- gunda parte de la obra.
d) Los métodos de auditoría de la actividad informática
En el marco del control de la fiabilidad del entorno informático, el audi- tor pondrá su atención en un conjunto de puntos clave, que constituyen un buen o un mal control interno.
Por lo general, formará su opinión tanto a través de entrevistas con el per- sonal del servicio informático como con un determinado número de usua- rios. Procederá igualmente al control de documentos y listados para ratificar las respuestas obtenidas o bien para completar su información sobre ciertos ámbitos.
Para ayudarle en su tarea, el auditor cuenta hoy día con diferentes instru- mentos, comercializados en el mercado por los bufetes de auditoría o empre- sas de servicios, cuyas prestaciones están, en realidad, muy cercanas las unas a las otras.
Estos instrumentos tienen todos como base un cuestionario de auditoría, más o menos detallado según el caso. Por lo general, un software va acompa- ñado del método y las respuestas son entonces introducidas en un microor- denador y las conclusiones de la auditoría son presentadas posteriormente bajo formas asequibles y didácticas («rosetón» de auditoría, o sea, notación que pone en evidencia los puntos fuertes y débiles, etc.).
Sin querer adelantar la presentación de estos métodos, lo que encontrare- mos en la cuarta parte de la obra (capítulo 13), nos limitamos aquí a sugerir algunos temas para reflexión:
— ¿Es siempre posible ratificar las notas atribuidas, a menudo basadas tan solo en las respuestas dadas a los auditores en el curso de sus entrevistas? — Más generalmente, ¿se puede confiar en ciertos métodos basados en una
autoevaluación por parte de los informáticos y de los usuarios de sus pro- pias fuerzas y debilidades?
— No siendo la seguridad informática una ciencia exacta, ¿no es entonces subjetivo y peligroso querer cuantificar, a toda costa, las informaciones esencialmente cualitativas?
1.2 EL ESTUDIO DE LA EFICACIA Y DE LAS
ACTUACIONES DE LA ACTIVIDAD INFORMÁTICA
La seguridad de un centro informático es una cosa y su eficacia y actua- ción son otras muy distintas. Hemos insistido anteriormente sobre el hecho de que un buen control interno era un factor de eficacia. No es menos verdad que los arbitrajes entre el coste de la seguridad y los imperativos presupues- tarios son a veces necesarios.Así, en materia de back-up2, una solución ideal consiste en disponer per-
manentemente de un emplazamiento de emergencia en estado de funciona- miento y listo para tomar el relevo en el caso de indisponibilidad del empla- zamiento principal. Sin embargo, esta solución casi nunca se adopta debido a su coste. Se prefieren generalmente medidas menos onerosas tales como: un contrato de puesta a disposición en caso de necesidad de un emplaza- miento de back-up a través de un suministrador externo, una sala vacía lista para recibir el equipamiento en caso de necesidad, duplicación de las máqui- nas de explotación con el funcionamiento estropeado de una de ellas, si se diera el caso, etc.
Generalmente, la auditoría de la eficacia se interesa más bien por aque- llos aspectos no cubiertos por la auditoría de seguridad. En especial, se estu- diarán a fondo las prestaciones y la dimensión de los equipos físicos. De he- cho, aun cuando un exceso de capacidad de las unidades centrales o de los discos con relación a las necesidades no estorban al buen control interno del centro, no deja de ser un factor de coste adicional inútil.
La adecuación a las necesidades del software de sistema constituye igual- mente un tema interesante. Ciertas PYME no cuentan con grandes sistemas informáticos con un software sofisticado, pero necesitan la presencia de téc- nicos cualificados y costosos (principalmente ingenieros de sistemas), cuando sus sistemas hubieran podido ser tratados sin dificultad por equipos de per- sonal reducidos en miniordenadores.
En otras palabras, la auditoría de eficacia en la materia comprobará que no se hayan implantado configuraciones desproporcionadas sólo por amor al arte.
2. Procedimientos de reinicio de explotación.
Para tales misiones se reciben órdenes ya sea de la Dirección general, in- teresándose sobre el coste de su informática, o bien del responsable de infor- mática deseoso de comprobar la pertinencia de su configuración. Se en- tiende fácilmente que estos encargos exigen por parte de los auditores unas competencias técnicas particularmente elevadas. Así, la presencia en el equipo de ingenieros de sistemas que tengan un perfecto conocimiento de la maquinaria es muy a menudo deseable.
1.3 ESTUDIO DE FIABILIDAD DE UNA APLICACIÓN
INFORMATIZADA
1.3.1 Los objetivos de la auditoría
La finalidad primordial, claro está, es pronunciarse sobre la calidad de una aplicación dada, por ejemplo: gestión de existencias, gestión de produc- ción, contabilidad general, auxiliar y analítica, compras, gestión comercial, etcétera.
En realidad detrás de este objetivo básico se pueden ocultar motivaciones bastante diferentes, en función de las cuales convendría elegir las técnicas de auditoría más apropiadas.
• Control de la/labilidad del software o control del uso que se da al
mismo
Muy burdamente, podríamos considerar que en el primer caso es la pres- tación del servicio informático lo que se controla, cuando en el segundo, lo es la actividad del usuario.
Dicho de otra forma, un software puede ser fiable, pero mal utilizado, o bien a la inversa, bien utilizado pero poco fiable.
Imaginemos un software contable, cuya toma de datos se lleva a cabo de forma normal, pero que «borra» por error los datos en los ficheros. Este soft- ware evidentemente es poco fiable a pesar del uso correcto que se hace del mismo.
Por el contrario, la mayoría de los programas contables, con el fin de co- rregir las anomalías en el contenido de los ficheros, admiten un procedi- miento de introducción de datos desequilibrados (o sea, donde el debe no es igual al haber) debiendo esta operación estar reservada excepcionalmente sólo a los usuarios competentes. Si es utilizado de forma abusiva, este proce- dimiento, aunque responda a una necesidad real, puede conducir a situacio- nes totalmente anárquicas.
Por supuesto, la diferenciación entre el control del programa y el control de la utilización del mismo es voluntariamente caricaturesca, y las cosas son en realidad más sutiles. Un buen programa contiene «protecciones» contra una mala utilización y un buen usuario utiliza los instrumentos de control de la fiabilidad de las aplicaciones.
En el ejemplo anterior el servicio contable detectará con facilidad la des- igualdad entre débitos y créditos y, por consiguiente, la existencia de datos borrados, y el programa contable editará de forma diferenciada la lista de da- tos introducidos por el procedimiento de exclusión para el análisis. ¡Tam- bién es necesario examinar y conservar esta lista!
No es menos verdad que la fiabilidad de una aplicación informática resulta de la conjunción de un buen programa y de una utilización satis- factoria.
• Control de la adecuación del software desarrollado a las
especificaciones funcionales o control de la adecuación de las especificaciones funcionales para un buen control interno
Aquí también se encontrará por decirlo así la dualidad auditoría de los in- formáticos frente a auditoría de los usuarios.
Verificar la adecuación del software desarrollado según las especifica- ciones funcionales definidas en el pliego de condiciones, en principio re- dactado por los usuarios, significa comprobar que los programas desarrolla- dos por el servicio de informática estén de acuerdo con las necesidades expresadas.
Pero esta adecuación no es suficiente para garantizar la calidad de la apli- cación en su conjunto, puesto que las especificaciones funcionales pueden ellas mismas revelar insuficiencias o anomalías.
Imaginemos, por ejemplo, un software de gestión de existencias que su- ministra cada mes un listado de las existencias valoradas a precio medio ponderado. La necesidad de suministrar los elementos de un control perió- dico de los listados editados implica la previsión de la edición de una lista mensual incluyendo la existencia inicial y el detalle de los movimientos del mes que se valoriza, justificando de esta forma la existencia final. En otras palabras, el listado de movimientos de existencias garantiza la continuidad de la vía de revisión, o sea, la posibilidad de vincular las informaciones ele- mentales introducidas y los datos obtenidos. Por el contrario, la ausencia de este listado elimina toda posibilidad de control por parte de los usuarios del modo de valoración de existencias. La aplicación no lograría ser considerada como fiable si no se hubiera previsto la edición de la lista de movimientos de existencias en el pliego de condiciones.
Otro ejemplo: la concepción de las aplicaciones debe permitir respetar
los principios de separación de las funciones. De este modo, en materia fi- nanciera, las operaciones de contabilización y las de tesorería, en principio, deben estar conducidas por personas distintas. La concepción y la utilización del software deben también permitir respetar esta separación, principal- mente gracias a la puesta en práctica de controles de acceso apropiados.
Último ejemplo: un buen control interno implica la existencia de contro- les jerárquicos de las operaciones. Este principio tiene como consecuencia informática la definición:
— ya sea de procedimientos de ratificación de las operaciones por un supe- rior jerárquico desde su introducción;
— ya sea de procedimientos de edición de listados de control de las opera- ciones introducidas (exhaustivo o por exclusión) para ser analizados a posteriori por un superior jerárquico;
— o bien, de una combinación de ambos tipos de procedimientos.
De este modo, en materia de gestión comercial, algunas operaciones es- pecíficas introducidas por los vendedores, tales como unas comisiones acor- dadas, superiores a un cierto umbral, o superación por parte de un cliente del crédito máximo autorizado, etc., serán sometidas a la confirmación del di- rector comercial.
• Búsqueda defraudes o búsqueda de errores
En la inmensa mayoría de los casos, los riesgos de pérdidas relacionadas con los errores de realización o de utilización del software son infinitamente más importantes que los riesgos de pérdidas relacionadas con las operacio- nes dolosas o fraudulentas. Es, por lo tanto, la búsqueda de errores lo que será generalmente privilegiada por el auditor en su enfoque.
Por supuesto, en algunos casos específicos (presunción de malversación de fondos) o en ciertos sectores de la actividad (establecimientos financie- ros) la búsqueda de operaciones fraudulentas será parte de los objetivos asig- nados a la auditoría.
Entonces, se realizarán trabajos dedicados a esta búsqueda. Así, en un es- tablecimiento financiero se puede programar la ejecución regular de un soft- ware específico de barrido y análisis de los movimientos en las cuentas ordi- narias, con el propósito de revelar las operaciones sospechosas que sean susceptibles de encubrir una malversación de fondos.
• Control de calidad de los métodos de desarrollo del software
o control de calidad de los procedimientos de utilización
La calidad de los procedimientos de concepción y de realización de las aplicaciones constituye un supuesto de fiabilidad y de respeto de las especi- ficaciones funcionales.
Sin embargo, pueden aparecer anomalías graves en los ficheros cuando un programa, aunque sea perfecto, no sea utilizado de manera satisfactoria. De esta forma, los errores de utilización, como la doble ejecución de un pro- ceso en tiempo diferido o, por el contrario, su no ejecución, pueden alterar los datos contenidos en los ficheros.
Los procedimientos erróneos de utilización pueden de igual modo tener consecuencias dañinas sobre la perennidad de las aplicaciones. De este modo, en un emplazamiento externo, en ausencia de copias de seguridad de los programas o de los ficheros de importancia vital, éstos se encontrarán perdidos y serán imposibles de reconstruir en caso de siniestro que destruya dicho emplazamiento informático.
• Control de la fiabilidad del software y control de su perennidad
Acabamos de mencionar indirectamente esta diferencia. Un software puede revelarse fiable por la calidad de su concepción, pero no perenne de- bido a malos procedimientos de utilización.
De igual modo, un programa fiable en un momento dado, pero mal docu- mentado, verá su esperanza de vida notablemente reducida.
1.3.2 Los demandantes de una auditoría de aplicación informatizada
Al igual que para la auditoría general del entorno informático, los deman- dantes potenciales son múltiples.
El responsable informático, ante una aplicación sujeta a críticas y pre- guntándose sobre la posibilidad de volver a redactarla, podrá solicitar la au- ditoría. Una misión de este carácter será además tanto más útil en un con- texto de relaciones conflictivas entre el personal informático y los usuarios, en la medida que ella permitirá obtener una impresión externa y neutral.
El responsable de un servicio que utilice la informática estará también in- teresado en pedir que sea controlada la calidad de la aplicación que le ha sido suministrada. Ahí también, la auditoría le será particularmente útil cuando sus colaboradores hagan valer las «debilidades» del software, que perjudi- can la calidad de su propio trabajo.
Los controladores externos a la empresa desearán, muy en especial, eva- luar la calidad de los tratamientos que contribuyen al establecimiento de los documentos que ellos deben controlar. El interventor de cuentas ya no puede hoy día justificar las cuentas de sus clientes sin interesarse por ciertas aplica- ciones tales como: gestión y valoración de existencias, gestión de inmovili- zaciones, contabilidad analítica, etc.
1.3.3 Las dificultades de la auditoría de una aplicación informatizada
Ya hemos mencionado las dificultades y los límites de la auditoría de una aplicación informatizada. Una aplicación representa miles, incluso decenas de miles de instrucciones.
Incluso en el marco de un trabajo a largo plazo, está fuera de duda el con- trol de una aplicación por la relectura de los programas que la componen. Cuando más que, incluso a través de una relectura atenta de cada programa, será casi imposible detectar la mayoría de los errores potenciales.
Y lo que es más, ya hemos subrayado que la calidad de los programas sólo es uno de los elementos necesarios entre otros para la fiabilidad de una aplicación. Una mala utilización, los errores de utilización, o incluso las in- tervenciones directas en los ficheros, fraudulentas o simplemente erróneas, son otros tantos factores que perjudican la fiabilidad de la aplicación y no son detectables por el simple análisis de los programas.
Ahora bien, es tan impensable pedir al auditor informático que analice uno a uno el conjunto de los registros del conjunto de los ficheros que están siendo utilizados como pedirle que analice línea a línea los programas.
Una primera conclusión se impone desgraciadamente y es que el auditor informático está desarmado ante el control de una aplicación informatizada e, independientemente de la duración de su misión, no contará más que con supuestos pero jamás con realidades. Esta primera constatación explica por qué las conclusiones de este tipo de misión aparecen algunas veces como de- cepcionantes teniendo en cuenta los costes que comportan.
No obstante, no caigamos en un exceso de pesimismo. Incluso cuando no aporta la certeza, la auditoría de una aplicación no es inútil y, para establecer sus supuestos, el auditor dispone de diferentes métodos que pasamos a deta- llar a continuación.
1.3.4 Los métodos de auditoría de una aplicación
informatizada
a) Los juegos de prueba
El juego de prueba consiste en crear un entorno de test, que incluya una copia de los programas en uso y de los ficheros específicos.
Entonces, es posible controlar en este entorno el funcionamiento de los programas de una manera profunda, dentro del mínimo de casos de test o comprobación que han sido suficientemente preparados.
Además, antes de ser una técnica de auditoría, los juegos de prueba son ante todo un medio que permite a los usuarios llevar a cabo la «receta» de una aplicación previa a su utilización.
Técnica de una gran eficacia, los juegos de prueba son, sin embargo, rara- mente utilizados en materia de auditoría. Su principal inconveniente reside de hecho en la torpeza de su aplicación, que implica a menudo cambios de trabajo prohibitivos tanto para los informáticos, que forman la base del test, como para los auditores, que tienen que tener un conocimiento perfecto del conjunto de las prestaciones del programa.
Además, nombraremos las principales limitaciones de esta técnica: — Permite comprobar los programas, pero no el contenido de los ficheros
en uso. Ahora bien, hemos visto que los ficheros pueden detectar anoma- lías sin que los programas estén equivocados.
— Difícilmente es posible ser exhaustivo en los casos verificados por el juego de prueba.
— Esta técnica raras veces permite detectar las operaciones fraudulentas en la medida en que éstas se llevan a cabo, bien por la intervención directa en los ficheros, o bien por una modificación temporal de los programas, que no aparecen en el momento de la creación del software de compro- bación.
b) El examen del control del entorno informático para esta aplicación
Hemos mencionado (en el apartado a de 1.1) la primera preocupación de un buen control interno del entorno informático de una empresa, que es, en definitiva, una excelente prueba de la fiabilidad de los programas desarrolla- dos.
En otras palabras, uno de los medios básicos para controlar una aplica- ción consiste en controlar la calidad del entorno informático para esta apli- cación.
En concreto se estudiarán específicamente para la aplicación auditada:
— Los procedimientos de desarrollo y de mantenimiento, o sea, instrumen- tos, metodología, normas, documentación, procedimientos de puesta en marcha.
— Los procedimientos de uso, o sea, protección de acceso, copias de segu- ridad, preparación, arranque y control de trabajos en tiempo diferido, procedimientos de recuperación, seguimiento de incidentes.
— Las funciones técnicas, o sea, gestión de red, soporte microinformático. — La organización general del servicio y del proyecto.
El enfoque dirigido hacia una aplicación será incluso más preciso que un control del conjunto del emplazamiento.
Recordemos que el estudio detallado de los métodos de examen del con- trol interno de la función informática será tratado en la segunda parte de la obra.
El interés principal de este enfoque, además de que puede ser llevado a cabo en el marco de un presupuesto limitado, radica en que permite extraer presunciones acerca de la calidad de los programas. La ausencia de una me- todología de desarrollo, la debilidad de la documentación, la falta de un se- guimiento de los incidentes, un gran laxismo en las autorizaciones de acceso y una política de copias de seguridad o salvaguarda mal definida son tantos signos inquietantes que es muy raro que no se materialicen a través de graves carencias en la aplicación.
A la inversa, el principal reproche que se podría hacer a este método es que sólo suministra suposiciones y jamás las carencias detectadas.
Así, la técnica de los juegos de prueba pone en evidencia las anomalías seguras en los programas, o sea, el no cumplimiento de las especificaciones funcionales. De igual modo, el empleo del programa de auditoría (apartado 3.4 d) permite detectar las incoherencias comprobadas en el contenido de los ficheros.
Un control interno que falla por sí solo permite presuponer la existencia de tales insuficiencias.
En definitiva, el examen del control interno de la función informática por la aplicación constituye un primer enfoque relativamente poco costoso, pero que merece, por lo general, estar complementado por una o varias técnicas de auditoría.
c) Examen del control interno de la función tratada
Ya hemos subrayado que el control exhaustivo de una aplicación implica a la vez el control del software desarrollado y el control de la utilización que se hace del mismo. Una aplicación no puede ser considerada como fiable si, a pesar de los programas de calidad, se la utiliza sin sentido común.
En otras palabras, la implicación de los usuarios es tan importante que los controles de coherencia apropiados a su nivel son seguramente mejor ga- rante de la fiabilidad del software que la mayoría de los controles técnicos internos al servicio informático. A pesar de ser una idea muy difundida, los usuarios están lejos de ser desarmados y tienen en sus manos los medios de detectar la gran mayoría de los fallos de un software, cuyo origen se encuen- tra en un error de programación o en una mala utilización del sistema. Para ello, también hace falta que no hayan renunciado a asumir toda la responsa- bilidad en el momento de la aplicación de los tratamientos automatizados. Muy a menudo, ya sea por exceso de confianza ante un «dios informático» infalible o bien por negligencia (la informatización es un excelente pretexto para dejar de asumir sus propias responsabilidades), los usuarios tienen la tendencia a dejar de efectuar el mínimo de controles indispensables de la fia- bilidad del conjunto de la aplicación.
Por consiguiente, el auditor informático basará una parte importante de sus investigaciones en la utilización y el control por parte de los usuarios de los tratamientos informáticos.
Al extremo, y con riesgo de sorprender y decepcionar al lector, se puede considerar que si hubiera que elegir, a la hora de hacer una auditoría de una aplicación, entre trabajar ante el servicio informático y trabajar ante los ser- vicios de usuarios, la segunda solución sería indudablemente la más eficaz.
Habiendo hecho esta constatación, citamos algunos aspectos esenciales en este ámbito.
• La realización por parte del usuario de controles de coherencia que
lleva a los tratamientos
Ya hemos aclarado este aspecto, el cual ilustraremos con un ejemplo. En materia de software contable, los controles de coherencia del tipo: — suma de los asientos registrados = suma de los asientos resultantes en el
«borrador de registros» (listas diarias recapitulativas de los asientos re- gistrados);
— suma de los asientos listados en los borradores del mes = totalización de los asientos en los diarios contables del mes;
— totalización de los asientos listados en los diarios contables del mes = to- talización de los asientos del mes en los libros de mayor;
— acumulado de principio de período de los asientos del mayor + total de los movimientos del mes = acumulado de principio de período siguiente (en débitos y en créditos);
— saldo de las cuentas del mayor = saldo de las cuenta del balance;
permitirán detectar la mayoría de los errores de diseño, de aplicación y de
utilización del software contable. También hace falta que sean utilizados re- gular y cuidadosamente.
• La existencia de controles jerárquicos
La existencia de controles jerárquicos en las operaciones tratadas consti- tuye un elemento esencial de control interno del conjunto de los ciclos de la empresa.
Ya hemos ilustrado (apartado 1.3.1) la necesidad de procedimientos in- formáticos que permitan la corroboración o el control de los datos registra- dos, por parte de un superior jerárquico del operador, o sea:
— Listas-resumen de registros, detalladas o por exclusión, para control a posteriori.
— Procedimiento de autorización en tiempo real de determinados movi- mientos, previamente a su validación (control a priori).
• La existencia de una buena separación defunciones
Ya hemos ilustrado igualmente este aspecto del control interno (apartado 1.3.1).
Por lo general, se distingue en la actividad de una empresa: — Operaciones relativas a la realización del fin social. — Operaciones relativas a la conservación del patrimonio. — Operaciones relativas al tratamiento contable.
El cuidado de una buena separación de funciones permite atribuir a per- sonas distintas, para un mismo proceso de la empresa, la responsabilidad de los trabajos relativos a algunos de estos tres tipos de operaciones.
En el caso específico de los sistemas informatizados, el respeto de esta separación de funciones será controlado por la aplicación de sistemas de au- torización de acceso a los tratamientos mencionados a continuación.
• La existencia de procedimientos satisfactorios de autorización de acceso
Una aplicación no puede ser considerada como fiable si cualquiera que pertenezca o, peor aún, sea ajeno a la empresa, tiene la posibilidad de conec- tarse con ésta y de consultar o poner al día los datos básicos.
Más allá de los riesgos de operaciones fraudulentas o dolosas que son fá- ciles de imaginar, existe, de hecho, un riesgo importante de errores cometi- dos con toda buena fe y cuyo autor será a menudo difícil de localizar.
Volveremos, por supuesto, ampliamente, en el resto de la obra sobre la problemática de las autorizaciones de acceso, que pueden ser controladas por medio de diferentes técnicas, de las cuales la utilización de palabras clave es, hoy día, la más difundida.
• La capacidad y la integridad del personal
La capacidad y la integridad, tanto de los informáticos como de los usua- rios, constituye naturalmente un elemento esencial de la fiabilidad de las aplicaciones.
• La continuidad de la vía de revisión
La noción de continuidad de la vía de revisión de un sistema de informa- ción (se habla a menudo de pista de auditoría, del término anglosajón audit
LA NOCIÓN DE VÍA DE REVISIÓN
Extracto de la subsección IV del Plan General de Contabilidad Francés
4e «Debe ser posible, en cualquier momento, reconstruir a partir de datos
definidos a continuación, los elementos contables, listados e informaciones so- metidos a verificación o localizar a partir de estas cuentas, listados e informa- ciones los datos introducidos. Así, cualquier saldo de cuenta debe poder ser justificado por un extracto de los asientos de los cuales procede, a partir de otro saldo de esta misma cuenta. Cada uno de estos asientos debe traer consigo una referencia que permita la identificación de los datos correspondientes.»
Extracto del Reglamento nº 90-08 del 25 de julio de 1990 del Comité de Reglamentación Sanearía
En lo concerniente a la información incluida en las cuentas publicadas, el sistema de control interno debe garantizar la existencia de un conjunto de procedimientos, llamados pista de auditoría, que permita:
a) reconstruir en orden cronológico las operaciones;
b) justificar toda información por medio de un dato original a partir del cual debe ser posible remontar por una vía continua al documento de síntesis y recíprocamente;
c) explicar la evolución de los saldos de un extracto al otro por la conserva- ción de los movimientos que hayan afectado a las partidas contables. Las informaciones contables que figuren en las situaciones destinadas a la Comunidad bancaria, así como aquellas que son necesarias para el cálculo de las normas de gestión establecidas en aplicación del artículo 33 (6º) de la ley del 24 de enero de 1984 revisada, deben respetar, por lo menos, los dos pri- meros aspectos a y fe de la pista de auditoría. En este caso, se conservan los elementos constitutivos de la pista de auditoría relativos al extracto periódico más reciente y al último cálculo de algunas de las normas de gestión.
trail) corresponde a la necesidad de conectar los datos introducidos en este
sistema y las informaciones obtenidas. En otras palabras, la aplicación debe suministrar los elementos necesarios para la validación de los datos resultan- tes de las cadenas de proceso.
Ya hemos dado (apartado 1.3.1.) un ejemplo de listado necesario para la continuidad de la vía de revisión, o sea, el de la lista mensual de movimien- tos de existencias en un software de gestión de existencias.
Otro ejemplo será ilustrado con la ayuda de una cadena de gestión del in- movilizado. Si el importe de la dotación para amortizaciones del ejercicio se suministra sin justificación, es imposible controlar esta dotación y habrá pér- dida de la vía de revisión. Por el contrario, si esta dotación viene totalizada en un listado que incluya, línea a línea, las amortizaciones del ejercicio se puede detectar que:
— Todas las inmovilizaciones pertenecientes a la empresa, y sólo ellas, han sido tomadas en consideración.
— El cálculo de las dotaciones es correcto.
Mencionamos a título de ilustración que en Francia la noción de vía de revisión ha sido consagrada sin que el término sea explícitamente empleado por el plan contable 1982, y más recientemente, bajo el término de pista de auditoría, por el comité de reglamentación bancaria.
• La existencia de validaciones regulares del contenido de los ficheros
Los ficheros controlados por una aplicación informatizada contienen ciertos datos cuyo contenido es susceptible de ser objeto de una validación. De este modo, las existencias son controladas periódicamente durante los in- ventarios físicos3 y los saldos de las cuentas de terceros, clientes y proveedo- res, son implícitamente ratificados por la ausencia de litigios.
d) La utilización de los programas de auditoría
Hemos vuelto a recuperar voluntariamente el término de software de au- ditoría que es empleado corrientemente y, por desgracia, la mayoría de las veces de forma abusiva.
Por lo general, esta técnica tiene como objetivo desarrollar programas informáticos cuyo objetivo es controlar la fiabilidad de las aplicaciones au- ditadas.
Los lenguajes de programación, particularmente adaptados al desarrollo rápido de peticiones de análisis de ficheros, han sido a veces bautizados de forma abusiva como software de auditoría. En realidad, algunos de estos len- guajes tienen otros objetivos básicos y sólo son utilizados como accesorios en materia de programación:
— lenguajes de infocentro para el análisis rápido de los ficheros por los usuarios;
— lenguajes de desarrollo rápido de programas de edición destinados a los informáticos para la obtención de listados poco complejos.
Los lenguajes de programación tradicional (COBOL, etc.) permiten ade- más el desarrollo de programas de auditoría. Solamente el tiempo de progra- mación que implica su utilización (el Cobol es el de mayor difusión, pero también de lejos el más indiscreto de los compiladores) los hacen poco adap- tados a este tipo de función.
Citemos por último que algunos lenguajes han merecido la denominación de «software de auditoría» por la asociación a sus funciones básicas de mó- dulos («rutinas») específicamente destinadas a fines de auditoría, tales como: muestreo, análisis estadístico, etc.
Concretamente, los objetivos buscados por el diseño y la realización de programas de auditoría son variados y pueden ser distribuidos en dos cate- gorías:
• Los programas de selección para análisis de ciertos registros
existentes en los ficheros
Los tipos de selección son en sí mismos diversos.
En algunos casos, se trata de un simple muestreo, o sea, selección por control de una factura entre 1000, selección de las compras más significati- vas por su importe, etc.
Aun así, algunas veces estos registros detectan informaciones que, aun- que no sean necesariamente erróneas, justifican una búsqueda complemen- taria por su carácter excepcional, como por ejemplo, edición de las ventas en las que el porcentaje de comisión al cliente sea superior a un determinado lí- mite, edición del inmovilizado adquirido con anterioridad a una cierta fecha.
En otros casos, por último, las selecciones corresponden a anomalías, que son resultado de un error de programación o de una mala aplicación de los procedimientos: estado de existencias negativas, estado de ventas con pérdi- das, lista de los códigos de artículos que figuran en el fichero de facturación y no aparecen en el fichero de referencias de artículos.
• Los programas de validación de informaciones que provienen de la
aplicación
El objetivo del auditor será aquí dar validez al software para ciertos trata- mientos importantes, escribiendo por lo general un programa que contenga las mismas funciones que aquel que está siendo auditado.
Aunque este enfoque puede parecer sorprendente, permite a veces de- tectar errores bien inesperados. De este modo, la nueva redacción de un programa de evaluación de existencias conducirá a un valor total de 1.251.000,00 pesetas mientras que el programa «oficial» dé un total de 1.151.000,00 pesetas En este caso, el control realizado habrá puesto en evi- dencia una falta de capacidad de una zona de trabajo del programa «oficial». En esta zona, que consta de cinco cifras significativas, un artículo cuyo valor total era de 106.000 pesetas había sido valorado sólo por 6.000 pesetas. Ahora bien, en presencia de un fichero muy voluminoso, que representa un listado en papel de varias decenas de páginas, este error podría muy bien pa- sar desapercibido en controles manuales.
Por supuesto que la reescritura para el control de ciertos programas no puede ser más que una técnica restringida. Su generalización conduce, en efecto, a redactar nuevamente la aplicación auditada.
• Ventajas e inconvenientes de la gestión
El principal interés de este proceso radica en dar resultados concretos y en cifras. Además, cuando los programas de control son bastante numerosos y variados, la proporción de anomalías detectadas dará una primera imagen de la calidad de la aplicación. Pero, sobre todo, estos programas pueden ser completamente compilados.
Imaginemos por ejemplo que el objetivo sea controlar el seguimiento por los vendedores de la política comercial. Los programas puestos en práctica serán entonces del tipo:
— Edición de descuentos especiales acordados para ciertos clientes.
— Edición de descuentos especiales acordados sobre determinados ar- tículos.
— Edición de clientes sobre los cuales el margen es insuficiente. — Edición de los vendedores que realicen márgenes insuficientes. — Etcétera.
Imaginemos ahora que el objetivo sea controlar el seguimiento del proce- dimiento de entrega y de facturación. Los programas puestos en práctica se- rán entonces por ejemplo:
— edición de albaranes de entrega antiguos no facturados;
— edición de facturas en las cuales el precio unitario difiere de forma notable del que figura en el fichero de lista de precio;
— etcétera.
El inconveniente del proceso es el contrapeso de su ventaja, o sea, sólo puede suministrar informaciones parcelarias. De hecho, incluso cuando se utilizan lenguajes de programación sofisticados (con o sin rutinas de audito- ría), cada control necesita el desarrollo de un programa específico. Por lo tanto, es indispensable definir claramente los objetivos buscados, con el fin de evitar poner en práctica un alud de tests costosos e inútiles.
1.3.5 Los principales grupos de aplicaciones
Exceptuadas deliberadamente las aplicaciones de tipo científico o indus- trial (control de procesos, etc.) debido a su carácter, estudiaremos de una ma- nera más detallada, en la tercera parte de la obra, las modalidades de control de las principales aplicaciones de gestión informatizada de la empresa. Éstas son:
— Contabilidad general, analítica y auxiliar. — Gestión de existencias.
— Gestión comercial. — Gestión de compras. — Gestión de inmovilizado.
— Remuneración y gestión del personal.
1.4 UTILIZACIÓN DEL INSTRUMENTO INFORMÁTICO
EN EL MARCO DE UNA MISIÓN DE AUDITORIA
Abusando del lenguaje, designamos a menudo con el término de audito- ría informática el desarrollo de programas de control en el marco de una auditoría contable o de una auditoría operativa.En realidad, la informática no es más que un instrumento puesto al al- cance del auditor para llevar a cabo su tarea principal: la auditoría contable tiene como objetivo la comprobación de la regularidad y corrección de las cuentas de la empresa y la auditoría operativa pronunciarse sobre la fiabili- dad y la eficacia de un ciclo de la empresa (aprovisionamientos, ventas, pro- ducción, etc.)
Teniendo en consideración la fuerte automatización de la mayoría de las empresas, su control pasa necesariamente cada vez más por un control de las aplicaciones informatizadas, y por la utilización de instrumentos informáti- cos destinados a reducir la duración de estos controles mejorando así su efi- cacia.
Tomemos el ejemplo del auditor de cuentas que audita las inmovilizacio- nes. Ejecutado manualmente, el control del cálculo de las dotaciones es a la vez pesado y poco convincente, habida cuenta del pequeño tamaño de la muestra, que podrá razonablemente validar.
En cambio, el diseño de un software, por lo general poco complejo, que analice los ficheros del inmovilizado, permitirá recalcular y validar la dota- ción del ejercicio.
Y además, los programas complementarios pondrán en evidencia anoma- lías eventuales para el análisis:
— lista de las inmovilizaciones cuya dotación acumulada desde el principio sea inferior al mínimo lineal (siendo las dotaciones en tal caso insufi- cientes y las dotaciones diferidas irregularmente, ya que no fueron con- tabilizadas, siendo finalmente no deducibles fiscalmente);
— lista de las inmovilizaciones cuya fecha de aplicación difiere notable- mente de la fecha de instalación;
— etcétera.
A veces incluso el auditor desarrolla programas para conocer la inciden- cia financiera de sus advertencias. Ante las cuentas de clientes con insufi- ciente cobertura escribirá un programa de búsqueda de créditos antiguos y, si fuere necesario, de evaluación del importe de la cobertura a constituir.
Como se ve, la informática se ha transformado hoy día en la herramienta indispensable del auditor, sin cuyo dominio éste no podría cumplir su misión de una forma totalmente eficaz.
Felizmente algunos lenguajes de programación, llamados también len- guajes de infocentro, lenguaje de programación rápida o software de audito- ría, están bien adaptados a estas necesidades.
Sin embargo, la tarea no es fácil. Al llevar a cabo auditorías en empresas dotadas de configuraciones de todo tipo, recurriendo a diferentes constructo- res, el auditor debe adaptarse a entornos muy variados, incluso, si es el caso, por medio del dominio de varios lenguajes de programación.
Segunda parte
AUDITORÍA
DE LA ACTIVIDAD
INFORMÁTICA
¿Cómo estar seguro de la calidad del entorno informático?
En otras palabras, ¿qué controles hay que poner en práctica para obtener buenos supuestos concernientes a la fiabilidad, o por el contrario, a la falta de fiabilidad de las aplicaciones desarrolladas?
Para responder a esta pregunta el auditor se dedicará a comprobar que se hayan respetado los principios básicos de una organización que satisface la actividad informática.1
Con el propósito de suministrarle un soporte técnico en su gestión, esta segunda parte de la obra presenta, a partir de tales principios básicos de una buena organización, los principales puntos clave de evaluación del control interno de un entorno informático, o sea, por así decir, la lista de las áreas que conviene estudiar a fin de hacer una apreciación cualitativa de la fiabili- dad de este entorno.
Estos puntos de control han sido voluntariamente limitados en su canti- dad. Lo importante para el auditor no es de hecho hacer el máximo de pre- guntas sino dominar y evaluar los aspectos esenciales de la organización del servicio controlado.
1. Estos principios están especificados en la obra Les techniques de /'organisation informatique, colec- ción Dunod Entreprise,1991, del mismo autor.
Auditoría de la actividad informática 27
Hemos mencionado en la advertencia al principio de la obra, los riesgos inherentes a los cuestionarios voluminosos, donde, en definitiva, un gran nú- mero de preguntas se asemejan mucho las unas a las otras.
Las preguntas mencionadas han sido agrupadas en cinco partes: — La organización general del servicio.
— Los procedimientos de desarrollo y mantenimiento del software. — El entorno de producción.
— Las funciones técnicas.