técnicas de la auditoría informática.pdf

Técnicas de la

auditoríainformática

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 EDITORES

ESTRATEGIA Y GESTIÓNCOMPETITIVA

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

Índice general V

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

6.3 La conexión física con las líneas en las cuales circulan los datos ...... 119

VI Técnicas de la auditoría informática

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

Índice general VII

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 14.5 El seguimiento de las recomendaciones ........................................... 207

VIII Técnicas de la auditoría informática

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

Índice general IX

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 tendencia 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, algunas 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 veces 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 insuficiente.

¿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,

Advertencia 1

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 respuesta a objetivos también muy variados.

2 Técnicas de la auditoría informática

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 realidad 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 especialistas externos, el medio de seguir y justificar la aplicación de nuevas estructuras 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 proceso, de las cuales él es el usuario. Por último, el Interventor de cuentas, independiente 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 trabajo 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

Objetivos y métodos de la auditoría informática 3

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 necesario 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.

4 Técnicas la auditoría informática

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 fiabilidad 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, ocultar 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 empresa 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 perfectamente fiable!

Los objetivos de la auditoría informática 5

Además, la paradoja sólo es aparente. La informática, a pesar de las evoluciones 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 aplicaciones que, sin embargo, son fiables. Más allá de cualquier medida, el desarrollo 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 sofisticados.

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 considerables.

¿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 industriales a empresas comerciales hasta incluso a bancos o compañías de seguros. 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?

1. Errores de programa.


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, incluso 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 motivada 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 mantenimiento 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 utilizadas 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, instrucciones de la dirección y favorecer la mejora de las actuaciones. Se manifiesta por medio de la organización, los métodos y procedimientos de algunas 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 satisfactorios constituyen, de hecho, un primer supuesto de fiabilidad y de perennidad del software desarrollado.

A título de ejemplo, en ausencia de la definición de una política de salvaguarda 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 confidencialidad 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 riesgos 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 razones evidentes que le llevan a cuestionarse sobre la calidad de un instrumento 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 actividad 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 comprobar 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 financieros, Tribunal de Cuentas, etc.) tienen igualmente la vocación de interesarse 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 ratificar 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 segunda 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 auditor 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 personal del servicio informático como con un determinado número de usuarios. 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 instrumentos, comercializados en el mercado por los bufetes de auditoría o empresas 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 microordenador 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 encontraremos 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 propias 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 permanentemente de un emplazamiento de emergencia en estado de funcionamiento y listo para tomar el relevo en el caso de indisponibilidad del emplazamiento 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 emplazamiento 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 aquellos 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 hecho, 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 igualmente 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 personal 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 entiende 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 software 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 corregir las anomalías en el contenido de los ficheros, admiten un procedimiento 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 procedimiento, aunque responda a una necesidad real, puede conducir a situaciones 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 datos 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 satisfactoria.

• 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 especificaciones funcionales definidas en el pliego de condiciones, en principio redactado por los usuarios, significa comprobar que los programas desarrollados 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 suministra 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 elementales 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 financiera, 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, principalmente gracias a la puesta en práctica de controles de acceso apropiados.

Último ejemplo: un buen control interno implica la existencia de controles 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 superior jerárquico desde su introducción;

— ya sea de procedimientos de edición de listados de control de las operaciones 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 acordadas, 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 director 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 operaciones 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 financieros) la búsqueda de operaciones fraudulentas será parte de los objetivos asignados a la auditoría.

Entonces, se realizarán trabajos dedicados a esta búsqueda. Así, en un establecimiento financiero se puede programar la ejecución regular de un software 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 especificaciones 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 proceso 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 debido a malos procedimientos de utilización.

De igual modo, un programa fiable en un momento dado, pero mal documentado, 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 demandantes 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 contexto 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 interesado 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 perjudican la calidad de su propio trabajo.


Los controladores externos a la empresa desearán, muy en especial, evaluar 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 aplicaciones tales como: gestión y valoración de existencias, gestión de inmovilizaciones, 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 control 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 intervenciones 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, raramente 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 desarrollados.

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, instrumentos, metodología, normas, documentación, procedimientos de puesta en marcha.

— Los procedimientos de uso, o sea, protección de acceso, copias de seguridad, 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 control 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 seguimiento 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 garante 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 encuentra 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 responsabilidad 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 fiabilidad 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 servicios 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 registrados);

— 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 regular y cuidadosamente.

• La existencia de controles jerárquicos

La existencia de controles jerárquicos en las operaciones tratadas constituye 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 registrados, 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 movimientos, 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 personas 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 conectarse 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 sometidos a verificación o localizar a partir de estas cuentas, listados e informaciones 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 primeros 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 resultantes 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 movimientos de existencias en un software de gestión de existencias.

Otro ejemplo será ilustrado con la ayuda de una cadena de gestión del inmovilizado. 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 inventarios físicos3 y los saldos de las cuentas de terceros, clientes y proveedores, 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 auditadas.

3. Igual que las inmovilizaciones (a intervalos más distanciados).


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 lenguajes 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 adaptados 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 significativas por su importe, etc.

Aun así, algunas veces estos registros detectan informaciones que, aunque no sean necesariamente erróneas, justifican una búsqueda complementaria 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 tratamientos 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 detectar 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 evidencia 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 pasar 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 procedimiento 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 industrial (control de procesos, etc.) debido a su carácter, estudiaremos de una manera 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 alcance 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 fiabilidad 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 eficacia.

Tomemos el ejemplo del auditor de cuentas que audita las inmovilizaciones. 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 insuficientes 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 notablemente de la fecha de instalación;

— etcétera.

A veces incluso el auditor desarrolla programas para conocer la incidencia financiera de sus advertencias. Ante las cuentas de clientes con insuficiente 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 lenguajes 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 fiabilidad de este entorno.

Estos puntos de control han sido voluntariamente limitados en su cantidad. Lo importante para el auditor no es de hecho hacer el máximo de preguntas 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

i

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. — La protección y la confidencialidad de los datos.


Capítulo 2

La organización general del servicio informático

2.1 LA ESTRUCTURA DEL SERVICIO INFORMÁTICO

• P. ¿Existe un organigrama escrito del departamento de informática?

Aunque el organigrama escrito pueda parecer superfluo e incluso acon- gojante en las estructuras pequeñas, se impone desde el momento que el personal supera una decena de personas.

Encontraremos en la figura 1 una estructura tipo de servicio informá- tico y, en el recuadro que hay a continuación, una sucinta descripción de las principales funciones extraída de la obra Les techniques de l’ organisation informatique.

El auditor comprobará, por supuesto, que el organigrama que le es dado está al día y cubre el conjunto de las funciones necesarias para la buena marcha del servicio.

Además, las fichas de definición de función son deseables, en particular para ciertos puestos funcionales como: responsables de métodos, adminis- tradores de datos, responsables de la seguridad, etc. El análisis de estas fichas permitirá algunas veces descubrir que determinadas funciones no están cubiertas.

La organización general del servicio informático 29

Figura 1. Modelo de estructura de un servicio de informática.


A. LAS FUNCIONES PRINCIPALES EN EL SENO DE UN SERVICIO DE INFORMÁTICA

a) La función de estudios La función de estudios representa el conjunto del personal informático

dedicado al desarrollo de nuevas aplicaciones y al mantenimiento de las mismas.

Estas aplicaciones serán utilizadas a continuación por el personal de pro- ducción. Para fijar bien las ideas, tomemos por ejemplo la aplicación de un nuevo sistema de gestión de pedidos y facturación, decidida por la Dirección general. El Director de informática confía este trabajo al responsable de estudios, quien constituye un equipo bajo la responsabilidad de un jefe de proyecto. Este equipo escribe y prueba los programas (utilizando los lenguajes de tipo COBOL, GAP, o lenguajes más evolucionados conocidos como de cuarta generación), y posteriormente el usuario valida la aplicación gracias a un juego de prueba. Solamente después de este juego de prueba es cuando los programas son puestos en marcha y, por lo tanto, realmente utilizados bajo el control del personal de producción. El personal de estudios no tendrá ya que intervenir excepto para las operaciones de mantenimiento, es decir, para las operaciones de modificación de las funciones de los programas. Volveremos después sobre los métodos de puesta en marcha y de mantenimiento de las aplicaciones.

El responsable de estudios tiene, por lo tanto, el control del conjunto de las operaciones de desarrollo y de mantenimiento del software. Está asistido en sus funciones por varios jefes de proyecto responsables de uno o varios proyectos.

El jefe de proyecto dirige un equipo que puede estar constituido: — por analistas; — por analistas-programadores; — por programadores.

b) La función de producción Hace algunos años esta función era a menudo llamada explotación. Hoy

día, el término de producción consagra definitivamente el paso de la informá- tica de la era «artesanal» a la era «industrial».

En efecto, la organización de la producción ha evolucionado profunda- mente en pocos años, principalmente gracias al perfeccionamiento de los materiales y del software básicos. Al mismo tiempo, la cualificación del personal de producción ha subido considerablemente.

Para delimitar mejor lo que hoy día es la producción en un centro de tratamiento, partimos de la situación existente hace algunos años (y que hoy día algunas veces aún existe), para después entretenernos con las evoluciones más recientes.

Los preparadores: son los que han procedido a poner en marcha, y posteriormente en producción, las aplicaciones desarrolladas por el personal de estudio.

En efecto, los programas desarrollados por el personal de estudio han estado en un entorno de prueba, utilizando en particular ficheros o bases de da-


tos de test. La aplicación de estos programas necesita, por lo tanto, una modifi- cación de los procedimientos por medio del JCL (Job Control Language, o sea, del lenguaje de comando del ordenador), lo que permite relacionar el programa con su entorno exterior.2 En particular, en el caso de cadenas de tratamiento en tiempo diferido, los preparadores podrán proceder a una verdadera optimización del procedimiento. A título de ejemplo, si el jefe de proyecto hubiese previsto conservar en el disco duro un fichero destinado exclusiva- mente a fines de salvaguarda, el preparador lo podrá copiar en cinta magnéti- ca para reducir el espacio de disco consumido por la aplicación. En otras palabras y para simplificar las cosas, se puede considerar que el preparador hace pasar la aplicación a «tamaño real».

Más tarde, cuando una aplicación se encuentre en producción, será el preparador quien asegurará el conjunto de parámetros y el arranque suministrando todas las consignas necesarias a los operadores y, por consiguiente, al ordenador.

Los preparadores están, por lo general, agrupados en equipos de trabajo, cada equipo con la responsabilidad de un conjunto de aplicaciones.

Por ejemplo: un primer equipo se encarga de todos los procesos relacionados con la gestión de producción, otro se encarga de todos los tratamientos de tipo contable y el tercero se ocupa sólo de las aplicaciones de gestión comercial.

Los teclistas son las personas que están en relación directa con el ordenador por medio de su consola. Ellos ponen en marcha la máquina, la paran, la vuelven a poner en marcha en caso de avería. Ponen en práctica la ejecución de las cadenas partiendo de los procedimientos que fueron introducidos a la espera de tratamiento por los preparadores, luego, aseguran eventualmente ciertas intervenciones manuales que figuran en las consignas dejadas por los mismos preparadores (incluso en caso de incidente). Algunas veces los teclistas son auxiliados por los operadores en los trabajos más corrientes, tales como la colocación y retirada de cintas magnéticas en las bobinadoras, colocación de papel en las impresoras, etc.

Los teclistas están organizados en equipos para así asegurar una utiliza- ción continua de los ordenadores. Algunas veces 24 horas al día. Por lo general están especializados en una máquina. Los equipos de teclistas están algunas veces bajo la responsabilidad de un jefe de sala.

La célula de control tiene como objetivo el control de los resultados de los tratamientos en tiempo diferido antes de la distribución a los servicios de

2. Veremos a continuación un ejemplo simplificado intencionadamente con fines pedagó- gicos de un JCL de lanzamiento del programa FACT que lee en forma de secuencia el fichero de los pedidos para la emisión de facturas. II JOB EDIFACT Nombre de la tarea a ejecutar II OPTION LOG, PARTDUMP Opciones de ejecución

II ASSIGNSYS001, DISK,VOL=SYSWK1,SHR Relación entre los ficheros lógi- cos descritos en el programa y ficheros físicos en disco.

II DLBL FILE, FACTURE II EXEC FACT Lanzamiento de la ejecución del programa 0292 Parámetro de ejecución


usuarios de los listados correspondientes. La célula de control debe tener de este modo los «códigos» que permitan detectar eventuales anomalías de uso.

El gestor del archivo de cintas asegura la gestión física del parque de cintas magnéticas necesarias para las operaciones de salvaguarda.

El crecimiento excepcional de las capacidades de almacenaje en disco magnético en el curso de los últimos años ha conducido algunas veces a bajar la guardia en la vigilancia del espacio disco. La gestión del espacio disco representa una función importante en los grandes centros de proceso. El gestor, por supuesto, cuenta con la ayuda de sistemas de herramientas cada vez más eficaces, que permiten una gran automatización de esta función.

La gestión de la red representa igualmente una función nueva e importante. En efecto, las configuraciones informáticas actuales recurren, en gran parte, a las técnicas de transmisión de datos directamente o a distancia, utilizando, en el segundo caso, conexiones telefónicas especializadas, la red telefónica conmutada o también las redes especializadas. Además de la necesidad de utilizar el software especializado, cuya implantación es por lo general confiada al personal de sistema, esta evolución contribuyó a crear las funciones de gestores de red, que garantizan el seguimiento continuo de la misma, por medio de contacto telefónico con los usuarios,3 implantación de nuevos terminales, diagnóstico de las paradas de sistema más comunes (corte en la red, incidente en la unidad central, terminal desconectado, etc.).

Sólo los trabajos de manutención (desconexión, guillotinado, encuader- nación, etc.) ocupan a menudo varias personas en los grandes centros infor- máticos.

Por último, el departamento de registro, bajo la responsabilidad de una monitor a, agrupa el personal encargado de la toma del caudal de documentos, muy a menudo bajo la forma de una doble toma (asegurada por las perforadoras-verificadoras). Como es sabido, esta función se ha reducido considerablemente en el curso de los últimos años por el hecho de la aplicación progresiva de procedimientos de registro interactivo por los propios usuarios. En algunos casos específicos, sin embargo, el registro masivo encuentra todavía su razón de ser.

Después de este recuento de las principales funciones propias de la pro- ducción informática, conviene aportar un cierto número de complementos relacionados con la evolución reciente de esta actividad.

• Teniendo en cuenta el desarrollo de los sistemas de explotación y en particular del número de aplicaciones que pueden ser ejecutadas simultánea- mente en una misma máquina (multiproceso), el teclista ya no puede conocer las especificaciones de estas aplicaciones ni tampoco velar por las operaciones propias de éstas. Él es el garante del buen funcionamiento del ordenador, pero no del buen funcionamiento de las aplicaciones utilizadas por este ordenador. Al igual que un fabricante de televisores, que es el garante de la calidad técnica del aparato, pero no de la calidad de las emisiones. Además, la apari- ción de los grandes sistemas de programas ha permitido automatizar un nú- mero importante de órdenes de tecleado y reducir otro tanto la carga de los teclistas, los cuales, la mayoría de las veces, sólo procesan las intervenciones más delicadas. En lo que concierne a la función del operador, ésta debería

3. Se habla a menudo de hot Une.


desaparecer progresivamente, sólo con la sustitución de las cintas magnéticas por cuya manipulación es totalmente automatizada.

• Simultáneamente, gracias a la evolución de los sistemas de explotación, es posible prever una automatización cada vez más estimulada por las cadenas de proceso y por los procedimientos de reanudación en caso de incidente. Par- tiendo de este hecho, se tiende a sustituir la noción de preparador por la de responsable de producción de aplicación, teniendo cono funciones:

— La puesta en explotación de las nuevas cadenas de proceso y optimiza- ción de la utilización de los recursos.

—Su preparación y su arranque con periodicidad ad hoc. — El control de su buena ejecución. — Las relaciones con los usuarios. El responsable de producción de aplicaciones (o analista de aplicaciones)

cuenta además desde ahora con instrumentos informatizados para la prepa- ración y control de explotación.

• El papel de la célula de control tiene tendencia a reducirse. En efecto, las anomalías que tiene a su cargo descubrir tienen su origen:

— ya sea en errores de explotación, que pueden ser detectados por el propio analista de explotación al recibir los informes de explotación producidos por la máquina;

— o bien, en anomalías funcionales, las cuales también son detectadas con mucha eficacia por los propios servicios de usuarios.

c) Las funciones de sistemas El software básico puesto a disposición de los informáticos es cada vez más

numeroso. Los sistemas de explotación, compiladores, monitores de teleproceso, software de protección de acceso, sistema de gestión de base de datos, diccionarios de datos, gestor de red, gestor de espacio disco, gestor de archivo de cintas, etc., son solamente algunos ejemplos entre tantos.

El papel de los ingenieros de sistemas es elegir el software que mejor se adapte a las necesidades de su empresa, implantarlos, regular sus parámetros y, quizás lo más delicado, conseguir que cohabiten de forma armoniosa.

d) Las junciones técnicas Estas funciones no han aparecido en la mayoría de los centros informáti-

cos hasta el último decenio. Citaremos a título de información las funciones en este área: — Responsable de la microinformática. — Responsable del infocentro (puesta a disposición de los usuarios de

lenguajes de interrogación simples). — Responsable de los métodos. — Responsable de la seguridad. — Responsable de las bases de datos. — Responsable de las redes. En los centros importantes, estas funciones están a veces agrupadas en el

seno de una dirección técnica.


2.2 LA PLANJFICACIÓN DE LA ACTIVIDAD INFORMÁTICA

• P. ¿Existe un comité informático, responsable de las principales decisiones estratégicas?

Con frecuencia, la Dirección general de la empresa delega a la Dirección de informática la definición de la política a llevar a cabo. Esta delegación es evidentemente peligrosa en la medida de que el personal informático tiene la tendencia a favorecer a sus propios criterios en la elaboración de las orienta- ciones estratégicas.

De este modo, las elecciones de equipamiento corren el riesgo de ser llevadas a cabo tanto en función del interés técnico de la maquinaria como en función de sus cualidades intrínsecas. Igualmente, las prioridades en materia de desarrollo de los programas podrían estar influenciadas por la calidad de las relaciones de la informática con los diferentes Directores de la empresa, o incluso por el carácter más o menos innovador de la aplicación a ser conce- bida, tanto como por la importancia que ésta representa para la empresa.

Incluso con un equipo de personal informático totalmente integrado y objetivo, no es bueno que éste asuma la responsabilidad de arbitrajes entre servicios que puedan, con el tiempo, transformarse en fuente de relaciones conflictivas.

Por lo tanto, es esencial que las decisiones estratégicas sean llevadas a cabo por la Dirección general. El comité de informática, compuesto por re- presentantes de la Dirección general, por responsables de cada Dirección de la empresa, y por los principales responsables de la Dirección de informá- tica, es, por lo general, la instancia más apropiada para asumir esta decisión. Tendrá a su cargo, por ejemplo, la elaboración o la aprobación del plan infor- mático, tanto equipos como software, los presupuestos, la definición de prioridades a corto plazo, el arbitraje de los conflictos eventuales y el seguimiento de la calidad del servicio producido.

• P. ¿Hay un plan informático?

El plan informático tiene como objetivo anticipar las principales evoluciones de la actividad informática, tales como: equipos, programas básicos, progamas de aplicaciones, recursos humanos.

La elaboración del plan informático es, no obstante, un ejercicio peligroso, teniendo en cuenta la rapidez de la evolución tecnológica. Así pues, ¿cómo se pueden prever los equipos que serán implantados en una empresa en un plazo de 24 meses, cuando los propios fabricantes desconocen lo que


será su política comercial en este plazo, o por lo menos no la han revelado todavía al público?

De forma análoga, las prioridades de desarrollo de aplicaciones pueden ser cuestionadas por varias razones, como por ejemplo: evolución de la polí- tica comercial, situación de la competencia, modificación de la legislación vigente, etc.

Un plan informático demasiado detallado está, por lo tanto, desgraciadamente condenado a una rápida obsolescencia. Por el contrario, un plan demasiado impreciso no necesitará ser cuestionado, pero no tendrá ninguna utilidad.

Estos argumentos no deben conducir al rechazo de toda planificación. Tienen más como finalidad sacar a la luz la necesidad de un cuestionamiento permanente de los planes. El auditor sacará sus conclusiones sin resaltar el desacato al plan, por lo menos cuando las evoluciones han sido aprobadas por la Dirección general.

2.3 EL SEGUIMIENTO DE COSTES

• P. ¿Hay un presupuesto informático?

Más allá de la simple existencia de un presupuesto, el auditor se dedicará a su contenido, el cual puede ser muy variable de una empresa a otra.

Se encontrará, entre otras cosas, los encabezamientos de capítulo siguientes: equipos, programas básicos, programas de aplicación, remuneraciones, telecomunicaciones, materiales consumibles (papeles, etc.).

• P. ¿Se justifican sistemáticamente los incrementos de costes?

Un crecimiento importante en los presupuestos de informática no deben ser criticados a priori. Puede corresponder a necesidades reales, tales como: introducción de una aplicación importante, evolución hacia un software más asequible. Pero, a la inversa, los presupuestos deben estar justificados y, si fuere necesario, ser objeto de arbitrajes por parte de la Dirección general en función de las prioridades que contenga.

• P. ¿Hay un seguimiento de la actividad del personal de informática?

Cuando, en un centro pequeño, le compete al responsable de informática controlar la actividad de sus colaboradores, este seguimiento, sin las herra-


mientas apropiadas, se hace rápidamente imposible a partir del momento que aumenta la magnitud del servicio.

Así, en ausencia de un procedimiento serio de seguimiento de la actividad, las informaciones tan importantes como el coste de cada proyecto o la distribución en el seno del servicio entre las actividades de desarrollo y de mantenimiento, serán mal identificadas.

El argumento frecuentemente evocado por los responsables de informá- tica para rechazar un seguimiento de este estilo, a saber, el riesgo de rechazo por su personal de procedimientos demasiado apremiantes, incluso cuando no debe ser subestimado, es que no pueden resistir una constatación simple del tipo: ¿Cómo y por qué la informática se ha transformado en la única actividad que no se preocupa de sus precios de coste?

• P. ¿Se facturan los costes de la informática a los servicios de usuarios?

La respuesta a esta pregunta sólo puede ser analizada en el contexto más general del control de gestión en el seno de la empresa.

La falta de facturación de costes encuentra a veces su justificación en la voluntad de «promover» la informática. Esta «promoción», no obstante, a priori será limitada en el tiempo.

Cuando hay refacturación, ésta incluirá habitualmente una separación entre:

— Los costes de desarrollo. — Los costes de mantenimiento. — Los costes de explotación.

• P. ¿Hay en el seno del servicio de informática una función de auditor de gestión?

Curiosamente, la Dirección de informática ha sido una de las últimas direcciones de la empresa en preocuparse por controlar sus costes. Con frecuencia, la informática ha vivido en el axioma de que todo crecimiento de su presupuesto contribuía a la automatización de sus usuarios y, por lo tanto, a una reducción global de los gastos generales de la empresa. Este principio, que ha justificado a menudo incrementos de presupuesto considerables, es frecuentemente rebatido por la realidad. Los desarrollos inútiles o lujosos, las dificultades sociales que impiden cualquier reducción de los efectivos, la inadaptación de la organización, son algunos de los factores que limitan las reducciones posibles de gastos generales.

Hoy día, la mayoría de las empresas ha comprendido que el control de los


gastos generales pasa también, entre otras cosas, por un control de los gastos de informática, justificando así la creación de una función de auditor de ges- tión en el seno de esta dirección para los grandes centros, o por lo menos el seguimiento por parte del auditor de gestión de los costes de informática al igual que los otros costes.

2.4 LAS PRÁCTICAS CONTABLES Y FINANCIERAS

• P. La elección del modo de financiación de los equipos, ¿es económicamente satisfactoria?

La elección del modo de financiación (compra, leasing) debe ser objeto de un estudio que observe, de acuerdo con las condiciones del mercado del momento, las posibilidades financieras de la empresa y la duración previsible de la utilización del equipo.

• P. ¿Son coherentes los períodos de amortización elegidos para los equipos y, en su caso, para el software, con su período de utili- zación previsible?

Los equipos y programas adquiridos se amortizan en su período probable de utilización.

Los períodos de amortización demasiado largos son con el tiempo generadores de pérdidas excepcionales.

A título de ejemplo, podemos prever un período de amortización de:

— Tres años para los microordenadores. — Cinco años para otros equipos. — Cinco años para los programas, salvo aquellos que están relacionados

con los equipos, que se amortizan en el mismo tiempo que éstos.

Los gastos de desarrollo interno de software específico son la mayoría de las veces imputados por prudencia. Sin embargo, se notará que, bajo reserva de que se cumplan ciertas condiciones, dicho software debe ser inmovilizado y amortizado en el período probable de utilización de los programas.4

4. Para más exactitud sobre los principios contables, ver Les techniques de l'organisation informatique, Dunod, 1991.


2.5 LAS RELACIONES CON LOS SERVICIOS DE USUARIOS

• P. ¿Hay un seguimiento de la calidad del servicio prestado?

Los instrumentos de medición simples dan una primera estimación de esta calidad de servicio:

— Disponibilidad de la unidad central. — Disponibilidad del teleproceso (incluso disponibilidad de las líneas

mismas). — Tiempo de respuesta medio de las transacciones. — Frecuencia de los incidentes por aplicación.

Por otro lado, las herramientas de seguimiento permiten optimizar la con- figuración y, en su caso, anticipar las evoluciones de éstas antes de que se re- gistre una degradación de las actuaciones. Se trata, por ejemplo, de los instrumentos de medida de la carga de la unidad central de la tasa de ocupación de los discos.

• P. ¿Está previsto en el servicio de usuarios una Junción de corresponsal informático?

El corresponsal informático es, en cada servicio, la interfaz con los infor- máticos. El interés de esta función es innegable. En efecto, el corresponsal informático dispone, además de un buen conocimiento de la actividad de su servicio, de una buena cultura general informática que le permite a la vez aconsejar eficazmente a los usuarios y llevar apropiadamente los procesos de mantenimiento que emanan de su servicio.

En ausencia de esta función, es de temer que no tardarán mucho en llegar al servicio de informática peticiones contradictorias.

• P. ¿Se tienen en cuenta en el diseño de nuevas aplicaciones los problemas relacionados con la organización de los servicios de usuarios y con la adecuación de los procedimientos administrativos ?

Se pueden considerar varias soluciones para dar respuesta a este objetivo:

— Creación de una estructura de organizadores dependientes del responsable de informática.


— Creación de una dirección de la organización dependiente de la dirección general.

— Reclutamiento de jefes de proyectos de alto nivel capaces de asumir igualmente la función de organizador (esta última solución es, no obstante, cada vez mas difícil de aplicar teniendo en cuenta la dicotomía entre las competencias técnicas, cada vez más elevadas, exigidas a los jefes de proyecto, y las competencias específicas inherentes a la función de organizador).

2.6 LA SEPARACIÓN DE FUNCIONES

• P. ¿Hay en la organización del servicio informático una separación entre las funciones de estudios y las de explotación?

Los principios de un buen control interno conducen a que sean separadas las funciones:

— de los usuarios; — del personal de estudios; — del personal de explotación.

• Los usuarios

Tienen acceso a las transacciones para las cuales han sido habilitados. En cambio, no deben tener ninguna otra posibilidad de actualizar los ficheros de explotación.

• El personal de estudios

Desarrolla y prueba los nuevos programas en un entorno de prueba dedicado a este fin, después solicita la puesta en explotación. En cambio, una vez en explotación, no tiene acceso por ningún medio a los ficheros.

De este modo:

— No conoce la palabra clave de los usuarios de la aplicación que él mismo ha desarrollado.

— No tiene acceso ni a los ficheros ni a la biblioteca de programas en ex- plotación.

— No pone él mismo en explotación los programas que ha desarrollado.


• El personal de explotación

Es responsable de la puesta en explotación y de la producción de los programas desarrollados por el personal de estudios. En cambio, no debe, bajo ningún concepto, desarrollar o actualizar él mismo tales programas.

* * *

Los medios para conseguir una buena separación de las funciones son varios y volveremos a hablar de los mismos más adelante de forma más detallada.

Citemos a modo de ejemplo:

— El control de acceso de los usuarios al entorno informático (palabras clave, cartas de memoria, etc.).

— La limitación de acceso a los locales. De este modo, el acceso a los locales que abrigan los despachos y puestos de trabajo de los titulares de ciertas funciones sensibles (ingenieros de sistemas, teclistas, etc.) será estrictamente reglamentado y, la mayoría de las veces, el personal de estudios no tendrá acceso a los locales ocupados por el personal de explotación.

2.7 EL CONTROL DE LA ACTIVIDAD

• P. ¿Se efectúan regularmente misiones de auditoría de la actividad informática?

Como hemos aclarado en la primera parte de la obra, un control de la actividad informática puede cubrir diferentes aspectos, tales como:

— Control de seguridad o control de las actuaciones. — Control del entorno informático o control de una aplicación particular.

Este control puede, además, ser llevado a cabo a diferentes niveles. En efecto, podrá ser efectuado dentro del servicio informático (por ejemplo, por un responsable de seguridad); o bien fuera del servicio informático pero dentro de la empresa (generalmente por la Dirección de la auditoría); o, por úl- timo, fuera de la empresa (contrato de servicio).

Por lo general, el auditor se ocupará de la frecuencia de las auditorías realizadas anteriormente y, por supuesto, de las conclusiones de las mismas.


2.8 EL ENTORNO SOCIAL

• P. ¿Es coherente la tasa de rotación del personal informático?

Un primer indicador «social» es, por supuesto, el turn-over del servicio. Una rotación muy importante o una rotación muy escasa están encaminadas a dañar la calidad del servicio prestado. Los inconvenientes de la primera opción, la cual de alguna forma es la enfermedad crónica de la informática, son evidentes: poco dominio de las aplicaciones por parte de los equipos que no participaron en su diseño, falta de experiencia, falta de motivación de los informáticos que tienen tendencia a considerarse como «de paso».

No se deben menospreciar los inconvenientes de una rotación demasiado escasa de efectivos. Ésta conduce, en efecto, a un envejecimiento de la po- blación con los riesgos que esto comporta: falta de motivación, disminución de la competencia técnica y de la capacidad innovadora y costes de prestaciones elevados. Es verdad que el problema se parece bastante a la cuadra- tura del círculo. El informático, más que ningún otro, está considerado como obsoleto a partir del momento que se acerca a los cuarenta, además por razones, la mayoría de las veces, de tipo subjetivas. Conociendo el problema, él mismo evita, a partir de esta edad, todo tipo de movilidad, de donde surge el riesgo de reducción de competencia.

Muy concretamente, el auditor estará particularmente vigilante ante tasas de rotación inferiores al 15 % o superiores al 25 %. También hace falta especificar la gran propensión que tienen las empresas a «cubrir» las estadísticas en este campo. Así pues, si todas las ESII5 reconocen el problema general de un gran turn-over en la profesión, cada uno, individualmente, probará con base estadística que es bastante reducida.

En cualquier caso, la tasa de rotación del personal sólo puede ser analizada en relación con algunas características de la gestión de los recursos humanos que mencionaremos sucintamente a continuación.

• P. ¿Es satisfactoria la política de contratación de personal?

Un turn-over importante tiene algunas veces su origen en los procedimientos de contratación de personal. De este modo, la contratación sistemá- tica de principiantes implica un riesgo más grande de rotación rápida. De la misma forma, la contratación de personas super cualificadas conduce a una rápida puesta en cuestión, por parte de éstas, de su estatuto, pues ahí también existe una gran probabilidad de salida.

5. Empresas de servicios e ingeniería informática.


Las remuneraciones muy bajas en la contratación o, por el contrario, demasiado elevadas son igualmente orígenes de dificultades rápidas.

Además, la validación de la competencia y de la integridad de las personas contratadas y su adecuación a los puestos propuestos, constituye un componente esencial de la calidad del procedimiento. Si bien una validación técnica es a menudo delicada, la empresa no se encuentra totalmente desar- mada.

• P. ¿La política de remuneración está de acuerdo con las normas del mercado?

Una política de remuneraciones muy bajas conduce en poco tiempo a un turn-over elevado. La situación inversa es igualmente peligrosa. Las remuneraciones demasiado altas son fuente de inmovilismo, luego de envejecimiento de una población cuya edad media es, en principio, baja.

Además, el auditor comprobará que dentro del servicio las remuneraciones sean coherentes entre sí.

• P. ¿Es coherente la cualificación del personal con la función que ejerce?

Si el exceso de cualificación del personal es fuente de rotación rápida, la falta de cualificación es todavía más lastimosa, ya que ella induce a un riesgo, en muy corto espacio de tiempo, de degradación de la calidad del servicio prestado.

• P. ¿Está controlado el recurso de colaboradores externos?

El recurso de colaboradores externos no debe estar prohibido a priori. En efecto, ofrece diversas ventajas:

— Permite absorber las sobrecargas temporales de actividad. — Permite contar con recursos de competencia técnica especial y adquirir

progresivamente estas técnicas. — Permite, por último, en algunos casos, integrar temporalmente dentro del

personal perfiles «raros», evitando así un recalentamiento de las remuneraciones.

Sin embargo, la empresa no debe hacerse tributaria de sus colaboradores. Dentro de esta óptica, y salvo en casos excepcionales y que estén totalmente justificados:


— Los colaboradores no deberían ocupar puestos que les dieran las responsabilidades jerárquicas dentro del servicio (jefes de proyecto, etc.).

— El número de colaboradores no debería en ningún caso sobrepasar del 20 al 25 % del personal.

• P. ¿Ha habido en el pasado hechos significativos en materia de gestión de personal?

El auditor se interesará, por ejemplo, por:

— Un número elevado de despidos, y las condiciones de estos despidos. — Los movimientos sociales (huelgas,...).

• P. ¿El interés técnico de la actividad informática permite una motivación satisfactoria del personal?

Está claro que el servicio informático no debe definir su actividad «por amor al arte». Escoger los equipos y el software básico más sofisticados implica no solamente un incremento del coste de los servicios prestados, sino también, en particular, un riesgo de encontrarse con problemas técnicos, que los servicios seguramente no sabrán resolver.

De este modo, muchos programadores, aficionados a las bases de datos interrelacionadas, han tenido que renunciar a esta técnica, cuando ésta estaba aún en sus principios, debido al tiempo de proceso prohibitivo que impli- caba. En este caso los propios programadores se han dado cuenta de que no tenían ninguna necesidad de una base de datos relacionada. Desgraciada- mente este descubrimiento ya había costado tiempo y dinero a su empresa. Se comprende entonces que la utilización de las técnicas más sofisticadas, aunque no estén todavía muy difundidas, deben continuar siendo patrimonio de los grandes centros de proceso, los cuales disponen de medios y de competencias para remediar dificultades eventuales y que, además son susceptibles de desarrollar aplicaciones experimentales.

En cambio, la implantación de equipos y de software básico poco difundidos, o superados técnicamente, al igual que el desarrollo de aplicaciones basándose en diseños obsoletos, son un factor de desinterés por parte de los informáticos. ¿Qué jefe de proyecto estaría interesado actualmente en un di- seño de un software totalmente basado en tiempo diferido («batch»), cuando incluso el tiempo real estaría efectivamente totalmente injustificado?

Independientemente de las consideraciones de carácter puramente téc- nico, que justifican por sí solas la evolución de las configuraciones, la Direc- ción de la empresa pondrá todo su interés en velar por que su informática no se torne arcaica.


En el caso de configuraciones estereotipadas y pasadas de moda, que algunas veces encuentran su razón de ser (¿por qué refundir las aplicaciones en los sectores de actividad con pérdida de velocidad y condenarlas a un abandono progresivo?), deberá entonces anticipar el riesgo de una falta de motivación progresiva de los equipos de personal informático.

Y lo que es más, una configuración obsoleta conduce a una «obsolescencia» rápida de los hombres mismos, la cual conviene también prevenir.

• P. ¿Es suficiente la formación del personal?

Incluso cuando la formación permanente «en el taller» es una caracterís- tica principal de la actividad de los informáticos, las formaciones teóricas ocupan a la par, y con toda razón, una parte importante en el presupuesto de los recursos humanos de los servicios informáticos.

Una política de formación insuficiente es, en efecto, un factor a la vez de falta de motivación y de disminución de capacidad del personal.

• P. ¿El contexto general de la empresa es fuente de motivación?

Un sector de actividad en declive o aun una localización geográfica des- favorable pueden tener consecuencias catastróficas en la contratación y en la rotación de los informáticos, los cuales, en un mercado dinámico perderán el interés por las empresas que tengan algún handicap.

He conocido una empresa con estas características, cuya informática era técnicamente competitiva y actualizada, pero que no podía retener a sus in- formáticos por la única razón de que estaba situada en un barrio de poco prestigio y, por lo general, poco asequible para los medios de transportes. Como última salida, esta empresa se ha orientado hacia el denominado «facilities management».6

2.9 LAS RELACIONES CON LOS PROVEEDORES

• P. ¿Existe una licitación o concurso para la elección de los sumi- nistradores de equipos o de software?

El recurso de proveedores externos para un servicio informático puede distribuirse en tres categorías:

6. «Facilities management» (gestión de servicios) consiste en la subcontratación total o parcial de la actividad informática (desarrollo y explotación) a un suministrador del servicio externo.


— La adecuación de los equipos frente a los fabricantes (o, según la forma de financiación, ante las sociedades de leasing).

— La adquisión de software, comercializado por los fabricantes de hard- ware o, más frecuentemente, por las ESII (Empresas de Servicios e Inge- niería Informática).

— El recurso a las ESII para la elaboración, en administración o en bajo contrato, de software específico para la empresa.

Veremos en los cuadros que siguen una lista de comprobación relativa a estas prestaciones externas.

B. CUESTIONARIO RELATIVO A LA ELECCIÓN DE LOS EQUIPOS

■ El llamado a licitación del equipamiento — ¿Se lleva a cabo una licitación para la elección del equipamiento que re-

presenta importes significativos (en la medida en que el equipo no va impuesto por una estimación preexistente)?

— Incluye: el pliego de condiciones del equipamiento que sirve de soporte a la licitación

— ¿La descripción de las aplicaciones a procesar? — ¿Una estimación de los volúmenes presentes y futuros? — ¿Una lista de las exigencias de explotación, tales como tiempo de res-

puesta, duración de los procesos, procedimientos de reactivación, confidencialidad, etc.?

— ¿Las fechas de entrega de los equipos a ser respetadas? — ¿La elección de las prestaciones se halla formalizada y basada en cri-

terios concretos?

* La negociación del contrato — Prevé el contrato negociado con el proveedor escogido:

— ¿Penalizaciones en caso de retrasos en las entregas? — ¿Un compromiso sobre la capacidad del equipamiento servido para

procesar las aplicaciones definidas en el pliego de condiciones con los volúmenes estimados y respetando las exigencias impuestas?

— ¿Un compromiso sobre el tiempo de respuesta del sistema? — ¿Un compromiso del coste de los incrementos futuros de la configuración? — ¿Las condiciones del mantenimiento, como costes, modalidades, retra-

so de intervención, etc.?

• Las condiciones de mantenimiento — ¿Hay un seguimiento cualitativo de los equipos y de su mantenimiento?:

— ¿Media de tiempo de buen funcionamiento (MTBF)? — ¿Seguimiento de incidentes y averías? — ¿Rapidez y calidad de las intervenciones de mantenimiento?


- ¿Se ha estimado el coste de mantenimiento de los equipos? — ¿El plazo de intervención contractual se corresponde con las necesidades? — ¿Se han estudiado soluciones del tipo «mantenimiento por parte de

terceros»? — ¿Se renegocian las condiciones regularmente?

C. CUESTIONARIO RELATIVO A LA ELECCIÓN DE PROGRAMAS

- ¿Se redacta un pliego de condiciones previamente a la elección de los programas (salvo cuando esto es impuesto por una situación existente con anterioridad, como por ejemplo el caso de cierto paquete de software básico del fabricante)?

- Incluye el pliego de condiciones del programa:

— ¿la descripción de las funciones a procesar? — ¿los volúmenes a procesar? — ¿los plazos para el arranque? — ¿las obligaciones en materia de seguridad? — ¿los datos básicos que deben ser controlados en los ficheros? — ¿una descripción de las funciones cuya entrega podría ser solicitada en

una segunda etapa? - ¿Se estudian y comparan varios programas antes de la elección definitiva? - Se apoya la elección definitiva sobre:

— ¿la calidad de las propuestas recibidas? — ¿visitas a compañías que tienen el programa? — ¿consideraciones generales sobre el proveedor, como: envergadura,

notoriedad, calidad de los interlocutores, etc.? — ¿las consideraciones concernientes al programa, como: número de re-

ferencias, perennidad previsible, etc.? — ¿la calidad de la documentación del programa?

- Prevé el contrato firmado con el suministrador del servicio: — ¿un compromiso por el procesamiento de las aplicaciones previstas en

el pliego de condiciones? — ¿un compromiso por el procesamiento de los volúmenes previstos en el

pliego de condiciones? — ¿las penalizaciones, en caso de retraso por parte del colaborador? — ¿la definición precisa de la asistencia prestada, como: formación, do-

cumentación, asistencia en el arranque, mantenimiento inicial, etc.? — ¿las condiciones del mantenimiento del programa? — ¿las condiciones de pago del coste de la prestación?7

- ¿Está previsto que la empresa disponga de los programas fuente?

7. Por lo general, se prevé un calendario de pagos en función del avance de las prestaciones: — el primer adelanto al efectuar el pedido; — pago contra entrega de software después de la «factura provisoria», o sea, de la valida-

ción por parte del cliente basándose en un juego de prueba; se retiene un saldo de garantía hasta «la factura definitiva».

— pago del saldo cuando se emite la «factura definitiva», después de algunos meses de funcionamiento satisfactorio del software.


Nota: Aun cuando el colaborador conserve la propiedad del programa fuente, es deseable que la empresa disponga de una copia, en particular cuando la envergadura de la ESII no permita garantizar la perennidad del programa; además del interés para la empresa de poder modificar ella misma el software en caso de fallo de su proveedor. Nos referiremos en este punto a las obligaciones en materia contable y fiscal. — ¿Está prevista una fase de validación del programa sobre la base de un

juego de prueba en el momento del arranque? — La utilización posterior del programa:

— ¿Está previsto un seguimiento cualitativo del programa, como: históri- co de los bugs,8 rapidez del mantenimiento?

— ¿La modificación por la propia empresa misma del software servido por la ESII se evita en la medida de lo posible (en caso contrario, la ESII no estará más en condiciones de garantizar el mantenimiento de su producto y, además, será difícil implantar las versiones siguientes)?

D. CONVOCATORIA A LAS ESII PARA LA REALIZACIÓN DEL SOFTWARE ESPECÍFICO SOBRE UNA BASE DE PRECIO ALZADO

Siendo el procedimiento relativamente cercano a los de la elección de un programa, las preguntas del apartado C son siempre válidas. Sin embargo, pondremos especial interés en algunos aspectos más «sensibles» en el caso de un software específico: — La calidad del pliego de condiciones que sirve de base a la relación con-

tractual y el hecho que ésta defina con suficiente exactitud las funciones a desarrollar.

— Los medios para asegurar el respeto de los plazos de realización por el suministrador del servicio.

— Los puntos de validación intermedios proyectados, como: análisis funcional (si no vienen íntegramente detallados en el pliego de condiciones), aná- lisis técnico detallado, etc.

— La calidad de las modalidades de validación del software antes de su puesta en explotación (generalmente sobre la base de un juego de prueba que sirve de soporte a la «receta provisoria»).

— El contenido de la documentación entregada.

E. CONVOCATORIA A LAS ESII PARA LA REALIZACIÓN DEL SOFTWARE ESPECÍFICO EN ADMINISTRACIÓN9

En este caso, la ESII tiene por lo general como única obligación aportar el personal de estudio (ingenieros, analistas y programadores) que se integrarán en los equipos de desarrollo que trabajan con los proyectos conducidos por la empresa misma.

8. Anomalía de programa. 9. El término «en administración» consiste en que la ESII factura su asistencia en función del tiempo empleado por los colaboradores que ella pone a disposición de su cliente.


El auditor se encargará de algunos aspectos específicos relativos a la par- ticipación de colaboradores externos a la empresa en el proyecto, tales como: — Modalidades de elección de las ESII. — Calidad general de los participantes. — Nivel de responsabilidad confiado a los colaboradores (éstos, en principio,

deben estar a las órdenes del personal perteneciente a la empresa). — Respeto por parte de los colaboradores externos de las reglas deontológicas en materia de confidencialidad de la información. — Seguimiento específico de la actividad de los colaboradores externos. — Prohibición de acceso de los colaboradores externos a ciertas funciones

(si fuere necesario). — Coherencia de las tasas diarias de facturación.


Capítulo 3

Los procedimientos de desarrollo y de mantenimiento del software

El desarrollo y el mantenimiento del software son, por lo general, calificados como actividades de «estudio», por oposición a la fase de explotación (o de producción) posterior al arranque «real» de la aplicación.

Serán, por lo tanto, estudiados en este capítulo los principales ámbitos de investigación relativos a la auditoría de un servicio de estudio.

3.1 LA METODOLOGÍA DE DESARROLLO DE LAS APLICACIONES

• P. ¿Se realiza siempre un estudio de oportunidad previo al lanzamiento del diseño de una nueva aplicación?

La oportunidad o no de desarrollar una nueva aplicación no es siempre evidente. De este modo, el auditor se encuentra algunas veces frente a costosos estudios detallados de sistemas de información, incluso con desarrollos de software, abandonados brutalmente sin verdadero motivo. Uno se ha dado cuenta durante el estudio que el software antiguo era del todo satisfac-


torio y que era completamente inútil sustituirlo. O aún, el diseño de la nueva aplicación adquiría proporciones considerables y ha parecido más razonable interrumpirla antes que alcanzara proporciones desorbitadas.

Estas situaciones muy costosas son generalmente el síntoma del mismo error: la ausencia, al principio del estudio, de una reflexión previa en cuanto a la oportunidad del proyecto. Esta reflexión tiene como objetivo, después de un análisis sumario de las necesidades de la arquitectura técnica futura de la aplicación, estimar el coste global del proyecto, para después pronunciarse sobre la prosecución de su aplicación.

Con el fin de facilitar la decisión, el estudio de oportunidad presentará, además, las ventajas y los límites del sistema propuesto, las principales obligaciones inherentes de su aplicación, y un primer calendario de reali- zación.

La instancia de decisión en cuanto al abandono o la prosecución del proyecto será generalmente el Comité informático o, más directamente, la Di- rección general. Una decisión llevada a cabo por el servicio informático, o por el único servicio operativo al que concierne, debe ser evitada, en la medida en que ésta se puede transformar posteriormente en fuente de tensiones, si se sospecha de parcialidad en su elección por parte de los susodichos servicios.

Si se da el caso, más allá de la decisión de abandono o de prosecución del proyecto, se arbitrará un cierto número de decisiones técnicas fundamentales al final del estudio de oportunidad, tales como: informática centralizada o descentralizada, prioridades de arranque, desarrollo de software específico o adquisición de programas, etc.

Por último, hacemos mención a que, si se puede admitir una cierta flexibilidad en el nivel de formalización del estudio de oportunidad (no es, por ejemplo, deseable exigir de una PYME documentos voluminosos para el estudio de proyectos «pequeños»), la existencia misma de una reflexión previa al lanzamiento de cada proyecto es, en cuanto a ella, del todo indispensable.

El estudio de oportunidad incluirá principalmente:

— La presentación sucinta de las funciones a desarrollar. — Las principales obligaciones de aplicación. — Si fuere necesario, una presentación de las diferentes soluciones técnicas

entre las cuales será conveniente arbitrar. — Una estimación de los volúmenes a procesar. — Una estimación de los costes previstos y, si fuere el caso, de los benefi-

cios financieros esperados. — Un calendario preventivo de la aplicación.

Desarrollo y mantenimiento del software 51

• P. Ante todo desarrollo de software o toda adquisición de programas, ¿se analizan las ventajas y los inconvenientes respectivos de la adquisición de un programa y de la realización de un sistema específico?

Conviene insistir muy particularmente sobre la utilidad de este análisis. Muy a menudo, los servicios informáticos desarrollan sistemas de contabilidad general o de nómina muy complejos, por el solo hecho de incluir algunas necesidades complementarias de menor importancia en relación a las prestaciones de los programas disponibles en el mercado.

• P. ¿Se redacta un pliego de condiciones previo al lanzamiento de la realización de nuevo software?

Evitaremos aquí un debate semántico sobre las diferentes fases de la vida de un proyecto. Modelos conceptuales y organizativos de los procesamien- tos y de los datos (vocabulario ligado a la metodología MERISE), análisis funcional (que define las funciones del software a desarrollar por oposición al análisis orgánico que definió las especificaciones técnicas), pliego de condiciones, etc., son muchos términos cuyo contenido exacto puede variar ampliamente de una interpretación a otra.

De todas formas, si el número y el contenido exacto de las diferentes fases de un proyecto puede variar en función del tamaño de la empresa y de la importancia de los proyectos, existe un punto de paso obligado en todo proyecto: el acuerdo entre los informáticos y los usuarios sobre el contenido de la aplicación a desarrollar. Este acuerdo se formalizará imperativamente por medio de un documento escrito, que llamaremos aquí pliego de condiciones y que incluirá, en efecto, el conjunto de las especificaciones funcionales del futuro sistema de información.

De alguna forma, se puede comparar el pliego de condiciones con la re- cuperación de los puntos de apoyo antes de la ejecución de una volea en un partido de tenis. Si el atacante no se toma su tiempo para la recuperación de sus puntos de apoyo, la volea, jugada en desequilibrio, terminará en la red o fuera de los límites de la pista.

Ocurre lo mismo con el pliego de condiciones. En su ausencia, es casi seguro que los programas desarrollados no corresponderán a las necesidades de los usuarios. El ahorro de algunos días empleados en la redacción, sin duda alguna trabajosa, de un documento de síntesis, parecerá irrisorio en comparación con los costes extraordinarios y los retrasos en los plazos que tendrán origen en esta falta de comprensión.

Y además, esta ausencia de formalización será fuente de conflictos. ¿La inadecuación del software es consecuencia de una mala expresión de las ne-


cesidades por parte de los usuarios, o bien de un mal análisis por parte de los informáticos?

Por tanto, la formalización de los análisis preliminares al desarrollo de un software es el origen de duros debates entre auditores y auditados. Cuántas veces he oído a los responsables de pequeñas estructuras informáticas afirmar terminantemente que, si bien, de una forma general, los pliegos de condiciones eran útiles sin ninguna duda, no se justificaban en sus casos particulares. La variedad de los argumentos es además infinita:

— «¡para tal máquina, el análisis funcional es inútil!»; — «en nuestra empresa, los nuevos desarrollos son escasos y siempre de

poca monta (pero mi predecesor, que había desarrollado varias aplicaciones muy gravosas, no nos ha dejado ningún análisis, lo que nos plantea grandes problemas»);

— «tenemos los informáticos más importantes y los usuarios más inteligen- tes y, no obstante, los dossieres son inútiles»;

— «mi Director general tiene toda mi confianza».

El único problema de este cuadro idílico es finalmente que, al salir del contexto de una auditoría, estos mismos responsables informáticos confesa- rán sus dificultades imputables, por supuesto, a la incompetencia notoria de sus interlocutores, cuando ésta no es otra que la de sus propios colaboradores.

En definitiva, la famosa frase de los automovilistas «esto sólo ocurre a los demás» encuentra del todo su aplicación en los fracasos de proyectos in- formáticos.

Sin que la lista sea exhaustiva, podemos nombrar como principales documentos contenidos en el pliego de condiciones:

— La descripción de las funciones a desarrollar. — La descripción de las pantallas de tomas de datos y de consulta. — Los procesos a realizar. — La lista y el contenido de los principales listados editados. — La lista y el contenido de los ficheros constitutivos de la aplicación (a ex-

cepción de los ficheros de trabajo). — La previsión de los volúmenes a procesar.

Según el caso, encontraremos igualmente las modalidades y el calendario de ejecución y de arranque de la aplicación.

Para concluir este importante y espinoso tema, citaremos una evolución interesante para el análisis de las aplicaciones. El desarrollo de programas de «maquetación» que, principalmente para las aplicaciones transaccionales, permite visualizar en la pantalla las propuestas de clave de registro y de con-


sulta que formarán la aplicación. Si bien estos «modelos» no sustituyen en ningún caso a un pliego de condiciones, ya que sólo definen los soportes de entradas y salidas interactivas pero no los procesos en sí, se debería, sin embargo, generalizar de forma progresiva y substituir los diseños demasiado complejos de la pantalla por soporte en papel.

Las herramientas de preparación de prototipos son, en sí mismas, mucho más completas, puesto que permiten presentar el conjunto de una aplicación futura antes de una programación en firme. Su único inconveniente, pero en justa medida, reside por último en el tiempo necesario para la elaboración del prototipo.

• P. ¿Existen normas en materia de desarrollo de aplicaciones?

Evidentemente, es totalmente indispensable que se adopte un método en materia de desarrollo de aplicación. En cambio, la cuestión de saber si un método reconocido en el mercado es preferible a las normas «de la casa» es más delicada.

En un entorno de grandes empresas o de administraciones públicas, la elección de un método ampliamente difundido se impone indiscutiblemente. Los métodos como el MERISE, el estándar por antonomasia, o el AXIAL (propuesto por IBM) presentan la ventaja, debido a su amplia difusión, de ser conocidos por gran número de informáticos y, por lo tanto, de poder ser impuestos con facilidad en el seno de la empresa. Presentan, además, la ventaja de un gran rigor, necesario para el desarrollo de proyectos muy importantes (más concretamente, consideraremos como importantes los proyectos cuyo coste global alcanza varias decenas de millones de pesetas).

En las empresas pequeñas o medianas, o bien para proyectos de menor envergadura, los métodos citados anteriormente representan, por lo general, el inconveniente de una carga demasiado elevada. Por ello, no es extraño encontrar en las empresas métodos «caseros». Se imponen entonces en el desarrollo de un proyecto el respeto de ciertas etapas y la formalización de documentos cuyo contenido tipo será predefinido.

Se impondrán, por ejemplo

— El estudio previo. — El pliego de condiciones. — El análisis técnico. — Las normas de programación.

• P. ¿Existen normas en materia de programación?

La existencia de normas de programación es un principio que tiene por


finalidad mejorar la calidad de los programas producidos, en la medida que éstos constituyen una verdadera guía de especial utilidad para los programadores debutantes. Además, conducen a una mejor homogeneidad del conjunto del software de la empresa. Distinguiremos con más exactitud:

• Las normas concernientes a la estructura general de los programas

Los métodos como la programación estructurada, o también WARNIER, proponen una estructura común para el conjunto del software desarrollado. Además, nos daremos cuenta que ciertos lenguajes de desarrollo (lenguajes de cuarta generación, generadores de programas) imponen, de hecho, una estructura de programación.

• Las normas relativas al contenido detallado de los programas

Citamos, por ejemplo:

— los nombres de ficheros; — los nombres de zonas en los ficheros; — los nombres de etiquetas en los programas; — etcétera.

Para poder ser respetadas, las normas de programación serán inscritas en un documento escrito y difundidas al conjunto del personal de estudios.

• P. ¿Se utilizan herramientas del tipo «taller de ingeniería de software»?

El término «taller de ingeniería de software» (TIS) se utiliza, hoy día, para designar funciones muy diversas en el desarrollo de aplicaciones. El producto MAESTRO, de PHILIPS, fue, en los años setenta, el precursor de los TIS de hoy día. Sus funciones en aquella época cubrían principalmente la gestión de las bibliotecas de software de estudios y de explotación y la auto- matización de procesos de puesta en explotación.

Las posibilidades de los TIS son hoy día mucho más amplias puesto que incluyen a menudo, además de las funciones mencionadas anteriormente, la asistencia en el diseño del software, la gestión automatizada de las especificaciones y de la documentación, la generación del software a partir de las especificaciones, etc.

Los TIS se relacionan a menudo con un método de desarrollo, principalmente el MERISE. Sin embargo, nos daremos cuenta que, si bien el TIS del


mañana será con certeza una herramienta totalmente integrada que dará una asistencia al conjunto de las etapas del proceso de desarrollo de la aplica- ción, esto todavía está muy lejos de ser el caso de la mayoría de los TIS disponibles en el mercado, de los cuales las diferentes funciones no están siempre del todo integradas las unas con las otras.

De todas formas, el auditor no podrá, en ningún caso, contentarse con considerar la presencia de un TIS como un punto fuerte y su ausencia como un punto débil. En efecto, un TIS mal utilizado puede ser totalmente inefi- caz, cuando algunas herramientas de desarrollo escogidas con acierto pueden ser suficientes para una excelente productividad del servicio.

Después de enumerar los métodos y herramientas de producción de apli- cación, el auditor deberá entonces pronunciarse sobre sus efectos en término de seguridad y de eficacia del proceso.

• P. ¿Se prevén en el proceso de desarrollo de nuevas aplicaciones las principales fases de puesta en práctica de un proyecto?

Salvo excepciones, ciertas fases deben imperativamente estar previstas en el proceso de introducción de nuevas aplicaciones. Las principales entre ellas son citadas a continuación.

• La formación de los usuarios

Una mala formación de los usuarios tendrá como consecuencia una utili- zación anárquica del sistema, con todos los riesgos que esto comporta, o bien un desinterés, incluso un rechazo, frente a éste. En ambos casos, la apli- cación está condenada a una fase de arranque, en el mejor de los casos, cier- tamente agitada.

• La documentación de la aplicación

El contenido y la calidad de la documentación serán nombrados posteriormente (apartado 3.3).

• La recuperación de los ficheros

El arranque de una aplicación necesita casi siempre la constitución y la entrada exnihilo de los ficheros necesarios para ésta, o bien la recuperación en el nuevo sistema de los ficheros procedentes del viejo, siendo este caso, notablemente, el más frecuente en la actualidad (los nuevos programas sustituyen muy a menudo a una vieja aplicación que tiene un proceso manual).


Estas recuperaciones son con frecuencia delicadas y necesitan una parti- cipación de los usuarios, aunque sólo sea con el fin de confirmar el contenido de los ficheros recuperados.

Una mala previsión de los gastos de recuperación es, así pues, susceptible de comprometer el arranque de la aplicación.

• El impacto del nuevo sistema en la organización y en los procedimientos administrativos

Un nuevo sistema informático va seguido, en la mayoría de los casos, de una reflexión sobre la organización del trabajo, y sobre la aplicación de nuevos procedimientos.

En ausencia de una reflexión de este tipo, es previsible que los procedimientos administrativos sean mal adaptados al sistema de información y no permitan sacar el mejor partido del mismo.

• La implantación física de los equipos

La reflexión sobre el tema permite prever, entre otras cosas:

— La implantación de la o de las unidades centrales (en un sistema bastante descentralizado, encontraremos una unidad central por emplazamiento).

— El número y la localización geográfica de los terminales, pantallas e impresoras.

• La validación del software

Dos métodos complementarios conducen a la validación del software (se habla, a menudo, de «receta») antes de su puesta en explotación.

— Los juegos de prueba, que permiten simular casos reales. Después de los juegos de prueba, diseñados y realizados por los informáticos, que permitirán asegurarse de que los programas están de acuerdo con los pliegos de condiciones, es indispensable prever los juegos de prueba para usuarios, los cuales darán validez a la adecuación de la aplicación a las necesidades y serán, en definitiva, el último control antes del arranque.

— La explotación doble, que consiste en hacer funcionar simultáneamente el software nuevo y el viejo con el fin de comparar los resultados.

Esta última técnica es muy eficaz puesto que la aplicación sustituye los programas que tienen funciones similares. No obstante, es engorrosa ya que


impone a los usuarios una importante sobrecarga de trabajo, como: doble registro, doble control. Así pues, está limitada en el tiempo (por lo general, de uno a tres meses).

Cualquiera que sea el método de validación del software escogido, el auditor comprobará que los usuarios hayan sido partícipes y que hayan tenido la posibilidad de probar las aplicaciones puestas en explotación.

• La seguridad

Si bien la seguridad del sistema de información es primordial en la fase de explotación, un primer acercamiento en ciertos ámbitos es deseable a partir del diseño. Nombremos, por ejemplo, las reflexiones sobre:

— la lista de personas autorizadas a acceder al sistema y las funciones asequibles a cada una de ellas;

— el medio de control de la validez de los procesos: controles de explota- ción, controles de bases de datos, etc;

— el respeto por la aplicación de ciertos principios de control interno: control jerárquico, separación de funciones, continuidad de la vía de revi- sión, etc.;

— los procedimientos de explotación: recuperación en caso de incidente, copias de seguridad, emplazamiento de emergencia, etc.

Volveremos más detalladamente sobre el conjunto de estos puntos a lo largo de la obra.

• P. ¿Se ha llevado a cabo regularmente un seguimiento del avance y de los costes de los proyectos?

Este seguimiento tiene como objeto el control del avance de cada una de las tareas elementales que componen los proyectos, con el fin de detectar lo más rápidamente posible los riesgos de desaciertos en términos de planifica- ción y de costes.

Varios programas de seguimiento de proyecto se encuentran actualmente disponibles para grandes sistemas o, con más frecuencia, para microordenador. De todos modos, un simple tablero puede ser suficiente para un seguimiento eficaz.

Cualquiera que sea la herramienta utilizada, el auditor se preocupará de comprobar que el responsable del proyecto disponga de los medios adecuados para anticipar a tiempo todo tipo de error, a fin de tomar las medidas necesarias.


• P. ¿Son los proyectos objeto de una coordinación suficiente?

Por lo general, el carisma del o de los responsables del proyecto es un factor primordial del éxito del mismo. Para los proyectos más importantes, la coordinación del mismo debe estar formalizada a través de reuniones pe- riódicas (por ejemplo: semanales) de los principales responsables.

En realidad, distinguiremos, para cada proyecto cuya envergadura lo justifique:

• La coordinación entre los equipos de diseño, y posteriormente entre los equipos de realización

Si la amplitud del proyecto justifica una distribución de tareas entre varios equipos, es deseable una coordinación periódica, por ejemplo, a través de una reunión semanal de los grupos de trabajo, a falta de la cual los diferentes subproyectos estarían poco integrados entre sí, además que algunas funciones habrían sido omitidas o tratadas doblemente.

Además, se deben prevenir las fases regulares de validación de los documentos producidos.

• La coordinación entre los equipos de puesta en marcha

Hemos citado antes algunas de las tareas a tener en cuenta en la puesta en marcha de un proyecto informático, tales como: recuperación, organización, formación, etc. Una coordinación general entre estas tareas es indispensable, aunque sea sólo por evitar que algunas de ellas se tornen «críticas» en térmi- nos de plazo.

• La coordinación entre los informáticos y los usuarios

Ya hemos subrayado la importancia de la formación de los usuarios. Ge- neralmente, es necesario prever una información regular de éstos, incluso de los que no participan en el diseño y la puesta en marcha del proyecto.

3.2 LA CALIDAD DEL SOFTWARE

* P. ¿Se procede con regularidad a los controles de calidad del software producido?

Un control por sondeo de los programas producidos, llevado a cabo internamente (afectando, a tiempo parcial, las tareas de control a un miembro del


equipo de desarrollo o del servicio informático), o por medio de terceros, permite entre otras cosas:

— Controlar la calidad de los programas producidos. — Asegurarse de la homogeneidad de estos programas.

• P. ¿Los nuevos colaboradores son objeto de una atención especial?

Esta atención especial se traducirá de diferentes maneras:

• Una formación teórica y práctica

Esta formación será, naturalmente, más o menos intensiva según el nivel de experiencia del colaborador. Siendo una verdadera iniciación para un principiante, se limitará a una formación en los métodos «de la casa» para un marco definido.

La formación teórica será completada de forma útil por una formación más práctica, bajo formas diversas, a saber: «padrinazgo» de los recién lle- gados, paso por diferentes equipos, etc.

• Un control de actividad reforzado

Una experiencia insuficiente del programador está a menudo en el origen de programas complejos y consumidores de tiempo de máquina. Desgracia- damente, en ausencia de un seguimiento eficaz, sólo nos daremos cuenta de estos errores de juventud demasiado tarde, cuando nuestro programador inexperto tenga ya realizados varios programas, los cuales le será imposible reescribir. Un control sistemático de los primeros programas escritos por cada nuevo programador permite reducir este riesgo y «corregir la puntería» inmediatamente.

• P. ¿Es satisfactoria la calidad de los programas producidos por el estudio?

¡Por más formalizados que sean, los métodos y las normas de desarrollo y de programación no pueden constituir una garantía absoluta de la calidad de los programas, porque no será la existencia de las normas la que garantice que éstas sean respetadas!

Por consiguiente el auditor pondrá todo su interés en llevar a cabo un control, por sondeo, de la calidad y del respeto a las normas en algunos programas.


3.3 LA DOCUMENTACIÓN

• P. ¿Es satisfactoria la calidad de la documentación producida?

Distinguimos en la documentación de una aplicación informática:

— La documentación de estudio, destinada a los equipos de desarrollo y de mantenimiento.

— La documentación de explotación, destinada al personal de producción. — La documentación destinada a los usuarios.

• La documentación de estudio contiene entre otras cosas: — La descripción del contenido de los ficheros. — La descripción de las cadenas de proceso. — La descripción detallada de los programas. — El historial de las operaciones de mantenimiento.

• La documentación de explotación contiene el conjunto de las informaciones y consignas necesarias al personal de producción:

— Descripción y organigrama de las cadenas de proceso. — Instrucciones para la preparación. — Descripción de los controles de la explotación a ser llevados a cabo en el

momento de cada proceso. — Instrucciones sobre la consola.

• La documentación para usuarios contiene: — La descripción general de las aplicaciones. — La descripción de las transacciones. — La descripción de los listados editados. — La explicación de los mensajes de anomalías.

Para el auditor, además de la calidad y de la cantidad de la documen-

tación, tendrá importancia la flexibilidad de utilización de la misma. Por lo tanto, una documentación controlada por soporte magnético, con la ayuda de un programa previsto para esta finalidad, facilitará en gran medida la puesta al día y permitirá la salvaguarda en un emplazamiento externo.

De un modo general, el auditor igualmente se preocupará de asegurarse de que la documentación esté al día. Por más completa que sea, ésta se torna, de hecho, rápidamente inutilizable si no se reflejan en ella de forma inmediata las operaciones de mantenimiento.


La ausencia de la actualización regular de los dossieres es tanto más la- mentable cuanto que hace caducar en algunos meses el pesado trabajo inicial de construcción de los mismos.

Más concretamente, el auditor podrá operar este control partiendo de las últimas fichas de mantenimiento de programa, y controlando que las modificaciones correspondientes hayan estado bien reflejadas sobre la documenta- ción.

3.4 EL MANTENIMIENTO

• P. ¿Qué procedimientos de mantenimiento de software se formalizan?

Las peticiones de mantenimiento de los programas deben ser formaliza- das y ser objeto de una petición escrita por parte de los servicios de usuarios, visada por el correspondiente interesado y pasada al responsable de estudio. Éste, después de dar su conformidad, se encargará de transferirla al jefe de proyecto correspondiente. Los programas modificados son probados en el entorno del estudio antes de ser enviados a explotación.

En caso de urgencia, y en particular si la operación tiene por finalidad la corrección de una anomalía de diseño de los programas, podrá ser perfectamente derogada la exigencia de una petición por escrito. De todos modos, incluso en este caso, el servicio informático redactará una ficha describiendo la modificación aportada a los programas.

Además, de una forma general, el conjunto de fichas de mantenimiento relativas a una aplicación son archivadas en el dossier de ésta.

3.5 LOS PROCEDIMIENTOS DE PUESTA EN EXPLOTACIÓN DEL SOFTWARE

Este tema, que toca a la vez el entorno de estudio y el de explotación, se abordará en el próximo capítulo.


Capítulo 4

El entorno de producción

4.1 LOS PROCEDIMIENTOS DE PUESTA EN EXPLOTACIÓN

• P. ¿Son satisfactorios los procedimientos de puesta en explotación del software?

Antes de imaginar un procedimiento «ideal» de puesta en explotación de los programas, conviene definir los principales objetivos de un buen control interno en este campo.

• El procedimiento de puesta en explotación debe garantizar una buena separación entre las funciones de estudio y las de explotación

Concretamente, el personal de estudio no debe tener acceso a las bibliotecas de programas de explotación, como tampoco a los ficheros de explota- ción. Este objetivo, además, tiene como propósito más bien prevenir los riesgos de error de manipulación que los riesgos de operaciones fraudulentas por parte del personal de estudio.

• El procedimiento de puesta en explotación debe, en todo momento, garantizar que estén disponibles en las bibliotecas los programas fuente correspondientes a los programas objeto en explotación

¡Atención!: el programa «fuente» es el programa escrito por el informá- tico en un lenguaje evolucionado y comprensible por el ser humano, el pro-

El entorno de producción 63

grama «objeto» es el lenguaje compilado, o sea, transformado en código bi- nario directamente ejecutable por la máquina. El lenguaje objeto, casi ilegible por el ser humano, se conserva en máquina:

— Por un lado, el programa fuente, en una biblioteca de programas fuente, que será modificada, después compilada, en caso de operación de mantenimiento de aplicación.

— Por otro, el programa objeto, listo para ejecución, en una biblioteca de programas objeto; en realidad, y más precisamente, algunos programas objeto deben ser conectados los unos a los otros antes de ejecutarlos. Se trata de la fase de edición relacionada (linkedit) que transforma los mó- dulos objeto en módulos ejecutables (load-modules).

En ausencia de programas fuente, o bien en presencia de programas fuente no compatibles con los programas objeto en ejecución, el mantenimiento de la aplicación será imposible a corto plazo.

• El procedimiento de puesta en explotación debe permitir conservar el historial de traslado de programas en el entorno de explotación

Este historial permitirá entre otras cosas:

— Elaborar estadísticas tales como: puestas en explotación por programa, cantidad de mantenimientos por programa y por aplicación, etc.

— Efectuar búsquedas, si fuere necesario, en caso de accidente, sobre la fecha de las últimas modificaciones de un software.

Si es posible, durante el proceso se tendrá en cuenta guardar la penúltima versión de todo programa en explotación, con el fin de facilitar una «vuelta atrás» en caso de anomalías de proceso en la última versión.

* * *

Aclarados estos objetivos, veremos a continuación, extraídos de la obra Les techniques de l'organisation informatique, las grandes líneas de un procedimiento de puesta en explotación «ideal».

El equipo de desarrollo trabaja en un entorno de prueba y utiliza para este fin la biblioteca de programas de comprobación, en particular una biblioteca de programas fuente (que llamaremos BIB.TEST.FUENTE) y una biblioteca de programas objeto, compilados (que llamaremos BIB.TEST.OB- JETO).


En el entorno de explotación es evidentemente necesario manejar una biblioteca de programas objeto, ejecutables (que llamaremos BIB.EXPL.OBJETO).

Por otro lado, se conservará una copia de los programas fuente en una biblioteca de entorno de explotación, que llamaremos BIB.EXPL.FUENTE.

El procedimiento de puesta en explotación de un programa PGM, esque- matizado en la figura 2, será el siguiente:

a) El programa fuente se transfiere del entorno de prueba al de explotación, bajo control del personal de explotación.

b) El programa fuente es recompilado en el entorno de explotación.

Figura 2. Procedimiento de puesta en explotación.


Eventualmente, el programa fuente y el programa objeto pueden ser des- truidos en el entorno de prueba. En el caso de operaciones de mantenimiento posteriores, el programa de comprobación será devuelto del entorno de ex- plotación al de prueba. Entonces, después de la realización y comprobación de las modificaciones del software, el programa fuente corregido será trans- ferido y recompilado en el entorno de explotación.

Además, la versión precedente será generalmente conservada de manera que se disponga, para cada programa, de la última y de la penúltima versión de los módulos fuente y objeto.

Tratándose de la aplicación práctica de este procedimiento, se pueden su- poner las modalidades siguientes:

— El responsable de la aplicación prepara su petición en un fichero de peticiones de traslado.

— Periódicamente, el responsable de los traslados revisa el fichero de peticiones y procede a la ejecución de estos traslados.

— Un fichero histórico de traslados se actualiza. Si fuere necesario se podrá saber de este modo el plazo de las puestas en explotación por programa, por aplicación, por peticionario, por orden cronológico, o según cualquier otro criterio.

4.2 LOS PROCEDIMIENTOS DE TOMA DE DATOS

Recordemos a continuación que la toma de datos puede realizarse:

— En tiempo diferido, a partir de impresos rellenos por los servicios de usuarios en los equipos dedicados a la recogida de datos; la toma conocida como «masiva» está también asegurada por las «perforadoras verificadoras» en los «talleres de toma de datos» especializados en esta función; los talleres de entrada de datos están, hoy día, en vías de desapa- rición, pero todavía se justifican en algunos casos particulares.

— En tiempo real, es decir, con actualización inmediata de los ficheros. La entrada está también asegurada ya sea directamente por los usuarios, o bien por los servicios que aseguran una toma masiva «inteligente». Así pues, en tema comercial, los pedidos serán recogidos, según sea el caso, por los mismos vendedores, por sus secretarias (por ejemplo, cada día después de la centralización de los pedidos del día), o también por un servicio de administración de ventas. De la misma forma, en un establecimiento financiero, las operaciones en el mercado serán registradas,


bien por los mismos operadores, o bien por un servicio de registro y control en el seno de un middle office o de un front office.

• P. Los principios de un buen control interno, ¿ se respetan en el software de toma de datos?

Los principales elementos de un buen control interno de los procedimientos de toma de datos son:

— Cuando la entrada se realiza partiendo de un impreso, la existencia de un visto bueno de una persona autorizada controlado por el personal de in- troducción.

— La doble introducción (únicamente en el caso de introducciones masivas en tiempo diferido).

— La existencia de claves de control para los códigos numéricos. Los errores de introducción del código también serán rechazados inmediatamente.

— El control por totalización de los lotes de introducción, que comprueba que todo documento haya sido introducido una única vez con los importes exactos.

— El control de la existencia en la mesa o en el fichero de los códigos introducidos.

— Los controles de compatibilidad (ejemplo: control de compatibilidad del día, del mes y del año en la introducción de una fecha); en algunos casos, la introducción de datos redundantes será voluntariamente prevista con la finalidad de control [ejemplo: entrada, en una factura, del importe sin impuestos (A), del IVA (B) y del importe total (C). El programa de intro- ducción comprueba que C = A + B].

— La visualización para validación desde la introducción del texto correspondiente (sólo en caso de introducción interactiva) al código introducido: por ejemplo, en el momento del registro de una factura de proveedor, el nombre del proveedor se fija a partir del código de proveedor registrado.

— La edición para análisis eventual de la lista exhaustiva de los datos registrados y, si fuere el caso, de una lista por exclusión de los datos más «significativos».

* * *


Por lo general, el auditor comprobará que los procedimientos de registro garanticen:

— que todo dato que deba ser introducido, lo sea de verdad (principio de exhaustividad);

— que no sean introducidos datos que no lo debieran ser (principio de realidad);

— que los datos introducidos no tengan errores (principio de exactitud).

Volveremos posteriormente sobre los controles propios de los procedimientos de autorización.

4.3 LA EJECUCIÓN DE LOS PROCESOS EN TIEMPO DIFERIDO

• P. ¿La ejecución de trabajos en tiempo diferido es objeto de una planificación?

La planificación de la ejecución de los procesos es un principio básico de una organización racional. En su ausencia, el ordenador se puede encontrar saturado en ciertos períodos (de donde surgen los retrasos en la distribución de los resultados) y bloqueado en otros.

Además, una planificación sistemática permite comprobar con facilidad que sólo los procesos planificados y autorizados hayan sido ejecutados.

Los programas de asistencia a la planificación y al ordenamiento de los trabajos están disponibles hoy día en el mercado (principalmente, para los más completos, pertenecientes a los grandes sistemas) y gracias a los cuales:

— Todo proceso ejecutado sin planificación, o bien se rechaza, o bien se pone en evidencia para ser controlado.

— Los inconvenientes del encadenamiento de trabajos son puestos en pará- metros, evitando, de esta forma, algunos errores relacionados con los arranques manuales (trabajo olvidado o, por el contrario, ejecutado doblemente, trabajos ejecutados en una mala secuencia, etc.).

En primer lugar, estos programas permiten a los preparadores (o, con más frecuencia, a los responsables de aplicación), «poner parámetros» durante el día a los trabajos que serán ejecutados por la noche bajo control único de los teclistas.


• P. ¿Se asume de manera satisfactoria la Junción de preparación de los trabajos?

Citemos, como principales características de una organización que cum- pla la función de preparación de los trabajos:

• La calidad de la documentación destinada a los responsables de la preparación: la calidad de la documentación es, por supuesto, la condición sine qua non de la calidad del trabajo de preparación por parte de los responsables de la aplicación.

• El carácter de intercambiabilidad de los responsables de apli- cación: si bien no es deseable que cada responsable de aplicación asuma a veces la responsabilidad de la preparación del conjunto de las cadenas de proceso (lo que conduciría a una dispersión muy grande), es necesario por lo menos, que varios responsables sean capaces de asegurar la preparación de cada cadena, de manera que las vacaciones, la enfermedad o la partida de uno de ellos no se transforme en el origen de todos los peligros.

• La calidad de los JCL: los JCL (Job Control Language) de explotación eficaces reducen muchísimo los riesgos de errores de explotación al limitar al mínimo estricto el número de parámetros a ser modificados en el momento de cada explotación.

Los JCL, por lo general, son modificados por los responsables de aplica- ción en el momento de la puesta en explotación de una nueva cadena de proceso, con la preocupación de optimizar las actuaciones de explotación, que no siempre tienen los equipos de desarrollo.

Además, las herramientas de automatización de la explotación (genera- ción automática de los JCL, gestión de recuperación, gestión de las gene- raciones sucesivas de un mismo fichero, gestión de las copias de seguridad, etc.) participan de forma notable en la reducción del número de los paráme- tros de explotación.

• P. ¿Las cadenas de proceso son sistemáticamente objeto de controles a posteriori?

Podemos distinguir entre los controles de una cadena de proceso:

— Los controles sobre la coherencia técnica de la explotación. — Los controles sobre la coherencia funcional de la explotación.


• Los controles sobre la coherencia técnica

Estos controles llevan, por ejemplo:

— A las cantidades de registros procesados. — Al contenido de las bases de datos. — Al buen fin de los procesos (por el análisis de los mensajes y los indica-

dores de fin de proceso). — A la coherencia de los listados editados.

Un buen número de estos controles pueden, además, ser informatizados en gran medida, ya sea por la creación de «codificadores numéricos» auto- máticos, o bien por la utilización de programas existentes en el mercado, en particular para el control del buen fin de los procesos.

• Los controles sobre la coherencia funcional de la explotación

Si bien es absolutamente deseable que estos controles sean llevados a cabo por el servicio informático, en la práctica, hace varios años, hay una tendencia a transferir la responsabilidad a los servicios destinatarios.

La razón principal radica en la imposibilidad ante la cual se encuentran los servicios informáticos para definir y realizar los controles funcionales pertinentes.

Lo cual no quiere decir que estos controles de coherencia funcional re- vistan una importancia primordial.

• P. ¿Están claramente definidas las modalidades de recuperación de la explotación de la cadena en caso de incidente?

La principal preocupación en este campo debe ser evitar que los teclistas tengan que tomar iniciativas en cuanto al proceso de los incidentes, en la medida en que no conocen las cadenas en explotación y donde la definición de las modalidades de recuperación tampoco es de su incumbencia.

En los grandes centros de proceso, los sistemas de explotación permiten, por lo general, la total automatización de los procedimientos de recupera- ción consecutivos en la mayoría de los incidentes. Cuando una recuperación automática se hace imposible, es preferible, salvo en casos de urgencia, abandonar el proceso y esperar la decisión del responsable de la producción de la aplicación (es decir, diferir la decisión hasta la mañana siguiente para los turnos de noche).

Para los sistemas pequeños, a menudo, no se contempla una automatiza- ción total de las recuperaciones. Para las situaciones de urgencia, y en el


caso de ausencia del responsable de aplicación, estará previsto proporcionar al teclista un manual de explotación que describa exactamente el procedimiento de recuperación a seguir.

4.4 EL CONTROL DE SUPERVISIÓN DEL ENTORNO DE PRODUCCIÓN

* P. ¿Existen herramientas de control y de asistencia destinadas a los teclistas?

Si bien en los grandes centros los teclistas trabajan sistemáticamente en equipo, no ocurre siempre lo mismo en los pequeños. En algunos casos, los trabajos no urgentes son iniciados y ejecutados por la noche en ausencia de cualquier presencia humana (a excepción, si es posible, de los guardias de seguridad o bomberos). En caso de incidente, los trabajos se interrumpen y se vuelven a iniciar la mañana siguiente.

Además, en los grandes centros hay cada vez más herramientas de control y asistencia al trabajo de los teclistas: prohibición de transmitir ciertos pedidos, respuestas automáticas al ordenador, etc.

Esta automatización permite enfocar la actividad de los teclistas hacia tareas más delicadas, en particular el tratamiento de algunos tipos de incidentes. Correlativamente, la automatización es acompañada siempre en los grandes centros de una centralización de funciones de tecleado, con la crea- ción de equipos que tengan la responsabilidad simultánea de varias unidades centrales.

4.5 EL CONTROL DE LA CALIDAD, DE LA PRODUCCIÓN INFORMÁTICA

• P. ¿Hay un seguimiento de la calidad de las prestaciones suministradas ?

Este seguimiento asume formas variadas:

— Disponibilidad de la máquina y de la red. — Tiempo de respuesta de las aplicaciones interactivas. — Frecuencia de incidentes por software.


— Frecuencia de retrasos en la distribución de los listados, y retraso medio constatado.

— Cantidad de operaciones de mantenimiento por aplicación. — Etcétera.

• P. ¿Existe un seguimiento destinado a optimizar las actuaciones del sistema informático?

Este seguimiento asume también formas variadas:

— Tasa de carga de la unidad central. —- Tasa de llenado de los discos. ., — Frecuencia de las entradas-salidas. — Seguimiento del tiempo de proceso por software de aplicación. — Seguimiento de la utilización de la red. — Etcétera.

• P. ¿Se edita y archiva sistemáticamente el «diario de a bordo» del (de los) ordenador(es)?

Recordamos que este diario de a bordo (printlog) describe en una forma más o menos detallada (parametrable), el historial de las órdenes dadas al sistema de explotación y los mensajes recibidos de éste.

Cada mensaje viene de esta manera a alimentar un fichero, que podrá ser utilizado con fines de búsqueda después de cualquier incidente de explo- tación.

El auditor comprobará en particular:

— que el tamaño del fichero permita contener el historial de los mensajes durante un período suficientemente largo (que comprenda de uno a varios días);

— que el «diario de a bordo» sea objeto de salidas en papel, archivadas igualmente durante un período que sea suficientemente largo (algunos meses).

Una recomendación, formulada a menudo por los auditores, de que el diario sea regularmente objeto de controles por sondeo, por parte del jefe de sala por ejemplo, parece relativamente poco realista teniendo en cuenta el volumen de este documento.


4.6 LA GESTIÓN DEL ESPACIO EN DISCO

• P. ¿Se realiza regularmente un análisis del contenido de los discos para suprimir ficheros inútiles?

La proliferación en el espacio del disco de ficheros totalmente inútiles constituye un síndrome común a casi todos los centros de proceso.

Es, por lo tanto, indispensable que se lleven a la práctica procedimientos que permitan reconocer estos ficheros inútiles. Citemos por ejemplo:

— El censo periódico con los jefes de proyecto y los responsables de pro- ducción de aplicación de todos los ficheros operativos.

— La eliminación automática de los ficheros cuyo nombre no respeta una estructura definida previamente.

Los programas de gestión automatizada del espacio en disco permiten en particular luchar contra esta proliferación de ficheros inútiles.

* P. ¿La implantación de los ficheros en los discos es objeto de una optimización?

En efecto, una optimización de la implantación física de los ficheros en los discos permite:

— Disminuir el tiempo de ciertos procesos, ya sean interactivos o en tiempo diferido.

— Mejorar la seguridad.

4.7 LA GESTIÓN DE LAS BIBLIOTECAS DE PROGRAMAS

Ya hemos mencionado, por medio de los procedimientos de puesta en ex- plotación (apartado 4.1), la gestión de las bibliotecas de programas. Nos limitaremos a mencionar aquí algunos objetivos de una gestión sana:

— Conservar en las bibliotecas sólo los programas efectivamente utilizados. — Tener la seguridad de que están disponibles en las bibliotecas todos los

programas fuentes correspondientes a los programas objetivo utilizados. — Dar al personal de estudio y de producción un máximo de procedimien-

tos automatizados de gestión de las bibliotecas (puesta en explotación,


traslado de un programa del entorno de producción al entorno de prueba, etc.). — Prohibir al personal no autorizado la entrada a las bibliotecas.

4.8 LA GESTIÓN DE LAS COPIAS DE SEGURIDAD

Nota previa: el soporte físico de la copia de seguridad no tiene ninguna incidencia particular en la política general. Las cuestiones siguientes se aplican entonces indistintamente a las copias de seguridad en cintas o en cartucho.

Si bien la finalidad de las copias de seguridad es fácilmente comprensible, las modalidades prácticas son a menudo bastante diferentes de un emplazamiento a otro. Así, esto se debe a que éstas dependen del tamaño del centro, de los volúmenes de información a salvaguardar y de los sistemas de explotación propuestos por el fabricante.

Cualesquiera que sean los procedimientos a aplicar, el auditor se encar- gará de comprobar que éstos satisfagan los objetivos básicos de una buena política de salvaguarda, a saber:

— Permitir volver a arrancar todas las cadenas de proceso en caso de fallo (ejemplo: reempezar con un turno interrumpido por un falta de fluido eléctrico, o incluso por un fallo de software).

— Permitir corregir un fallo en un soporte físico (ejemplo: un incidente en un disco lo hace ilegible y obliga a su sustitución física, además de la recarga de su contenido a partir de una copia de seguridad).

— Permitir arrancar de nuevo en un emplazamiento exterior en caso de des- trucción total del emplazamiento de producción.

— Responder a las obligaciones legales en materia de archivo, o sea: obligaciones comerciales, contables y fiscales.

• P. ¿Se salvaguarda regularmente el conjunto del software y ficheros necesarios para el desarrollo y la explotación?

Imperativamente deben ser salvaguardados:

— El software básico. — Los ficheros y software de aplicación del entorno de explotación. — Los ficheros y software de aplicación del entorno de estudio.

La diversidad de los tipos de incidentes que las copias de seguridad de-


ben poder paliar tiene como consecuencia la necesidad de combinar diferentes métodos de salvaguarda.

De este modo, asociamos, por lo general, las copias de seguridad totales de los soportes físicos (copia total de cada volumen de disco), destinadas a responder ante una destrucción de estos soportes, a las copias de seguridad selectivas por naturaleza funcional de las informaciones almacenadas (copia de cada fichero y de cada biblioteca), destinadas a dar respuesta a las necesidades más localizadas, como por ejemplo: recuperación de una cadena de proceso, recarga de una biblioteca, etc.

Además, tratándose de copias selectivas de los ficheros y de las bibliotecas, los sistemas de explotación proponen la mayoría de las veces, con el fin de reducir la duración de esta operación, una función de copia de seguridad únicamente de las informaciones modificadas; por ejemplo, preveremos, a intervalos regulares, copias de seguridad completas de cada fichero y, entre éstas, un historial de las modificaciones.

• P. ¿Permiten las copias de seguridad resolver en un plazo satisfactorio todos los tipos de fallos?

Ilustraremos esta pregunta a través de diferentes ejemplos de una mala política de salvaguarda.

• Los ficheros y bibliotecas se salvaguardan totalmente una vez por mes, y, dentro del período, todas las modificaciones son incluidas en el historial

Esta política es mala pues, para los ficheros y bibliotecas que se modifican a menudo, la reconstrucción de la situación en el momento de un fallo (en particular cuando éste surge justo antes de una salvaguarda total) será ex- cesivamente larga.

• Todas las copias de seguridad se realizan por medio de un soporte fí- sico y no hay ninguna copia selectiva de los ficheros

En esta hipótesis, en el caso de un incidente en una aplicación dada, la re- construcción de uno o varios ficheros será algunas veces larga, ya que necesita la recarga previa de un disco completo.

• Sólo hay copias de seguridad selectivas de ficheros y de bibliotecas y ninguna copia total por medio de soporte físico

Es aquí donde, en caso de necesidad de reconstrucción de un soporte fí-


sico (después de la destrucción de éste o después de la destrucción total del emplazamiento), la carga de trabajo será considerable.

• P. ¿Cuándo el acervo lo justifica, hay un software de gestión de cintas (o de cartuchos)?

La gestión del acervo de cintas (o de cartuchos) magnéticos no supone ningún problema especial en los pequeños centros de proceso. Las cintas son poco numerosas, y además están marcadas y clasificadas con la finalidad de salvaguardarlas. Una gestión de este tipo es totalmente impensable en los grandes centros, donde los soportes deben ser numerados y clasificados en orden correlativo. El gestor del acervo de cintas, por lo general, con la ayuda de un programa, establecerá la correspondencia entre la referencia numé- rica de las cintas, su naturaleza y su localización geográfica de almacenamiento.

El programa debe asegurar entre otras cosas:

— La gestión de los lugares de almacenamiento, según un parámetro inicial (por ejemplo, para todo fichero, la versión V se encontrará en el emplazamiento y será transferida a un emplazamiento externo transformán- dose en la versión V-l, tornándose la vieja versión V-l sin interés).

— La banalización de las cintas que contienen los ficheros inútiles. — El control de acceso a las cintas que contengan ficheros activos (y la

prohibición de cualquier modificación de éstas).

El auditor podrá en primer lugar comprobar por sondeo:

— que toda cinta indicada en el programa esté bien colocada en el sitio geo- gráfico de almacenamiento previsto (y, si fuere el caso, que el nombre y la versión del fichero contenido en la cinta sean exactamente los indicados);

— que toda cinta presente físicamente esté bien marcada en el programa.

• P. ¿Responde la gestión de las copias de seguridad a las obligaciones en materia de archivo?

En el cuadro siguiente, se incluye una copia del artículo 97-1 de la Ley de Finanzas Francesa para 1982 y del artículo 103 de la Ley de Finanzas para 1990. Estas disposiciones implican para la empresa la obligación de conservar durante el período fiscal no prescrito una copia de «las informaciones, datos o procesos» que concurran «directa o indirectamente en la formación de los resultados contables y fiscales del período verificado o en la prepara-


ción de los documentos o declaraciones considerados obligatorios por la normativa fiscal».

No obstante, dejaremos que cada auditor se preocupe de definir caso por caso cuáles podrían ser estas copias. Nos limitaremos a subrayar que se trata, en principio, del conjunto de los ficheros y del software que hayan tenido una incidencia contable, incluso indirecta, sobre el período no prescrito. Por tanto, el campo es amplio.

ALGUNAS DISPOSICIONES FISCALES EN MATERIA DE COPIAS DE SEGURIDAD EN FRANCIA

■ El artículo 97-1 de la Ley de Finanzas para 1982, que completa el ar- tículo 54 del Código General de los Impuestos, es aplicable a las empresas afectadas por el régimen de beneficio real.

«Cuando la contabilidad está establecida por medio de sistemas informatizados, el control se extiende a la documentación relativa a los análisis, a la progra- mación y a la ejecución de los procesos. Con el fin de comprobar la fíabilidad de los procedimientos de proceso automatizados de la contabilidad, los agentes de hacienda pueden llevar a cabo comprobaciones de control en el equipo utilizado por la empresa cuyas condiciones serán definidas por decreto»

• El decreto ir 82-1142 del 29 de diciembre de 1982 precisa las condiciones de realización de los controles.

«Art. 1º- Cuando las comprobaciones de control previstas por el artículo 97-1 de la Ley de Finanzas para 1982 se realizan en el equipo utilizado por la empresa inspeccionada, las fechas y las horas de intervención se fijan de forma que sean compatibles con el funcionamiento normal del sistema informáti- co de la empresa y con el ejercicio del derecho de control de la administración.

Sin embargo, si la empresa lo desea, podrá pedir a los agentes de hacienda, cuando éstos lo acepten, que le permitan entregar la copia de las informaciones y del software utilizados por ella. Las copias son hechas en un soporte informático suministrado por la empresa y respondiendo a las normas que se- rán fijadas por decreto.

«Art. 2º.- Las comprobaciones previstas en el artículo 1Q llevan en las informaciones, datos y procesos automáticos de cualquier tipo a partir del momento en que estas informaciones, datos o procesos concurren directa o indirectamente en la formación de los resultados contables y fiscales del período verificado o en la confección de los documentos o de las declaraciones consideradas obligatorias por el Código General de los Impuestos. Estas informaciones están protegidas por el secreto fiscal.

Art. 3º.- Las comprobaciones y los trabajos de copia previstos en el ar- tículo lº son realizados por parte del personal habilitado de la empresa o por el consejero que haya nombrado, bajo el control de los agentes de hacienda.

Art. 4º.- Cuando la empresa utiliza para todos o parte de sus procesos automáticos los servicios de un detallista o de un suministrador externo, ten-


drá la obligación de permitir a los agentes de hacienda llevar a cabo en el domicilio del detallista o del suministrador externo las comprobaciones que esti- men necesarias para el ejercicio del derecho de verificación. Estas comprobaciones se llevan a cabo en las condiciones definidas en el artículo 1º del presente decreto, incluso en lo que concierne a la posibilidad para los suministra- dores o detallistas de suministrar copias de las informaciones y del software.»

• El artículo 103 de la Ley de Finanzas para 1990 modifica el artículo L 13 del libro de los procedimientos fiscales.

«Art. 103 - Texto del artículo. - I. El artículo L 13 del LPF se completa por un apartado redactado así:

«Cuando la contabilidad es llevada por medio de sistemas informatizados, el control se produce sobre el conjunto de las informaciones, datos y procesos informáticos que concurren directa o indirectamente en la formación de los resultados contables o fiscales y en la elaboración de las declaraciones consideradas obligatorias por el CGI así como sobre la documentación relativa a los análisis, a la programación y a la ejecución de los procesos.»

II. El artículo L 82 del LPF está abolido.

III. Va insertado después del artículo L 102 A del LPF un artículo L 102 B redactado como sigue:

«Art. L 102 B: los libros, registros, documentos o piezas sobre los cuales se puedan ejercer los derechos de comunicación y de control de la administra- ción deben ser conservados durante un período de seis años a contar de la fecha de la última operación mencionada sobre los libros o registros o de la fecha en la cual los documentos o piezas fueron establecidos.

Sin perjuicio de las disposiciones del apartado primero, cuando los libros, registros, documentos o piezas mencionadas en el apartado primero son apo- yados o recibidos en soporte informático, deben ser conservados bajo esta forma durante un período por lo menos igual al plazo previsto en el artículo L 169.

Las piezas justificativas de origen relativas a las operaciones que dan derecho a una reducción en materia de impuestos sobre la cifra de negocio se conservan durante el plazo previsto en el apartado primero.

Cuando no estén previstos en los apartados precedentes, las informaciones, datos o procesos sometidos al control previsto en el apartado segundo del ar- tículo L 13 deben ser conservados en soporte informático hasta el agotamiento del plazo previsto en el artículo L 169. La documentación relativa a los análisis, a la programación y a la ejecución de los procesos debe ser conservada hasta ha- berse cumplido el tercer año después del que corresponde la misma.»

IV. Le sigue al artículo L 47 del LPF un artículo L 47 A redactado como sigue:

— Art. L 47 A: cuando la contabilidad se lleva por sistemas informatizados, los agentes de la administración fiscal pueden efectuar la verificación sobre el equipo utilizado por el contribuyente.

Este puede solicitar para efectuar él mismo todos o parte de los procesos informáticos necesarios para la verificación. En este caso, la administración aclara por escrito al contribuvente o a un representante designado a este efec-


to, los trabajos a ser realizados y el plazo acordado para llevarlos a cabo. El contribuyente puede igualmente solicitar que el control no sea efectua-

do sobre el material de la empresa. Pone entonces a disposición de la admi- nistración las copias de los documentos, datos y procesos sometidos a un control.

Estas copias serán hechas en un soporte informático suministrado por la empresa, respondiendo a las normas fijadas por decreto.

Al contribuyente se le informa de los nombres y direcciones administrati- vas de los agentes por los cuales, o bajo control de los cuales, las operaciones son llevadas a cabo.

Las copias de los documentos transmitidas a la administración no deben ser reproducidas por esta última y deben ser restituidas al contribuyente antes del cobro.»

V. Va insertado después del primer párrafo del artículo L 57 del LPF, un párrafo redactado así:

«En caso de aplicación de las disposiciones del artículo L 47 A, la adminis- tración aclara al contribuyente la naturaleza de los procesos llevados a cabo.»

VI. El artículo L 74 del LPF se completa con el siguiente párrafo: Estas disposiciones se aplican en caso de oposición a la aplicación del control en las condiciones previstas en el artículo L 47 A.

VII. El párrafo tercero del artículo 54 del CGI está abolido.

• P. ¿Se llevan a cabo copias de seguridad en emplazamientos externos?

Un día, durante una auditoría, yo mismo insistía ante un responsable de informática que guardaba el conjunto de sus copias de seguridad en una caja fuerte ignífuga: «¿Pero, qué haría Vd. en caso de riesgo de destrucción de su armario, por ejemplo en caso de explosión violenta?». Este responsable in- formático, un técnico excelente, me dio una respuesta bastante apabullante: «¡Exactamente, su pregunta llega en el momento preciso. Hemos tenido un aviso de bomba la semana pasada; como me he dado cuenta en seguida de que se trataba de una broma, no hice nada, pero, si hubiera tenido la menor duda me hubiera ido corriendo de la sala de máquinas para recuperar todas las cintas de la caja fuerte!».

Una gran mayoría de los responsables informáticos reconocerán de buen grado que, para evitar tener que tomar decisiones tan valientes como ésta, es preferible que haya, en un emplazamiento externo, una copia de todos los ficheros y programas necesarios para un back-up en caso de destrucción del emplazamiento de producción.


No obstante, seremos menos exigentes en lo que respecta a la fecha de la copia; y se admitirá, por lo general, que se encuentren en el emplazamiento externo las copias de algunos días, incluso de una semana, anteriores. En caso de siniestro importante, el hecho de tener que repartir los ficheros que se encuentren en estos soportes, y luego de perder algunos días en el registro de datos no será en sí más que un mal menor. En cambio, si son necesarias varias cintas para el arranque, la coherencia entre ellas, los ficheros y las bibliotecas contenidas en estas cintas es primordial.

4.9 LOS PROCEDIMIENTOS DE RECUPERACIÓN EN EMPLAZAMIENTOS EXTERNOS (BACK-UP)

• P. ¿Está previsto un procedimiento que permita en un plazo satisfactorio un nuevo arranque en otro emplazamiento?

Si bien la noción de plazo satisfactorio puede parecer estar relacionada a un «determinado tiempo», sin embargo, no es posible aclarar bien esta idea. En algunas actividades, será indispensable reactivar en las 24 horas, en otros casos el plazo de 15 días será del todo aceptable.

Entre las principales medidas destinadas a preparar un eventual back-up, podemos nombrar:

— El contrato de back-up con una sociedad especializada. — La «sala blanca», sala vacía, equipada con anterioridad para las teleco-

municaciones y lista para recibir los materiales de urgencia en caso de necesidad.

— El contrato de asistencia con empresas que dispongan de equipos similares. — El montaje en común de un emplazamiento de urgencia entre varias em-

presas. — Y por último, la solución que está en auge, la existencia dentro de la em-

presa de dos emplazamientos alejados el uno del otro, en que cada uno es capaz de asumir el back-up del otro, por medio de la aplicación de procedimientos deteriorados.

No olvidemos por último que, en nuestros días, un plan de recuperación serio implica que haya sido previsto cuidadosamente el back-up de la red de telecomunicaciones.


• P. Cuando la recuperación en un emplazamiento externo implica la aplicación de procedimientos deteriorados, ¿han sido definidos éstos?

Es muy extraño que el emplazamiento de urgencia permita «procesar» las aplicaciones en las mismas condiciones que el emplazamiento inicial. Resulta, por tanto, indispensable definir las aplicaciones y los usuarios prio- ritarios, es decir, los procedimientos de funcionamiento en modo «dete- riorado».

• P. ¿Los procedimientos de recuperación en un emplazamiento externo son comprobados con regularidad?

Sólo el test «tamaño natural» de las recuperaciones detectará las imperfecciones del procedimiento teórico: memoria central insuficiente, ficheros no salvaguardados, usuarios no conectados, etc.

4.10 LA SEGURIDAD FÍSICA

Sólo citaremos aquí las características esenciales del control de la seguridad física del centro de proceso, que es objeto de largos desarrollos en la lite- ratura.

• P. ¿Está protegido el acceso físico al entorno informático?

En los grandes centros de proceso, la sala en la cual están situadas las unidades centrales, discos y otros equipamientos sensibles, está libre de toda presencia humana. Por lo demás, el acceso a los espacios de trabajo de los equipos de producción (teclistas, operadores, responsables de producción de aplicación, jefes de salas, etc.) está estrictamente reglamentada.

Incluso en los pequeños centros, el acceso a la sala de máquinas debe estar protegido. Los sistemas de autorización más difundidos en el momento actual son el código digital y el distintivo (que permite, si se diera el caso, conservar un fichero histórico de las entradas).

En algunas empresas, la localización de la sala de máquinas y su disposi- ción (planta, ventanas, paredes, etc.) tienen en cuenta los riesgos de motines, de conflictos sociales, o de cualquier intrusión fraudulenta por medios vio- lentos. Si fuera el caso, la implantación geográfica del emplazamiento de urgencia se mantendrá en secreto.


• P. ¿Está controlado el acceso físico al lugar de almacenamiento de las cintas (o cartuchos) magnéticas?

Es conocido por parte de los auditores que un buen número de robos de información han podido tener lugar dentro de los entornos de alta seguridad, debido a que las cintas magnéticas, soportes de ficheros sensibles, estaban almacenadas sin protección.

Por tanto, es deseable que los soportes magnéticos de almacenamiento estén agrupados en un mismo emplazamiento (con excepción de las copias de seguridad externas) cuyo acceso será estrictamente reglamentado.

• P. ¿Los locales están protegidos contra incendio?

Distinguiremos:

— Los dispositivos de detección, generalmente basados en la detección del humo.

— Los dispositivos de extinción; como ejemplos se pueden citar el gas ha- lón, el gas carbónico, el agua (utilización de aspersores), etc.

Nos daremos cuenta que un procedimiento de alarma, conectado por ejemplo a un servicio de seguridad, o con los servicios de bomberos, puede mostrarse más eficaz que un procedimiento de extinción automática (¡hemos visto algunas veces dispararse inesperadamente aspersores y verter grandes masas de agua en la sala de las máquinas, dañando gravemente los equipos y las copias de seguridad magnéticas!).

• P. ¿Los locales están protegidos contra los daños por agua?

Incluso en el mismo París, puede ser peligroso instalar una sala de má- quinas en el sótano, por ejemplo si éste está situado en los márgenes del Sena.

• P. ¿Está el centro informático protegido contra los fallos de fluido eléctrico?

El sistema de alimentación ininterrumpida (SAI) permite, a un coste razonable, protegerse contra los cortes de alimentación de corta duración. También lo encontramos en la mayoría de los centros.

Para los cortes de larga duración, por ejemplo en caso de huelga, sólo el grupo electrógeno puede suministrar la electricidad necesaria. Igualmente, teniendo en cuenta su coste, sólo será implantado cuando, más allá de las ne-


cesidades puramente informáticas, la prosecución de la actividad de la empresa lo justifique.

• P. ¿Se ha previsto un sistema de detección de las intrusiones?

Diferentes sistemas permiten detectar las eventuales intrusiones después de la salida del personal informático. Por ejemplo: haz luminoso, detector de ruidos, televigilancia, etc.

4.11 LOS SEGUROS

El auditor comprobará que se hayan previsto las coberturas financieras de los riesgos relativos a:

— La destrucción de los equipos. — La reconstrucción de los ficheros perdidos. — Las pérdidas de explotación a consecuencia de la falta de disponibilidad

de los equipos. — Las pérdidas financieras a consecuencia de actos malintencionados o

fraudulentos.

No obstante, tendrá el cuidado de no recomendar sistemáticamente la sus- cripción de las pólizas más completas. La falta de evaluación de los riesgos incurridos constituye un error de gestión; en cambio, si los riesgos han sido evaluados, la decisión de asegurarlos o no constituye una decisión de ges- tión de la incumbencia de la Dirección general, de acuerdo con los riesgos incurridos, el coste del seguro y las medidas preventivas que pueden ser tomadas.

Los contratos de seguro contra los riesgos informáticos pueden ser clasificados en: — Los contratos «a todo riesgo informático» (TRI) que cubren, según la ga-

rantía, todos o parte de los riesgos relativos a los sucesos accidentales. — Los contratos «de extensión a los riesgos informáticos» (ERI), que cubren,

según las garantías, total o parcialmente los daños relacionados con una utilización no autorizada de los sistemas informáticos (actos fraudulentos o mal intencionados).

— Los contratos de tipo «informático global» que acumulan las coberturas relacionadas con los dos tipos de riesgos precedentes.


4.12 LAS OBLIGACIONES LEGALES DE DECLARACIÓN

• P. ¿Está la empresa suscrita al conjunto de las declaraciones obligatorias?

Citemos a título de ilustración:

— Las obligaciones relativas a la ley “informática y libertades” que asegura la protección de los datos nominativos (véase recuadro).

— Las obligaciones relativas a la transmisión de los datos cifrados en las redes (decreto nº 86/250 del 18 de febrero de 1986).

— Las obligaciones relativas a la utilización de las redes con valor añadido, o sea, las redes telemáticas abiertas a terceros y que utilizan las conexiones especializadas (decreto nº 87/775 del 24 de septiembre de 1987).

— Las obligaciones relativas a la «puesta a disposición del público o de cate- gorías de público por un procedimiento de telecomunicación, de signos, de señales, de escritos, de imágenes, de sonidos o de mensajes de todo tipo que no tengan el carácter de correspondencia privada» (ley ne 86/1067 del 30 de septiembre de 1986 relativa a la libertad de comunicación, decreto ns

87-277 del 17 de abril de 1987 y circular del 17 de febrero de 1988).

La ley informática y libertades de Francia del 6 de enero de 1978

Esta ley tiene como objetivo la protección del individuo frente a las informaciones nominativas controladas por cadenas de proceso automatizado.

Con este propósito: — el capítulo 2 de la ley instituye la creación de una Comisión Nacional de la

Informática y Libertad (CNIL); — el capítulo 3 impone que todo proceso automatizado que contenga infor-

maciones nominativas sea objeto de una declaración previa en la Comi- sión;

— el capítulo 4 aclara las condiciones en las cuales las informaciones nominativas pueden ser recogidas y conservadas;

— el capítulo 5 es relativo al derecho de acceso de cada individuo a los datos nominativos que le conciernen;

— el capítulo 6 aclara las sanciones aplicables en caso de falta de respeto a las disposiciones precedentes. A continuación veremos algunos extractos de esta ley.


Capítulo III Formalidades previas a la aplicación de procesos automatizados

Art. 14. - La Comisión Nacional de la Informática y de las Libertades ve- la por que los procesos automatizados de informaciones nominativas, públicos o privados, sean llevados a cabo de acuerdo con las disposiciones de la presente ley.

Art. 15. - Salvo los casos en los cuales deben ser autorizados por la ley, los procesos automatizados de informaciones nominativas llevados a cabo por cuenta del estado, de un establecimiento público o de una colectividad terri- torial, o de una persona física de derecho privado que dirige un servicio pú- blico, son decididos por un acto reglamentario llevado a cabo después del conforme del Consejo de Estado.

Cuando el aviso de la Comisión no es notificado al cabo de un plazo de dos meses, renovable una sola vez por decisión del presidente, se entiende como favorable.

Art. 16. - Los procesos de informaciones nominativas automatizados llevados a cabo por cuenta de personas que no están autorizadas por las disposiciones del artículo 15, deben ser objeto de una declaración de la Comisión Nacional de la Informática y de las Libertades previa a su aplicación.

Esta declaración comporta el compromiso de que el proceso satisface las exigencias de la ley.

A partir del momento en que ha recibido el comprobante emitido de inmediato por la Comisión, el peticionario puede aplicar el proceso. No está exonerado de ninguna de sus responsabilidades.

Art. 17. - Para las categorías más corrientes de procesos de carácter pú- blico o privado, que no comporten manifiestamente ningún atentado a la vida privada o a las libertades, la Comisión Nacional de la Informática y de las Li- bertades establece y publica las normas simplificadas inspiradas en las carac- terísticas mencionadas en el artículo 19.

Para los procesos que respondan a estas normas, sólo una declaración simplificada de conformidad con una de estas normas es depositada ante la Comisión. Salvo decisión en particular de ésta, el comprobante de la declaración se entrega inmediatamente. A partir de la recepción de este comprobante, el peticionario puede aplicar el proceso. No está exonerado de ninguna de sus responsabilidades.

Capítulo V Ejercicio del derecho de acceso

Art. 34. - Toda persona que justifique su identidad tiene el derecho de examinar los servicios u organismos encargados de aplicar los procesos automatizados cuya lista es asequible al público en aplicación del artículo 22 precedente, con el fin de saber si estos procesos llegan a las informaciones nominativas que se refieran a ella y, si fuera el caso, obtener comunicación.

Art. 35. - El titular del derecho de acceso puede obtener comunicación de las informaciones que se refieran a él. La comunicación, en lenguaje claro, debe ser conforme al contenido de los registros.


Las normas y deliberaciones de la CNIL han aportado además aclaracio- nes en cuanto a la aplicación de esta ley. De este modo, están sujetos a decla- ración simplificada los procesos relativos a la remuneración y a la gestión de ficheros de clientes y de proveedores. La contabilidad general está exonerada de cualquier declaración.

Por último, conviene remarcar que, en la práctica, la Ley Informática y Libertad está lejos de ser aplicada de forma universal y que la falta de decla- ración casi nunca ha sido sancionada.

Por fortuna, la evolución hacia las aplicaciones microinformáticas no se hace para facilitar las eventuales investigaciones en estos campos.

A continuación se incluye la legislación vigente en España sobre el tratamiento o proceso de datos.

Ley informática Regulación del tratamiento automatizado de los datos de

carácter personal (España)

Ley 5/1992 de 20 de octubre

Esta ley tiene como objeto limitar el uso de la informática y otras técnicas y medios de tratamiento automatizado de los datos de carácter personal para garantizar el honor, la intimidad personal y familiar de las personas físicas y pleno ejercicio de sus derechos.

Se estructura en los siguientes siete títulos principales:

TITULO I, Disposiciones Generales, en el que se recogen los preceptos deli- mitadores del ámbito de aplicación de la Ley y las definiciones de datos de ca- rácter personal, fichero automatizado, tratamiento de datos, responsable de fichero, afectado y procedimiento de asociación.

TITULO II, Principios de la protección de datos, en el cual se desarrollan los principios generales que definen las pautas a las que debe atenerse la recogida de datos de carácter personal. Estas pautas tienen como finalidad garantizar tanto la veracidad de la información contenida en los datos almacenados como la congruencia y la racionalidad de la utilización de los datos.

TÍTULO III, Derechos de las personas, que configura jurídicamente las ga- rantías de las personas —derechos de información, de acceso de los datos y de rectificación y cancelación, entre otros— como derechos subjetivos encaminados a hacer operativos los principios genéricos del Título II. Los derechos de acceso a los datos y de rectificación y cancelación son las piezas centrales del sistema cautelar o preventivo instaurado por la Ley.


TÍTULO IV, Disposiciones sectoriales, en el que se distingue entre los distin- tos tipos de ficheros, según sea su titularidad pública o privada.

TITULO V, Movimiento internacional de datos, que regula los posibles efectos perniciosos asociados con la transmisión internacional de datos de carácter personal.

TÍTULO VI, Agencia de Protección de Datos, por el cual se establece la crea- ción de un órgano independiente, al que se atribuye el estatuto de Ente públi- co, para el control de la aplicación de Ley con objeto de asegurar la máxima eficacia de sus aplicaciones.

TÍTULO VII, Infracciones y sanciones, en el que la Ley se limita a tipificar, de acuerdo con la práctica usual, unos supuestos genéricos de responsabilidad administrativa, con arreglo a una gradación de infracciones que sigue la dis- tinción habitual de leves, graves y muy graves.

A continuación, veremos algunos extractos de esta Ley:

TÍTULO I. Disposiciones generales Artículo 1. Objeto La presente Ley Orgánica, en desarrollo de lo previsto en el apartado 4 del ar- tículo 18 de la Constitución, tiene por objeto limitar el uso de la informática y otras técnicas y medios de tratamiento automatizado de los datos de carácter personal para garantizar el honor, la intimidad personal y familiar de las personas físicas y el pleno ejercicio de sus derechos.

Artículo 2. Ámbito de aplicación 1. La presente Ley será de aplicación a los datos de carácter personal que fi-

guren en ficheros automatizados de los sectores público y privado y a toda modalidad de uso posterior, incluso no automatizada, de datos de carácter personal registrados en soporte físico susceptible de tratamiento automatizado.

TÍTULO II. Principios de la protección de los datos Artículo 4. Calidad de los datos 1. Sólo se podrán recoger datos de carácter personal para su tratamiento au-

tomatizado, así como someterlos a dicho tratamiento, cuando tales datos sean adecuados, pertinentes y no excesivos en relación con el ámbito y las finalidades legítimas para las que se hayan obtenido.

2. Los datos de carácter personal objeto de tratamiento automatizado no po- drán usarse para finalidades distintas de aquellas para las que los datos hubieran sido recogidos.

5. Los datos de carácter personal serán cancelados cuando hayan dejado de ser necesarios o pertinentes para la finalidad para la cual hubieran sido re- cabados y registrados.

6. Serán almacenados de forma que permitan el ejercicio del derecho de acceso por parte del afectado.


Artículo 5. Derecho de información en la recogida de datos 1. Los afectados a los que se soliciten datos personales deberán ser previamente informados de modo expreso, preciso e inequívoco:

a) De la existencia de un fichero automatizado de datos de carácter personal, de la finalidad de la recogida de éstos y de los destinatarios de la in- formación.

b) Del carácter obligatorio o facultativo de su respuesta a las preguntas que les sean planteadas.

c) De las consecuencias de la obtención de los datos o de la negativa a su- ministrarlos.

d) De la posibilidad de ejercitar los derechos de acceso, rectificación y cancelación.

e) De la identidad y dirección del responsable del fichero.

Artículo 11. Cesión de datos 1. Los datos de carácter personal objeto del tratamiento automatizado sólo

podrán ser cedidos para el cumplimiento de fines directamente relacionados con las funciones legítimas del cedente y del cesionario con el previo consentimiento del afectado.

TITULO III. Derechos de las personas Artículo 13. Derecho de información Cualquier persona podrá conocer, recabando a tal fin la información oportu- na del Registro General de Protección de Datos, la existencia de ficheros automatizados de datos de carácter personal, sus finalidades y la identidad del responsable del fichero. El Registro General será de consulta pública y gra- tuita.

Artículo 14. Derecho de acceso 1. El afectado tendrá derecho a solicitar y obtener información de sus datos

de carácter personal incluidos en los ficheros automatizados.

Artículo 15. Derecho de rectificación y cancelación 1. Por vía reglamentaria se establecerá el plazo en que el responsable del fi-

chero tendrá la obligación de hacer efectivo el derecho de rectificación o cancelación del afectado.

2. Los datos de carácter personal que resulten inexactos o incompletos serán rectificados y cancelados en su caso.

3. Si los datos rectificados o cancelados hubieran sido cedidos previamente, el responsable del fichero deberá notificar la rectificación o cancelación efectuada al cesionario.

TÍTULO VI. Agencia de Protección de Datos Artículo 34. Naturaleza y régimen jurídico 1. Se crea la Agencia de Protección de Datos. 2. La Agencia de Protección de Datos es un Ente de Derecho Público, con

personalidad jurídica propia y plena capacidad pública y privada, que ac- túa con plena independencia de las Administraciones Públicas en el ejercicio de sus funciones.


Artículo 36. Funciones Son funciones de la Agencia de Protección de Datos: a) Velar por el cumplimiento de la legislación sobre protección de datos y

controlar su aplicación, en especial en lo relativo a los derechos de infor- mación, acceso, rectificación y cancelación de datos.

b) Emitir las autorizaciones previstas en la Ley o en sus disposiciones regla- mentarias.

c) Dictar, en su caso y sin perjuicio de las competencias de otros órganos, las instrucciones precisas para adecuar los tratamientos automatizados a los principios de la presente Ley.

d) Atender las peticiones y reclamaciones formuladas por las personas afectadas.

e) Proporcionar información a las personas acerca de sus derechos en materia de tratamiento automatizado de los datos de carácter personal.

f) Ordenar la cesación de los tratamientos de datos de carácter personal y la cancelación de los ficheros, cuando no se ajusten a las disposiciones de la presente Ley.

g) Ejercer la potestad sancionadora en los términos previstos por el título VII de la presente Ley.

h) Informar, con carácter preceptivo, los proyectos de disposiciones generales que desarrollen esta Ley.

i) Recabar de los responsables de los ficheros cuanta ayuda e información estime necesaria para el desempeño de sus funciones.

j) Velar por la publicidad de la existencia de los ficheros automatizados de datos con carácter personal, a cuyo efecto publicará periódicamente una relación de dichos ficheros con la información adicional que el Director de la Agencia determine.


Capítulo 5

Las funciones de asistencia técnica

Cada vez más se han desarrollado durante la última década las funciones de control o de asistencia técnica:

— definición de normas y métodos, — gestión de las bases de datos, — infocentro, — microinformática, — gestión de redes, — gestión de la seguridad.

En los grandes centros de procesado, algunas veces, estas funciones están agrupadas en el seno de una dirección técnica. Éstos son los puntos clave de la auditoría de estas diferentes funciones que serán estudiados en este capítulo.

5.1 LAS BASES DE DATOS

La generalización de la utilización de los sistemas de gestión de bases de datos (SGBD) en el desarrollo de aplicaciones ha llevado a la creación de funciones y de tareas nuevas.

Veremos, además, que la mayoría de los controles descritos a continua- ción se imponen igualmente en el caso de programas diseñados en torno a sistemas de gestión de ficheros «tradicionales» y que la presencia de SGBD sólo sirve para aumentar su necesidad.


• P. ¿Hay un «administrador de datos»?

El administrador de datos tiene como papel la gestión de los datos de la empresa (en las PYME) o, en el caso de las aplicaciones importantes, la ges- tión de los datos de la aplicación.

Es el garante de la coherencia y de la falta de redundancia de los datos controlados por el SGBD.

Distinguiremos, por lo menos en los grandes centros, la noción de administrador de datos, responsable de los datos de la empresa, de la de administrador de base de datos, responsable de la implantación física de las bases de datos, de su optimización y de su coherencia técnica (ver a continuación). La administración de la base de datos es una función de sistema, mientras que la administración de datos es más bien una función de estudio.

• P. ¿Se utiliza un «diccionario de datos»?

El «diccionario de datos» es un programa que facilita la gestión de los datos por parte del administrador y su utilización por parte de los equipos de desarrollo.

• P. ¿Se procede a tareas de búsqueda de optimización de la base de datos?

Hay, por lo general, varias formas de estructurar una base de datos y de controlar el acceso a ésta para dar respuesta a una misma necesidad. Según se optimicen o no los métodos de acceso, las actuaciones de un mismo programa pueden variar en proporciones bastante considerables. La ausencia total de optimización conducirá en algunos casos a tiempos de respuesta de las aplicaciones interactivas, o a tiempos de ejecución de las tareas en tiempo diferido, totalmente inaceptables. Esta constatación, además, sólo sirve para reforzar el recurso cada vez más frecuente a los SGBD conocidos como rela- ciónales.

La optimización de las bases de datos constituye una tarea esencial del administrador de datos en conjunto con los programadores.

• P. ¿Se controla regularmente la integridad de las bases y la coherencia de los datos?

Se deben controlar regularmente:

— la coherencia técnica de las bases de datos, — la coherencia funcional de los datos.

Las funciones de asistencia técnica 91

• Coherencia técnica

La técnica de las bases de datos, en cualquier tipo de arquitectura (jerár- quica, en red o relacional) implica la presencia de apuntadores y de un ín- dice, que aseguren la relación entre los segmentos (o entre las tablas) y que eviten de este modo la redundancia de los datos.

No obstante, los incidentes pueden conducir a un deterioro de los apuntadores y de los índices, y a una incoherencia técnica del contenido de la base, conduciendo a la pérdida de algunos datos.

• Coherencia funcional

Si bien es posible controlar la coherencia de los datos en el momento de su introducción, este control no excluye una degradación posterior de éstos, por razones diversas (error en un programa a tiempo diferido, modificación de los datos no controlados, incidente máquina, etc.).

Es, por lo tanto, deseable que las normas de integridad y de coherencia de los datos puedan ser incluidas en la definición de la base misma, y que el respeto a estas normas sea controlado regularmente para el conjunto de los datos de la base.

5.2 LA GESTIÓN DE REDES

• P. ¿Existe una célula técnica de gestión de redes?

En los entornos «gran sistema», la aplicación de una red necesita la elec- ción de programas coherentes los unos con los otros, para luego proceder a su implantación y su «parametraje».

La elección de las redes (TRANSPAC, TRANSCOM, TRANSFIX, etc.) necesita estudios técnicos y económicos.

Por lo general, esta función es atribuida a una célula técnica agregada al equipo de sistema.

Además de la existencia misma del equipo de red, el auditor controlará su actividad:

— justificación técnica y económica de las elecciones, — comprobación de las nuevas configuraciones, — back-up entre los ingenieros de sistemas, etc.


• P. ¿Existe una célula de asistencia de red?

Contrariamente a la célula técnica precedente, ésta tiene esencialmente un papel de asistencia a los usuarios: — instalación de nuevos puestos de trabajo, — primeros auxilios por teléfono en caso de problema, — mantenimiento, si éste no está confiado a empresas especializadas, — gestión de algunas mesas.

En verdad se trata de una función de tipo «SVP», que debe estar disponible a toda hora para dar respuesta a las necesidades de los usuarios.

• P. ¿Están controlados los accesos a la red?

La existencia de una red implica riesgos adicionales de acceso no autorizado, por diferentes razones: — El número de terminales conectados al ordenador central aumenta cons-

tantemente y éstos pueden encontrarse en posiciones geográficas muy alejadas.

— Si bien en la mayoría de las aplicaciones la lista de terminales física- mente autorizados a estar conectados al sistema central se establece de forma limitativa, es cada vez más frecuente que por razones de flexibilidad de utilización los terminales no identificados físicamente sean autorizados a acceder a la red: esto se da, sobre todo, cuando se aplican los procedimientos de mantenimiento a distancia.

— La gestión de redes combina, la mayoría de las veces, la utilización de lí- neas privadas (líneas alquiladas) y de redes públicas (red telefónica conmutada, TRANSPAC), donde los datos que circulan se mezclan con los de las demás empresas.

— Por último, algunas aplicaciones informáticas están destinadas, por naturaleza, a un acceso público: consulta de cuentas por la clientela en los establecimientos financieros, consulta de existencias y registro de los pedidos en las empresas industriales o comerciales.

Los diferentes métodos de control de acceso serán estudiados en el capí- tulo 6.

• P. ¿Se han previsto técnicas de salvaguarda y recuperación especiales para la utilización de la aplicación en procesamiento a distancia?

Las técnicas de salvaguarda diaria de los ficheros (por lo general, durante


el proceso nocturno) se encuentran con una gran limitación en el caso de las aplicaciones interactivas: la actualización permanente de los ficheros o una copia de seguridad en la víspera o durante la noche, implica introducir otra vez todos los movimientos del día, en el caso de un incidente y de necesidad de recuperar a partir de la copia de seguridad.

Además, esta molestia es aceptable en algunos casos a condición de que, por lo menos, los usuarios obren en consecuencia. En el caso contrario, se deben aplicar técnicas específicas.

La más frecuente y la más vieja consiste en el registro periódico (log- ging) de las transacciones. Cada puesta al día de ficheros da lugar a la crea- ción de movimientos en un fichero-diario, descargado regularmente en cinta o cartucho. En caso de fallo, la nueva aplicación de los movimientos del día en la copia de seguridad en la víspera o por la noche permitirá reconstruir la situación de los ficheros en el momento del incidente.

Más exactamente, el contenido del fichero diario podrá variar de un entorno al otro. En algunos casos, contendrá las propias transacciones de ac- tualización, en otros contendrá la imagen de los registros de fichero modificados antes y después de la puesta al día.

Una técnica más reciente consiste en crear para los ficheros puestos al día en tiempo real ficheros «imagen» en un disco distinto de aquel que contiene los ficheros originales, y puesto al día al mismo tiempo que éstos. De este modo, en caso de fallo en el disco que contenga el fichero original, será posible proseguir la aplicación, casi de inmediato, partiendo del disco imagen.

El principal inconveniente de estas técnicas de registro periódico y disco «imagen», que explica además que no sean utilizadas en ciertos emplazamientos (esencialmente las PYME), reside en el coste. La creación del fichero diario multiplica las operaciones de entradas-salidas («I/O») y requiere también configuraciones de equipamiento más importantes. La técnica de los ficheros «imagen» es aún más onerosa, debido a que necesita una duplicación de los volúmenes en disco, que hacen los soportes magnéti- cos costosos.

Veremos, por último, que la técnica del registro periódico se podría ex- tender en los próximos años a los procesos en tiempo diferido. Esto ya ocurre con el SGBD relacional DB2 de IBM, que permite periodificar las modificaciones de la base, salidas, a la vez, de los procesos en tiempo real y en tiempo diferido.

• P. Si las aplicaciones lo necesitaran, ¿se han previsto procedimientos de «back-up» de la red?

En el capítulo anterior, hemos enfocado esencialmente los procesos de recuperación a consecuencia de una indisponibilidad de la unidad central.


Pero existe otro riesgo propio de las redes, que es: la indisponibilidad de un soporte de transmisión de datos. Es el caso bien conocido, por ejemplo, de la línea alquilada no disponible durante algunos días debido a que se encuentra físicamente estropeada.1

Cuando la importancia del software lo justifica, conviene por tanto prever los procedimientos con el fin de paliar estos fallos. Citemos, por ejemplo:

— Duplicación de una línea especializada por medio de un abono a TRANS- PAC, preparada para tomar inmediatamente el relevo en la transferencia de datos.

— El desarrollo de software que permita el procesamiento en el local y en modo degradado de algunas aplicaciones, en el caso de imposibilidad total de asegurar la conexión entre los usuarios y el emplazamiento central.

— La utilización de conexiones TRANSFIX, que permiten sus propias soluciones de urgencia.

5.3 LA MICROINFORMATICA

• P. ¿Están coordinadas la adquisición y la utilización de microordenadores ?

Las propuestas de los auditores no deben acabar en una centralización abusiva de la política microinformática, que sería mal entendida y marcharía en sentido contrario a la historia.

Una política de elección y de compra descentralizada en los servicios es aceptable a condición de ser eficazmente enmarcada.

Por tanto, el auditor se asegurará de que estén coordinadas al nivel de la Dirección informática:

— La elección de los equipos «aceptados» en la empresa, con vistas a ofre- cer una diversidad de material suficientemente difundida.

— La elección de las aplicaciones de ofimática «aceptadas»: proceso de texto, hojas de cálculo, software gráfico, software integrado, gestores de ficheros, etc.

— La elección de proveedores y la negociación de las condiciones comerciales.

1. Nos acordaremos igualmente de la parada durante varios días del «nudo» TRANSPAC de Lyon, en los primeros años de funcionamiento de esta red.


— Las modalidades del mantenimiento de los equipos y de los programas. — La definición de la política en materia de infocentro, y las modalidades

de transferencia de datos entre unidad central y microordenadores.

Es evidente que la falta total de coordinación, que encontramos en algunas empresas, no debe darse en ningún caso ya que la misma conduce de forma rápida a una situación completamente anárquica. Esta falta de coordi- nación es, por lo general, el resultado de un abandono de la Dirección Infor- mática ante las fuertes presiones "autonomistas" de los servicios en materia de ofimática. Además, a menudo, son también la consecuencia de las fuertes reticencias que se manifestaban en este ámbito en el seno de los servicios in- formáticos hace algunos años.

• P. ¿Se pone cuidado para que la microinformática no se transforme en el soporte de un desarrollo anárquico de aplicaciones autónomas y heterogéneas?

Si bien la microinformática actualmente es un soporte fiable y eficaz para procesar el conjunto de las necesidades de la empresa en materia de ofi- mática, su utilización en calidad de soporte del desarrollo de aplicaciones de gestión, cuando no está sistemáticamente prohibida, debe, por lo menos, ser estudiada cuidadosamente.

Cantidad de programas de gestión presupuestaria, de gestión del inmovilizado, de gestión de existencias, de contabilidad general, desarrollados por principiantes con simples hojas de cálculo o gestores de ficheros, son verdaderos peligros para el director de empresa. Redactados en pocos días, puestos en explotación sin verdaderas comprobaciones, estos programas raramente ofrecen los controles suficientes en el momento de la entrada de los datos (que, además, a menudo debe ser realizada doblemente, teniendo en cuenta la falta de coordinación con los desarrollos en gran sistema).

En cambio, bien controlados, los desarrollos en microordenadores, eventualmente completados por intercambios de datos con los grandes sistemas, constituyen un medio valioso para dar satisfacción a los usuarios, descargando los servicios informáticos atascados.

En definitiva, el auditor comprobará:

— que la utilización de la microinformática con la finalidad de desarrollo de aplicaciones sea conocida por el servicio informático y controlada por éste (los programas serán, si es posible, desarrollados por el servicio in- formático);


— que las aplicaciones desarrolladas en estas condiciones estén documen- tadas correctamente y presenten las mismas garantías en materia de seguridad que las aplicaciones desarrolladas en gran sistema: • control de datos introducidos, • procedimientos de copia de seguridad y de recuperación, • control de entrada, • etcétera.

• P. ¿Está controlado el acceso a las aplicaciones o a los datos sensibles gestionados por microordenador?

Las técnicas habituales de protección de acceso a los ficheros, a las bibliotecas de programas y a las aplicaciones pueden llegar a ser aplicadas en un entorno microinformático.

Conviene, no obstante, reconocer que éstas están todavía demasiado poco difundidas incluso cuando se procesan aplicaciones «sensibles» en microordenadores.

¿Cuál es la proporción de puestos de trabajo en los cuales las posibilidades de control de acceso por contraseña han sido efectivamente utilizadas? Si bien hace algunos años los microordenadores eran particularmente per- meables, la negligencia es aún más palpable cuando, algunos de ellos ofrecen actualmente posibilidades de control de acceso análogas a las de los grandes sistemas.

Además, y excepto cuando los microordenadores están conectados en redes, las mejores protecciones son en la actualidad las protecciones físicas tales como el bloqueo por medio de llave o tarjeta magnética, o simplemente cierre a llave de los despachos y armarios.

• P. ¿Se toman las medidas específicas para limitar los riesgos de robo de los microordenadores?

En las grandes empresas, los riesgos de robo de equipos deben estar siempre presentes. Este riesgo es tanto más importante que el propio microordenador. Algunos componentes anexos son susceptibles de ser robados, tales como: el software, varias tarjetas de extensión, etc.

Entre las medidas preventivas, podemos citar:

— El control de las entradas y salidas de la empresa. — La identificación precisa de las inmovilizaciones y del inventario físico

regular del conjunto del parque.


• P. ¿La empresa no incurre en ninguna sanción penal por la implantación de programas sin licencia de utilización?

Muchas grandes empresas han tenido, hasta nuestros días, una actitud poco ejemplar en este campo ya sea por una política deliberada o bien por falta de control. El caso de la encuesta realizada en los locales del INPI2 en noviembre de 1990, que ha puesto en evidencia la implantación en algunos micros de este organismo de software «desprecintado», mas allá de la anéc- dota, es del todo significativo.

Ahora bien, el no respeto a la reglamentación implica para la empresa:

— Un riesgo de sanciones penales, previstas en la ley del 3 de julio de 1985 relativa a la propiedad intelectual y artística (ver recuadro).

— Un riesgo de deterioro del parque existente, en caso de la presencia de «virus» en el software utilizado sin licencia.

Los controles por sondeo de la ausencia de software ilícito en los microordenadores deben estar previstos.

Ley del 3 de julio de 1985 relativa a la protección intelectual y artística (Francia)

Esta ley extiende a los autores de software las disposiciones de la ley del 11 de marzo de 1957 relativa a la propiedad literaria y artística. Encontraremos a continuación las disposiciones del título V, relativas al software.

Título V De los programas informáticos

«Art. 45 - Salvo cuando se estipule lo contrario, el software creado por uno o varios empleados en el ejercicio de sus funciones pertenece al empleador al cual se asignan todos los derechos reconocidos a los autores.

Todo contencioso sobre la aplicación del presente artículo está sometido al tribunal supremo del lugar de residencia del empleador.

Las disposiciones del primer párrafo del presente artículo son igualmente aplicables a los agentes del estado, de las colectividades públicas y de los establecimientos públicos de carácter administrativo.

Art. 46 - Salvo cuando se estipule lo contrario, el autor no puede oponerse a la adaptación del software dentro de los límites de los derechos que ha ce- dido, ni tampoco de ejercer su derecho de arrepentimiento o de retractarse.

Art. 47 - Por derogación del 2B del artículo 41 de la ley nº 57-298 del 11 de marzo de 1957 anteriormente citada, toda reproducción aparte del estableci-

2. Instituto Nacional de la Propiedad Industrial.


miento de una copia de seguridad por parte del usuario y toda utilización de un software no autorizado expresamente por el autor o sus derecho habientes, está sujeto a las sanciones previstas por la mencionada ley.

Art. 48 - Los derechos objeto del presente título se extinguen al vencimiento de un período de veinticinco años contados a partir de la fecha de la creación del software.

Art. 49 - El precio de cesión de los derechos de utilización de un software puede ser global.

Art. 50 - En materia de software, el registro falsificado se ejecuta en virtud a una ordenanza surgida por requerimiento del presidente del tribunal supremo. El presidente autoriza, si fuere el caso, el embargo real.

El funcionario instrumental o el comisario de policía puede ser asistido por un experto designado por el demandante.

A falta de designación o de citación en la quincena del embargo, el embargo incorrecto es nulo.

Además, los comisarios de policía tienen la obligación de presentar, si fuere pedido por cualquier autor de un software protegido por la presente ley o por sus derechohabientes, un registro descriptivo del software falsificado, registro descriptivo que puede ser materializado por medio de una copia.

Art. 51 - Bajo reserva de convenciones internacionales, los extranjeros gozan en Francia de los derechos reconocidos en el presente título, con la con- dición que la ley del Estado del cual son ciudadanos o en el territorio en el cual tienen su domicilio, su sede social o un establecimiento efectivo otorgue pro- tección a los programas creados por los nacionales franceses y por las personas que tengan su domicilio o un establecimiento efectivo en Francia.»

* * *

Cabe destacar que la falsificación puede estar penada por una prisión de tres meses a dos años y/o una multa de 6.000 a 120.000 F.

Pero aquí también, el número de registros fraudulentos es irrisorio en comparación con el número de copias ilícitas de programas en circulación, incluso en las empresas más grandes.

A continuación en el siguiente recuadro aparece un extracto de la legisla- ción vigente actual en España sobre derechos de autor en los programas.

Ley de propiedad intelectual. Normas Reguladoras (España)

LEY 22/1987 de 11 de noviembre

Entre sus disposiciones reguladoras para la protección de los derechos de propiedad intelectual, esta Ley recoge también, en su Título VII, la protección de los derechos de autor derivados de la creación de los programas de ordenador.


TÍTULO VII. De los programas de ordenador Artículo 95

El derecho de autor sobre los programas de ordenador se regirá por los preceptos del presente título y, en lo que no esté específicamente previsto en el mismo, por las disposiciones que resulten aplicables de la presente Ley.

Artículo 96 1. A los efectos de la presente Ley se entenderá por programa de ordenador

toda secuencia de instrucciones o indicaciones destinadas a ser utilizadas, directa o indirectamente, en un sistema informático para realizar una fun- ción o una tarea o para obtener un resultado determinado, cualquiera que fuere su forma de expresión y fijación.

2. La documentación técnica y los manuales de uso de un programa gozarán de la misma protección que este título dispensa a los programas de ordenador.

3. Los programas de ordenador que formen parte de una patente o un modelo de utilidad gozarán, sin perjuicio de lo dispuesto en la presente Ley, de la protección que pudiera corresponderles por aplicación del régimen jurí- dico de la propiedad industrial.

4. La protección establecida en la presente Ley se extiende a cualesquiera versiones sucesivas del programa, así como a los programas derivados.

Artículo 97 La duración de los derechos de explotación de un programa será de cin-

cuenta años, contados desde el 1 de enero del año siguiente al de su publica- ción, o al de su creación si no se hubiera publicado.

Artículo 98 El autor, salvo pacto en contrario, no podrá oponerse a que el cesionario

titular de derechos de explotación realice o autorice la realización de versiones sucesivas de su programa ni de programas derivados del mismo.

Artículo 99 1. Se entiende por cesión del derecho de uso aquel acto en virtud del cual el ti-

tular del derecho de explotación de un programa de ordenador autoriza a otro a utilizar el programa, conservando el cedente la propiedad del mismo. Se entenderá, salvo prueba en contrario, que la cesión del derecho de uso es de carácter no exclusivo e intransferible, presumiéndose asimismo que lo es para satisfacer únicamente las necesidades del usuario.

2. La reproducción del programa, incluso para uso personal, exigirá la auto- rización del titular del derecho de explotación, con excepción de la copia de seguridad.

3. No constituye reproducción, a los efectos previstos en el artículo 18 de esta Ley, la introducción del programa en memoria interna a los solos efectos de su utilización por el usuario, sin perjuicio de su necesaria comunicación al titular del derecho de explotación cuando así se hubiere pactado.

4. No constituye transformación, a los efectos previstos en el artículo 21, la adaptación de un programa realizada por el usuario para la utilización exclusiva por el mismo.


Artículo 100 Los derechos sobre los programas de ordenador, así como sobre sus suce-

sivas versiones y los programas derivados, podrán ser objeto de inscripción en el Registro de la Propiedad Intelectual.

Reglamentariamente se determinarán aquellos elementos de los programas registrados que serán susceptibles de consulta pública.

• P. ¿Se ejecutan regularmente programas de detección de virus en los microordenadores?

Estos programas son susceptibles de detectar la presencia de virus en los microordenadores, permitiendo de este modo desactivarlos antes que éstos hayan tenido tiempo de causar daños.

5.4 LOS MÉTODOS

• P. ¿Hay en la empresa una función de responsable de métodos?

El responsable de métodos, si es posible, tendrá a su cargo la definición del conjunto de las normas propias de la actividad informática, ya sean relacionadas con los procedimientos de desarrollo y de programación o con los procedimientos de puesta en explotación y de producción.

• P. ¿Las normas son objeto de una difusión sistemática al conjunto de los colaboradores involucrados?

Por supuesto, los procedimientos de actualización periódicos deben estar previstos.

• P. ¿Efectúa regularmente el responsable de métodos los controles con vistas a la aplicación efectiva de las normas?

En ausencia de cualquier control, las normas, teniendo en cuenta su carácter obligatorio, corren el gran riesgo de caer progresivamente en el olvido.


5.5 EL INFOCENTRO

La idea de infocentro, o de infoservicio, corresponde a la puesta a dispo- sición de los usuarios de lenguajes de programación de fácil manipulación, destinados a preguntas sobre las bases de datos y que permiten descargar otro tanto a los equipos de desarrollo del servicio informático.

• P. ¿Las herramientas de infocentro están bien adaptadas para la utilización por parte de los no informáticos?

Muy a menudo, los lenguajes de programación rápida totalmente inadap- tados a una utilización por los no informáticos por ser demasiado complejos, son denominados abusivamente lenguajes de infocentro.

En la mejor de las hipótesis, son olvidados totalmente, o peor aún engen- drarán numerosos resultados erróneos.

En caso de necesidad, en los centros más grandes, se pondrán varias herramientas a disposición de los usuarios, tales como: — lenguajes simples destinados a peticiones elementales para la mayoría de

ellos, — verdaderos lenguajes de desarrollo rápido para los más prevenidos.

• P. ¿Está controlado el acceso a las herramientas de infocentro?

El acceso a las herramientas de infocentro debe estar limitado tan sólo a los usuarios habilitados. Además, lo que más se autoriza es la consulta de datos, no su actualización.

• P. ¿No se desvían las herramientas de infocentro de su objetivo original en provecho del desarrollo de aplicaciones «pirata»?

La asistencia dada por el servicio de informática para la utilización del infocentro debe servir para comprobar que éste no es desviado de su función original.

De hecho, ya hemos mencionado, cuando hablamos de los microordenadores, el riesgo relacionado con una proliferación no controlada de aplicaciones paralelas desarrolladas por los usuarios mismos.

• P. ¿Se vigilan las cargas-máquinas imputables al infocentro?

Las herramientas de infocentro son por lo general grandes consumidoras de recursos, tanto de espacio-disco como de tiempo-máquina.


También es importante realizar seguimientos del consumo por aplica- ción, por usuario y por servicio, a fin de detectar abusos eventuales.

Este problema debería desaparecer progresivamente en los próximos años, gracias a la utilización de nuevas técnicas como:

— Equipos dedicados al infocentro. — Utilización de microordenadores, descargando en primer lugar los datos

del emplazamiento central hacia el microordenador, y después procesán- dolos otra vez en éste con la ayuda de herramientas apropiadas.

5.6 LA FUNCIÓN SISTEMA

• P. ¿Se ha creado en los grandes centros un entorno específico para los ingenieros de sistemas?

En los grandes centros de proceso, los ingenieros de sistemas tienen po- deres muy amplios, por el hecho de que ellos cuentan con los programas o software de base.

A título de anécdota, los medios para eludir el RACF, software de control de acceso en los entornos de gran sistema de IBM, son conocidos por la ma- yoría de los ingenieros de sistemas.

El objetivo de la creación de un entorno específico será permitir a los «hombres-sistema» comprobar con toda serenidad las nuevas versiones de los programas de base.

• P. Si se ha elegido desarrollar algún software de base internamente, ¿se ha justificado debidamente esta elección?

Algunos grandes centros informáticos, en particular en los años setenta y comienzos de los años ochenta, han elegido desarrollar internamente algunos programas de base como: sistema de gestión de ficheros, sistema de explotación, monitor de procesamiento a distancia, etc. Esta elección, que implica a veces cargas de trabajo considerables, estaba justificada por la necesidad de procesar volúmenes de información muy importantes con actuaciones que no ofrecían los programas de base disponibles en el mercado.

Desgraciadamente, el mantenimiento de este tipo de software, por lo general escrito en ensamblador, al cabo del tiempo se ha revelado cada vez más complejo, incitando a los responsables de estos centros a volver a las herramientas estándares, que mientras tanto se hicieron más útiles. No obstante,


en este caso también, la conversión fue a menudo larga y delicada, teniendo en cuenta sus consecuencias en los programas aplicables.

De una manera general, el auditor se asegurará de que ningún software de base sea desarrollado en la empresa sin haber sido estudiados los programas que ofrecen funciones similares. Hoy día, el desarrollo de software es- pecífico importante debería ser muy excepcional.

Además, podemos preguntarnos si los mismos errores del pasado no se pueden cometer otra vez, cuando oímos hablar a los grandes grupos, por ejemplo, que desarrollan su propio software de gestión de redes locales.

5.7 LA FUNCIÓN SEGURIDAD

• P. ¿Hay en la empresa una función de gestión de riesgos?

La seguridad informática es de hecho un aspecto importante de las atri- buciones del risk-manager.

No obstante, esta función sólo existe por lo general en las empresas de ta- maño importante.

• P. ¿Hay un responsable de la seguridad en el departamento de informática?

Cuando existe el cargo, el auditor se encargará de conocer las responsabilidades exactas, las cuales pueden variar bastante de un centro a otro. Encontrará, por ejemplo:

— la seguridad física de los locales y de los equipos, — la gestión de los contratos de seguro, — los procedimientos de salvaguarda, — los procedimientos de recuperación, — la definición de los procedimientos de autorización de acceso al entorno, — la protección de los datos confidenciales.

Algunos aspectos metodológicos podrán igualmente estar subordinados a este cargo, por ejemplo, la definición de los procedimientos de puesta en explotación y de control de bibliotecas, o también la definición de los procedimientos de mantenimiento.

Es igualmente deseable que el responsable de la seguridad sea consultado en el momento de los desarrollos de nuevas aplicaciones, con el fin de


asegurar que las molestias relacionadas con un buen control interno sean tomadas en cuenta desde el principio del proyecto.

Por último, si fuere el caso, el responsable de seguridad será consultado sobre ciertos aspectos de la organización del servicio de informática.

• P. ¿Hay un plan de seguridad informática? Este plan, actualizado regularmente, define las medidas a aplicar con el

fin de mejorar la seguridad informática. Constituye a menudo la última etapa de una auditoría, o incluso de un taller de prueba del riesgo informático del tipo MARIÓN (apartado 13.4.1).


Capítulo 6

La protección y la confidencialidad de los datos

La protección y el control de la confidencialidad de los datos de la empresa implica la previsión de tres tipos de manipulaciones:

— El acceso no autorizado a los datos y al software que se encuentran en el emplazamiento central.

— El robo o la copia de ficheros o software depositado en un soporte mag- nético de seguridad.

— La conexión física con las líneas de telecomunicación por las cuales circulan los datos por copia de éstas.

6.1 EL ACCESO NO AUTORIZADO A LOS DATOS QUE SE ENCUENTRAN EN EL EMPLAZAMIENTO CENTRAL

Este riesgo debe ser estudiado muy particularmente, pues permite al operador fraudulento no solamente la posibilidad de consultar los ficheros y, si se diera el caso, los programas, sino también de modificarlos con las consecuencias catastróficas que pueden tener las manipulaciones, como: malver- sación de fondos y destrucción del entorno.


Distinguiremos en las medidas de prevención las siguientes:

— Medidas de prevención de acceso por la identificación del individuo recurrente.

— Medidas de prevención de acceso por la identificación del terminal recurrente.

— Medidas de prevención de acceso a la forma de los datos y su soporte de almacenamiento.

6.1.1 Medidas de prevención por la identificación del individuo recurrente

Estudiaremos primeramente los modos de identificación del individuo recurrente, después examinaremos las técnicas de software de protección.

6.1.1.1 El modo de identificación del individuo recurrente

Distinguiremos de nuevo:

— la identificación lógica por contraseña; — la identificación por cualquier medio físico.

a) La identificación lógica por contraseña

La eficacia de una protección de acceso al entorno informático por atri- bución de códigos de usuarios y de contraseñas supone respetar algunas reglas básicas.

• P. ¿Las contraseñas se atribuyen individualmente a cada usuario?

Las contraseñas colectivas, por ejemplo por servicio o por aplicación, raramente mantienen su confidencialidad por mucho tiempo.

• P. ¿Las contraseñas deben ser modificadas regularmente?

Algunos programas dedicados al control de las protecciones de acceso imponen que la contraseña sea modificada con regularidad por su propie- tario, condición indispensable para una confidencialidad real (la obliga- ción de una modificación cada trimestre parece ser una periodicidad razonable).

La protección y la confidencialidad de los datos 107

• P. ¿Las contraseñas son suficientemente «sofisticadas»?

Algunas contraseñas son utilizadas tan a menudo que unas cuantas tentativas son suficientes para dar con ellas. Éstas son, por ejemplo, las iniciales de los usuarios, su fecha de nacimiento, la fecha de la creación de la contra- seña, etc. El auditor, por sondeo, procederá al control de la verdadera confidencialidad de algunas de ellas.

• P. ¿Se protege el cuadro de contraseñas?

Además de la protección del acceso al fichero de contraseñas, el auditor se asegurará de que éste no sea objeto de ediciones regulares.

• P. ¿Es posible detectar las tentativas de acceso no autorizadas?

La identificación, en tiempo real o en tiempo diferido, de las tentativas de acceso no autorizado permite detectar a tiempo operaciones fraudulentas eventuales.

No obstante, esta identificación no debe llevar a sospechar sistemática- mente de todos los usuarios sin razón.

• P. Después de varias tentativas de acceso infructuosas, ¿son desconectados los usuarios?

Por lo general, se prevé una desactivación de un código de usuario des- pués de tres tentativas de acceso con contraseñas equivocadas. En caso contrario, sería fácil, con las técnicas disponibles hoy día, programar en un microordenador un algoritmo de búsqueda de la contraseña.

* P. ¿Se ha sensibilizado a los usuarios de los riesgos que puede originar el «préstamo» de sus contraseñas?

Esta pregunta vale a fortiori para las «ventas» de contraseña.

b) La identificación física del individuo que opera

Estas técnicas sustituyen generalmente el uso de contraseñas, y no se acumulan a ella, salvo aplicaciones de altísima seguridad.


• P. ¿Existen sistemas de autorización de acceso por medio de tarjeta magnética?

La tarjeta magnética también se refiere al individuo. Esta técnica, tam- bién costosa, está llamada a desarrollarse en los próximos años.

• P. ¿Existen otros sistemas de identificación?

A título de ilustración citemos el reconocimiento vocal, la identificación de las huellas dactilares, del fondo de ojo. Estas técnicas están hoy día en fase experimental y, por supuesto, reservadas a campos específicos de altí- sima seguridad (militares, etc.)

6.1.1.2 Las técnicas de software de protección a) Los principales modos de acceso a los datos

Una protección eficaz representa que se tiene que conocer perfectamente el conjunto de los modos de acceso al entorno informático. Estos modos de acceso pueden ser clasificados en varias categorías.

• El acceso a través de una aplicación transaccional

Para cada una de las aplicaciones procesadas en una empresa (gestión comercial, gestión de compras, contabilidad, producción, etc.) las transacciones son puestas a disposición de los usuarios, el acceso inicial se hace, por lo general, a través de menús. Según sea el caso, las transacciones autorizan la toma de datos, o la consulta sobre la puesta al día de los datos.

• El acceso a través del arranque de programas en tiempo diferido

Este modo de acceso está, en principio, reservado al personal informá- tico. Implica la posibilidad de conformar trabajos en el entorno de produc- ción por medio del editor. Los JCL y los programas a ejecutar son, por lo general, almacenados en las bibliotecas previamente a su ejecución, pero es igualmente posible, si el autor del programa aspira a ser discreto, crear y conformar un trabajo en tiempo real, sin ninguna copia de seguridad en biblioteca.

• El acceso a través de herramientas de sistemas

Siempre por medio del editor, existe software básico que permite consultar y poner al día los ficheros sin pasar por un programa o una transacción.


Este software básico no deja ninguna pista de las modificaciones llevadas a cabo.

• El acceso a través de herramientas de infocentro

El infocentro pone a disposición de los usuarios todos o parte de los ficheros de explotación para consultas.

El acceso a las herramientas de infocentro se hace bien por las transacciones dedicadas a este efecto, o bien por medio del editor.

b) La auditoría de las técnicas de software de protección

A continuación encontraremos un conjunto de preguntas cuya única finalidad es responder a un objetivo más general: ¿el acceso al entorno infor- mático está limitado sólo a las personas autorizadas? Las respuestas a las preguntas siguientes, ya sean positivas o negativas, deben ser también inter- pretadas en su conjunto.

• P. ¿El acceso a las aplicaciones transaccionales está protegido por contraseña?

El acceso a las transacciones, en principio, está prohibido al personal in- formático. Cada usuario está autorizado a acceder a algunas transacciones, definidas de forma limitada en función de su perfil.

• P. ¿Está prohibido a los usuarios el acceso al editor? Una limitación de acceso eficaz se obtiene orientando a cada usuario, a

partir de su conexión, hacia un menú que contenga sólo las funciones que le están autorizadas.

En algunos casos, la disponibilidad del infocentro implica que los usuarios tengan acceso al editor. En tal caso, se tendrá en cuenta una limitación a las únicas funciones útiles de éste.

• P. ¿Está protegido con contraseña el arranque de programas en tiempo diferido?

No obstante, un control de este estilo representa que la contraseña figure claramente en el JCL. Por esta razón se puede preferir el control de acceso en el editor. Por lo menos, el acceso a las bibliotecas que contengan el JCL de- berá estar protegido.


• P. ¿Está estrictamente reglamentado el acceso al software de sistema de actualización de los ficheros?

En términos de auditoría, los programas básicos son temibles por su facilidad de utilización y por la falta de huellas tras cualquier manipulación llevada a cabo.

Si bien no deben estar prohibidos totalmente (se revelan extremadamente útiles en algunos casos), su uso debe estar reservado a un número extremadamente limitado de personas, y ser objeto de una formalización muy es- tricta (cualquier intervención será referenciada, y se indicarán los objetivos y la naturaleza de las operaciones llevadas a cabo).

• P. ¿La utilización de las herramientas de infocentro impide toda modificación de los ficheros de producción?

El infocentro debe excluir cualquier posibilidad de actualización de los ficheros de producción. En cambio, es del todo previsible entregar a los usuarios una copia de todo o parte de estos ficheros para el análisis con un nuevo proceso eventual. Esta copia estará disponible en el emplazamiento central, o transferida a un microordenador.

• P. ¿Está previsto el control de acceso a los datos?

Se pueden prever en este campo:

— Controles de acceso a los ficheros; a cada fichero se le asociará una lista de usuarios autorizados a acceder a él.

— Controles de acceso específicos en el interior de un fichero, a ciertos tipos de datos. A título de ejemplo, en un fichero de personal, distinguiremos tres niveles de autorización: el más amplio, para los datos administrativos, un segundo más limitado, para el acceso a las remuneraciones, y un tercero, todavía más reducido, para el acceso a los ficheros de cuadros superiores y dirigentes; los sistemas de autorización específicos están previstos en algunos sistemas de gestión de base de datos.

• P. ¿Están previstos los controles de acceso a las bibliotecas? Las bibliotecas de programas en explotación, fuente u objeto, serán trata-

dos con una atención especial.


• P. ¿Están previstos los controles de acceso por volumen-disco físico?

De no ser así, sería imposible reconstruir el contenido de un fichero, ana- lizando los datos que figuran en el disco físico en el que está implantado.

• P. ¿Los controles de contraseñas están controlados en las tablas y no están incluidos «en bruto» en los programas?

Aunque en los grandes sistemas existan programas dedicados al control de las protecciones de acceso, no ocurre siempre lo mismo en los microordenadores, donde los controles algunas veces deben ser programados por los equipos de desarrollo. El auditor comprobará que las contraseñas estén incluidas en las tablas y fácilmente modificables, y no directamente incluidas en los programas, en cuyo caso el sistema sería demasiado rígido para ser eficaz (en efecto, en la segunda hipótesis, es muy posible que las contraseñas no serían jamás modificadas).

• P. ¿El software de control de autorización de acceso permite discernir entre la autorización de consulta de los datos y la autorización de actualización de los mismos?

Las autorizaciones de consulta pueden estar más ampliamente distribui- das que las de actualización.

Ejemplo: sólo la contabilidad introduce los asientos contables, pero otros servicios pueden ser autorizados a consultar las cuentas de terceros.

• P. ¿Se ha implantado un software de control de la seguridad?

Los grandes sistemas IBM son la herencia de un cierto número de programas dedicados al control de la seguridad. Estos programas tienen en co- mún la ventaja de controlar la protección del entorno independientemente del modo de acceso.

Ilustramos esta afirmación por medio de la figura 3. Desde un terminal, se puede acceder a los ficheros y a las bibliotecas de programas de aplica- ción a través de diferentes programas básicos, del sistema de explotación (MVS), del monitor de teleproceso (CICS), del editor (TSO) o de cualquier programa a tiempo diferido introducido en la lista de espera.

Un primer método de control de acceso consiste en integrar en algunos de estos programas básicos un proceso de autorización. De este modo, el monitor de teleproceso CICS posee sus propias tablas de contraseña.

El inconveniente de este método reside en el hecho de que cada programa básico sólo controla los accesos que utilizan sus propios procedimientos. Por


Figura 3. Ejemplo de acceso a los ficheros y a las bibliotecas en el entorno de IBM.

ejemplo: el monitor de teleproceso no permitirá a un informático no autorizado la utilización de las transacciones de consultas de ficheros de personal, pero no le imposibilitará modificar directamente este fichero con la ayuda del editor.

Por el contrario, los programas de control de seguridad permitirán proteger los recursos (ficheros, bibliotecas, volúmenes discos físicos, bases de datos, transacciones, programas), independientemente del modo de acceso utilizado. En la figura 4 se muestra una ilustración de este método.

Citemos como ejemplos de estos programas los tres más difundidos actualmente en el gran sistema IBM:

— RACF del BM; — TOP SECRET de COMPUTER ASSOCIATES — ACF2, también de COMPUTER ASSOCIATES, que está avocado a ser

abandonado progresivamente.

c) Los principios funcionales del control de las autorizaciones de acceso

A continuación, volveremos sobre algunos principios fundamentales del control de las autorizaciones de acceso.


• P. ¿Hay un responsable de autorizaciones de acceso? Este responsable podrá crear los perfiles de cada director o jefe de servi-

cio, y les proporcionará el conjunto de las habilitaciones necesarias para el ejercicio de sus funciones. A continuación, cada uno de ellos podrá, a su vez, definir las habilitaciones que concederá a sus colaboradores.

Figura 4. Ejemplo de un acceso a los ficheros y a las bibliotecas controladas por RACF en el entorno IBM.

•P. ¿Las habilitaciones están acordes con el principio de un buen control interno? El auditor se interesará en particular por:

—El principio de separación de las funciones. —El principio de control jerárquico.


6.1.2 Las medidas de prevención de acceso por identificación del terminal recurrente

Cada vez más, las aplicaciones informáticas autorizan, por razones diversas, las conexiones a la unidad central desde terminales no identificados nominativamente por el sistema:

— El ingeniero de sistemas se conecta desde su miniterminal personal para asegurar un mantenimiento urgente.

— El fabricante se conecta con el sistema central para asegurar el «teleman- tenimiento», o sea, el mantenimiento a distancia.

— La aplicación «administración de ventas» prevé una conexión de los vendedores durante sus viajes desde un microordenador portátil.

— Los clientes se conectan desde puestos miniterminal para obtener informaciones comerciales.

Estos tipos de accesos son extremadamente peligrosos, pues la sola pro- tección contra intrusiones externas reside en la confidencialidad de las con- traseñas.

En algunos casos, las técnicas de identificación del terminal que se conecta permite reducir notablemente el riesgo de intrusión.

• P. ¿Está previsto un procedimiento de identificación física del terminal que se conecta?

Cuando los terminales susceptibles de conectarse a la unidad central son conocidos, es posible memorizar sus señas físicas en una tabla. La tentativa de acceso de cualquier otro terminal será rechazada.

• P. En la utilización de redes públicas, ¿se prevén, si esto es posible, procedimientos de recuperación automática del comunicante?

En algunas aplicaciones, se prevén procedimientos de conexión entre la unidad central y los terminales o microordenadores a distancia a través de una red pública (red conmutada, TRANSPAC, etc.). Citemos por ejemplo:

— Las tiendas que se conectan cada tarde con sus centrales para «teletrans- mitir» el fichero de ventas de la jornada.

— Las direcciones regionales de una empresa que introducen sus pedidos en modo transaccional en el ordenador de la central.


Estos dos ejemplos tienen en común:

— El hecho de que la lista de llamadas posibles (tienda o dirección regional) está identificada.

— Un riesgo de intrusión si un defraudador potencial conociera el número del comunicado y simulara una llamada desde una tienda o de una direc- ción regional.

El procedimiento que permite prevenir este riesgo es, por tanto, el siguiente:

— La lista de números (telefónicos o TRANSPAC) de los comunicantes potenciales se encuentra identificada en la unidad central.

— En el momento de cada llamada, el comunicante se identifica. — Después del control, la unidad central vuelve a llamar al comunicante al

número de abonado conocido registrado en sus propios ficheros.

• P. En el caso de la utilización de una red TRANSPAC, ¿se prevé, si esto fuere posible, la utilización de un grupo cerrado de abonados (GCA)?

El grupo cerrado de abonados es un servicio prestado por FRANCE TE- LECOM en las redes TRANSPAC que permite identificar, para una aplica- ción dada, la lista de abonados autorizados a llamar los unos a los otros. Cualquier llamada de un abonado de la red TRANSPAC que pertenezca al GCA por un abonado que no pertenezca será rechazada.

6.1.3 Las medidas de prevención de acceso a las formas de datos y su soporte de almacenamiento

• P. ¿Los datos más sensibles son objeto de una codificación?

La codificación consiste en la transformación, con la ayuda de un software apropiado, de los datos en un formato que les hace totalmente incom- prensibles para una persona que no disponga del software.

La operación inversa consiste en remitir los datos en su formato inicial antes de su utilización para las aplicaciones.

Veremos que la técnica de la codificación sólo puede ser totalmente eficaz cuando el acceso a los datos o, por lo menos, al software de codificación, esté también reglamentado.


• P. ¿Está previsto para algunos ficheros o programas extremadamente sensibles que sólo sean cargados en el momento de su ejecución?

Esta solución, debido a lo trabajoso de su puesta en práctica, sólo debe ser considerada en casos muy excepcionales. Encontraremos a continuación una ilustración concreta.

Imaginemos que una empresa desea imperativamente mantener confidenciales las remuneraciones de sus cuadros superiores, pero que, por razones prácticas, desea que sus fichas de nóminas estén establecidas por los mismos programas y en los mismos equipos que las de los demás empleados.

El acceso al fichero de personal será, por supuesto, estrictamente reglamentado. Por precaución complementaria, podemos imaginar que los registros que contengan los cuadros superiores sean objeto de una codificación. Pero una codificación sólo es eficaz cuando el software de las codificaciones está también protegido.

Por ello, una solución eficaz consiste en que el software, en vez de estar almacenado permanentemente en los discos, sea conservado en cinta magné- tica (guardada en sitio seguro) y cargado en el momento de la ejecución del programa de nóminas.

El procedimiento del proceso de la nómina será, en este caso, el siguiente:

— El responsable carga el programa de codificación y después ejecuta la aplicación.

— Recupera también los listados de salida. — Tras la terminación del proceso, destruye el software de cifrado en el

disco.

6.2 EL ROBO O LA COPIA DE FICHEROS O SOFTWARE QUE SE ENCUENTRAN EN UNJ3OPORTE DE PAPEL O MAGNÉTICO

Por soporte magnético, se entiende esencialmente las cintas o cartuchos magnéticos que sirven para las copias de seguridad o para las transmisiones de datos.


• P. ¿El acceso al parque de cintas y de cartuchos magnéticos está reglamentado ?

Recordemos que gran número de robos de ficheros están relacionados con una insuficiente protección del acceso a los archivos de cintas.

• P. ¿Para los ficheros «sensibles» se evitan los procedimientos de envíos de cintas o cartuchos «por mensajero» ?

La mayoría de los responsables informáticos tienen en mente por lo menos un caso de ficheros transmitidos por un servicio de entrega (interno o externo a la empresa) y que no han llegado jamás a su destinatario.

• P. ¿Se han incluido en los ficheros «sensibles» trampas que permitan comprobar que no hayan sido divulgados en el exterior?

Cuando algunos ficheros son susceptibles de interesar a otras empresas, de la competencia o no (por ejemplo, los ficheros de clientes), es útil incluir trampas con el fin de evidenciar inmediatamente cualquier utilización no autorizada. Se incluirá, por ejemplo, en el fichero el nombre y la dirección de uno de los directores, voluntariamente mal ortografiados.

• P. ¿Están previstos, si fuere necesario, procedimientos de validación de los datos contenidos en los ficheros sensibles?

El caso más conocido es el de ficheros de remesa de nóminas enviados por las empresas a sus bancos, los cuales deben tener un registro en cabeza de totalización que permita validar el contenido de la cinta enviada.

Recordaremos, a título ilustrativo, que aunque este procedimiento sea, por lo general, conocido por la población informática, ha permitido ya de- senmascarar a defraudadores que habían modificado el importe de su propio salario en el fichero de remesas, sin pensar en modificar el registro de tota- lización.

• P. ¿Existe un software que permita controlar la lectura y la reescritura de las cintas o cartuchos magnéticos?

Es de desear que estén previstos, con la ayuda de un programa de control de la seguridad o de un programa de control del parque de cintas o cartuchos, controles que impidan:

— la reescritura de cintas que contengan ficheros activos,


— la lectura de ficheros almacenados en cintas por personas no autorizadas a acceder a estos ficheros.

• P. ¿Se ha previsto un procedimiento de control específico en el momento de la edición de listados «sensibles»?

Para evitar el riesgo de difusión de informaciones confidenciales, se pre- verá, por ejemplo, que algunos listados sensibles sean editados en presencia del usuario responsable de la aplicación.

• P. ¿Se ha previsto la destrucción sistemática después de la utilización de los listados que contengan informaciones «sensibles»?

Hace algunos años, una ESII se hizo involuntariamente bastante célebre cuando copias de listados confidenciales destinados a uno de sus clientes fueron substraídas de sus papeleras y difundidas en el exterior.

6.3 LA CONEXIÓN FÍSICA CON LAS LINEAS EN LAS CUALES CIRCULAN LOS DATOS

• P. ¿Se ha previsto la codificación de las informaciones confidenciales que circulan en las redes públicas o privadas?

En la medida que es casi imposible controlar la ausencia de conexión no autorizada en el conjunto de la línea física (incluso en el caso de la utiliza- ción de la red TRANSPAC, la unión entre la empresa y el punto de entrada más próximo es propia de ésta), la técnica de la codificación es el medio más eficaz de evitar el robo de los datos que circulan por las líneas.


Tercera parte

EL CONTROL DE LAS

APLICACIONES

INFORMATIZADAS

Hemos presentado en la primera parte de la obra los objetivos y métodos de control de una aplicación informatizada.

La fiabilidad de una aplicación pasa siempre por la fiabilidad del control interno de la función informática propia de ésta. En otras palabras y más concretamente, el auditor podrá aplicar, al entorno de desarrollo y de explo- tación propios de esta aplicación, el conjunto de los controles mencionados en la segunda parte de la obra.

Controlará de esta forma por este sistema:

• Al nivel de la organización general del servicio:

— El seguimiento de los costes. — El seguimiento cualitativo. — Las relaciones con los servicios de usuarios correspondientes. — El respeto a los principios de separación de funciones estudio-explota-

ción-usuarios. — La evolución de los procedimientos administrativos. — La calidad y la perennidad de los equipos de desarrollo, de manteni-

miento y de explotación (analistas de aplicaciones). — Las modalidades de recurso a la subcontratación. — La elección de los equipos físicos. — La existencia de auditorías recientes.

El control de las aplicaciones informatizadas 121

• Al nivel de los procedimientos de desarrollo y de mantenimiento:

— La metodología aplicada. — La calidad del software. — El contenido de la documentación. — Los procedimientos de mantenimiento. — La toma de conciencia, en el momento del desarrollo, de los problemas

de seguridad tales como: control de introducción de datos, integridad de los datos, continuidad de la vía de revisión, etc.

— Los juegos de pruebas previos a cualquier puesta en explotación.

• Al nivel de la producción:

— Los procedimientos de puesta en explotación. — La introducción de datos en masa. — La planificación y el arranque de los trabajos en tiempo diferido. — Los controles de explotación. — Los métodos de recuperación en caso de incidente. — Las copias de seguridad. — Las modalidades de recuperación en unidad externa. — El control de las bibliotecas. — El respeto a las obligaciones declaratorias. — La seguridad física de la unidad y de los materiales dedicados a la aplica

ción.

• Al nivel de la dirección técnica:

— El control de la red. — La administración de las bases de datos. — El control de los microordenadores utilizados en la aplicación. — El infocentro. — La toma en consideración de las obligaciones relacionadas con la seguri-

dad y con la protección de acceso a los datos.

Además, ya hemos presentado en la primera parte de la obra (apartado 1.3.4), los principios generales de control interno relativos al diseño y a la utilización de una aplicación informatizada:

— Los controles de usuarios relativos a la coherencia de los datos y procesos de la aplicación.

— Los controles jerárquicos. — La separación de funciones.


— La continuidad de la vía de revisión. — La existencia de procedimientos de autorización de acceso satisfactorios. — La existencia de validaciones regulares del contenido de los ficheros. — La existencia de juegos de prueba de usuarios previos a toda puesta en

explotación. — La capacidad y la integridad del personal.

Habíamos igualmente mencionado en la primera parte los diferentes en- foques prácticos de auditoría de una aplicación, por otra parte complementarios y que son:

— El examen del control interno. — Los juegos de prueba. — La utilización de programas de auditoría, que tengan por objetivo ya sea

la validación de algunas cadenas de proceso, o bien la detección de ano- malías en los ficheros.

El objetivo de esta tercera parte será presentar, para cada uno de los principales programas de gestión utilizados en una empresa:

— Una descripción resumida de las modalidades habituales de funcionamiento de éste.

— La presentación de los principales puntos clave de control durante una auditoría de la aplicación, aclarando para cada punto el tipo de riesgos así como las modalidades prácticas del control.

— Las posibilidades de utilización de los programas de auditoría con fines de control.

En cambio, no se han tratado, o bien son simplemente citadas a título ilustrativo, las condiciones generales propias de la existencia de un buen control interno (confidencialidad, fiabilidad de la explotación, documenta- ción, etc.) ya especificadas en la segunda parte de la obra.

Por último, veremos en la cuarta y última parte una presentación más concreta de los problemas inherentes de la implementación de la misión: planificación de la intervención, definición de los medios de investigación más apropiados, elección de un programa de auditoría.

El control de las aplicaciones informatizadas 123

Capítulo 7

La contabilidad general, analítica y auxiliar

7.1 PRESENTACIÓN GENERAL DE LA APLICACIÓN

7.1.1 Los principales ficheros

a) El fichero del plan contable

El fichero del plan contable es un fichero permanente que contiene la lista de las cuentas abiertas y sus modalidades de funcionamiento. Contiene, por ejemplo, para cada cuenta:

— El tipo de cuenta (general o auxiliar). — Un código que indica si la cuenta lleva una letra1 o no (es o no marcable). — Eventualmente, el hecho de que los asientos sólo puedan ser de débito o

de crédito. — El título de la cuenta. — Si fuere el caso, la lista de los usuarios o de los servicios autorizados a

acceder a éste.

1. El mareaje o letraje consiste en confirmar los asientos que se compensan entre sí, siendo los asientos no letrados los que justifican el saldo de la cuenta. El término letraje surgió por el hecho de que en sus oríge- nes los contables confrontaban los asientos con ayuda de letras.


b) El fichero de clientes

Cuando se ha previsto una contabilidad auxiliar de clientes, el fichero permanente de clientes suministra para cada cliente su dirección, su nombre, una palabra guía abreviada, su forma de pago, un código de relanzamiento, etc. Además, cuando el fichero de clientes es utilizado igualmente por una aplicación de gestión comercial y de facturación, las informaciones complementarias estarán integradas: comisión acordada, importe pendiente má- ximo autorizado, etc.

c) El fichero de proveedores

El fichero permanente de proveedores especifica para cada uno de ellos su nombre, su dirección, una palabra guía abreviada, la forma de pago, el nombre del corresponsal habitual, etc.

d) El fichero de los asientos contables Este fichero contiene el detalle de los asientos contables introducidos.

Encontraremos, por ejemplo, para cada asiento su tipo (débito o crédito), su importe, su texto, su fecha de introducción, su fecha contable.

Mencionamos, igualmente, que entre los programas:

— Los ficheros de asientos de contabilidad general y auxiliar no están de ningún modo relacionados. La contabilidad auxiliar da lugar a la transformación automática de asientos de centralización en contabilidad general.

— Sólo existe un fichero único de asientos contables, que incluye a la vez los asientos de contabilidad general y auxiliar. No existen, por lo tanto, registros físicos que contengan asientos de cen- tralización. Éstos son reconstruidos, si fuere necesario, en el momento de cada edición partiendo del detalle de los asientos de contabilidad auxiliar.

e) El saldo de las cuentas

En este nivel encontraremos varias opciones. Algunas veces, hay un fichero de saldos. En otros sistemas, estos saldos

están incluidos en el fichero de plan contable. Por último, una tercera posibilidad consiste en no llegar a hablar propiamente de saldo, pudiendo éste ser reconstruido en el fichero de los asientos contables a partir de un saldo ini-

La contabilidad general, analítica y auxiliar 125

cial a principio del período, que figura en un asiento de «saldo inicial» y del conjunto de los asientos en la cuenta.

f) Otros ficheros

Hay, a veces, ficheros intermediarios que contienen los asientos que es- tán pendientes de validación definitiva.

7.1.2 Los procesos

a) La recogida y validación de los asientos

Los asientos se recogen de forma interactiva.2 Desde su recogida, son controlados (existencia del número de cuenta, igualdad debe-haber, etc.). Después del control de los asientos, según los programas:

— puede ocurrir que éstos sean directamente incluidos en el fichero de los asientos contables;

— o bien integrados en un fichero tampón, que contiene un conjunto de tomas de datos, cuyos asientos sólo serán traspasados a las cuentas después de una validación definitiva del conjunto.

La segunda solución, que presenta el inconveniente de un proceso semi- diferido, es preferida a veces, en la medida en que permite modificar y suprimir asientos mientras no hayan sido validados definitivamente.

Vemos también que las modalidades de recogida y de controles específi- cos pueden estar previstas por tipo de diario, o sea:

— Generación automática del asiento de contrapartida para las compras y las ventas.

— Limitación de los asientos de recogida en el diario de compras en las cuentas del grupo 4 y 6, y de los asientos de recogida en el diario de ventas en las cuentas del grupo 5 y 7.

Para las cuentas marcables, distinguimos por lo general:

— El mareaje manual: en el momento de la recogida de un asiento, el contable indica los números de los asientos marcados por este sistema.

2.0 sea, en tiempo real, desde una pantalla conectada a la unidad central.


— El mareaje automático que proviene de un algoritmo de cotejo informati- zado de los asientos.

El mareaje automático con una letra, si bien constituye un confort para los usuarios, no obstante, se debe manejar con precaución teniendo en cuenta el riesgo de mareaje «abusivo».

b) Las consultas en tiempo real Éstas son, por lo general, de tipo estándar:

— Plan contable. — Saldo de cuentas. — Detalle de los asientos de una cuenta durante un período determinado.

Para las cuentas auxiliares, el sistema ofrece generalmente la elección entre la consulta del conjunto de los asientos y la consulta de los asientos no marcados.

Los diarios de recogida raras veces se pueden consultar por pantalla.

c) Las ediciones

Corresponden, en la mayor parte, a las obligaciones legales del código de comercio.

• El borrador de registros (facultativo)

Suministra diariamente, o por lotes de tomas de datos, la lista de los asientos.

Permite, por ejemplo, una validación por parte de los usuarios de las operaciones recogidas por éstos, o también el control por un superior jerárquico. A veces, podrá servir para la recuperación de un fichero destruido por la gra- bación de la última copia de seguridad y la recuperación de los asientos a partir del borrador.

• Los diarios (obligatorios)

Para cada diario, tendremos cada mes el detalle por orden cronológico de los asientos recogidos.

La elección del número de diarios de registro se deja al servicio de contabilidad. Generalmente, en una empresa, existe un diario por ciclo de operaciones, de la forma siguiente:


— Un diario de compras. — Un diario de ventas. — Un diario de tesorería. — Un diario de imovilizaciones. — Un diario de pagos o remuneraciones. — Un diario de operaciones diversas, en el cual están todos los asientos no

imputados a uno de los diarios precedentes (por ejemplo, los asientos de cierre de ejercicio).

• Los libros mayor (obligatorios)

El mayor da mensualmente el detalle por cuenta y por orden cronológico de los asientos recogidos en la cuenta.

Es algunas veces útil prever a final del año una edición del conjunto de los asientos del año.

• El balance (facultativo)

A pesar de que no esté incluido en los listados exigidos por el código de comercio, todos los programas contables prevén la edición de un balance de cuentas especificando para cada cuenta:

— Su saldo inicial. — El total de los asientos deudores y acreedores posteriores al inicio del

ejercicio. — El total de los asientos deudores y acreedores del mes. — El saldo final.

• Los listados específicos de la contabilidad auxiliar de clientes

Además de los diarios, libros del mayor y balances auxiliares, se preverá por lo general la edición:

— de extractos de cuentas destinados a los clientes; — de efectos (cuando se trata de la forma de pago del cliente); — de un listado justificativo del saldo de las cuentas de clientes, que in-

cluya por cliente el detalle de los asientos no marcados; — de cartas de reclamación para las facturas no liquidadas, con varios nive-

les de reclamación; — de un «balance antiguo», distribuyendo por anterioridad el saldo de los

clientes. El balance «antiguo» constituye un instrumento de auditoría contable indispensable;


— la nota de remesa al cobro de los talones recibidos; — listados de seguimiento del riesgo cliente (saldo de la cuenta de clientes

+ efectos a cobrar + efectos descontados no vencidos).

En el caso de que la empresa esté sujeta al IVA sobre sus cobros, será necesario prever la posibilidad de separar dentro del diario los pagos de clientes y el IVA ingresado cada mes sobre los cobros.

En caso de pago sobre los cargos, es el diario de ventas el que permite separar sin dificultad el IVA reservado a la administración.

• Los listados específicos de la contabilidad auxiliar de proveedores

Además de los diarios, los libros de mayor y balances auxiliares de proveedores, también, por lo general, se prevé la edición:

— de efectos-cheque y pagarés emitidos, según sea la forma de pago; — de avisos de remesa; — del diario de los pagos; — de un listado justificativo del saldo de las cuentas de proveedores.

El IVA a recuperar será recogido ya sea del diario de compras o del de pagos.

• Los listados específicos del control de efectos

Para los efectos a cobrar, se tratará por ejemplo de la edición:

— de efectos en cartera, distribuidos por su vencimiento, — de listas de remesas a descuento, eventualmente después de seleccionar

los efectos a ser descontados por un importe total dado, — las listas de remesas al cobro.

Para los efectos a pagar, podemos citar:

— la edición de los efectos por su vencimiento, — la edición de avisos de domiciliación.

d) La contabilidad analítica

Sólo nombraremos de forma sucinta los procesos y listados propios de la contabilidad analítica en la medida en que este término cubre a veces especificaciones muy diversas de una empresa a la otra.


Por lo general, se prevé la imputación de un código de contabilidad analí- tica en la recogida de los asientos de cargo y de producto en contabilidad general. Para algunos tipos de asientos, es además posible generarlo automáti- camente. De igual forma es necesario prever la recogida de asientos «puramente analíticos», o sea, que no tengan ninguna incidencia en la contabilidad general.

Según sea el caso, habrá o no creación de un fichero específico de asientos de contabilidad analítica.

Al final del mes, volveremos a encontrar por la cuenta analítica los listados análogos a los de la contabilidad general, o sea: — Diarios analíticos. — Mayores analíticos.

Pueden ser necesarias prestaciones más sofisticadas, como: — Afectación con fines de control presupuestario, presupuestos de las

cuentas analíticas y comparación mensual de los presupuestos y de los gastos.

— La contabilidad conocida como «de obra», siendo los resultados analíti- cos seguidos por obra: las cuentas propias de una obra se transportan de un ejercicio al otro hasta el final de la misma, en lugar de ser reinicializa- das cada año.

7.2 LA AUDITORIA DE LA APLICACIÓN

7.2.1 La auditoría de las posibilidades funcionales

Auditar las funciones de un programa significa comprobar que el mismo responde a las necesidades específicas de la empresa. No obstante, en el caso particular de un programa contable, las necesidades se diferencian relativamente poco de una empresa a otra, y son, sobre todo, las que se acaban de citar.

Además, es preferible que algunas funciones estén previstas en el diseño del software con el único fin de garantizar la fiabilidad.

De un modo general, aclaramos a continuación un cierto número de puntos que el auditor tendrá todo el interés en controlar.

a) Los ficheros permanentes Si bien la mayoría de los programas prevén un fichero de plan contable,


algunos crean automáticamente las cuentas a medida que las van utilizando. Este procedimiento de una gran flexibilidad es evidentemente peligroso puesto que limita los medios de control de los asientos recogidos.

Los ficheros de clientes y proveedores son en sí mismos indispensables cuando se propone una contabilidad auxiliar.

b) La recogida de asientos contables

La fiabilidad de la recogida de asientos contables requiere algunos desarrollos.

• El control de capacidad

El software debe permitir la atribución a cada usuario sólo de aquellas autorizaciones que necesite.

Un control de capacidad eficaz se consigue:

— Atribuyendo a cada usuario una contraseña y limitándola a algunas tareas y a algunas cuentas.

— Desarrollando, si fuere el caso, transacciones específicas.

De este modo, el contable encargado de los proveedores sólo tendrá acceso al diario de compras, estando a la vez limitado a las cuentas del grupo 4 y 6.

• Los controles propios de la recogida de asientos

Citemos a título de ilustración algunos controles «tradicionales»:

— Existencia de los números de cuenta en el plan contable, o sea, el título de la cuenta se agrega automáticamente para el control visual.

— Igualdad de los débitos y créditos. — Sentido del asiento (cuando la cuenta ha sido marcada para recibir sólo

asientos deudores o acreedores).

Cabe citar también, aunque sea lento, el control por totalización de grupos de registros. Al final del registro de un grupo de asientos, el operador indica el importe total de los asientos llevados a cabo, que habrá calculado con anterioridad. El ordenador compara este importe introducido con su propia totalización. Una diferencia revela, bien un error en el registro de un importe, o bien la omisión de registro de algunos asientos.

Este procedimiento, que había estado ampliamente desarrollado por los operadores en la época de los registros masivos, no está desprovisto de inte-


res en el caso de una toma «inteligente» por parte de los contables, por poco que éstos adopten un método de registro por lotes, agrupando así todos sus trabajos informáticos en un mismo momento de la jornada.

• La fecha contable

La problemática de control de la fecha contable merece algunas consideraciones ya que la ausencia de este control está en el origen de numerosas horas de trabajo inútil.

Planteemos el problema: se permite, en todos los programas contables, registrar los asientos cuya fecha contable es anterior a la fecha del registro de la operación. Por ejemplo, a principio del año, es frecuente llevar a cabo el registro de los asientos correspondientes al cierre del ejercicio anterior. De igual modo, a principio del mes, los cierres pueden ser registrados por impu- tación al mes contable anterior.

Imaginemos ahora que se han registrado los asientos cuya fecha contable corresponda a un mes anterior, cuyo diario y mayor legales ya hayan sido editados. Supongamos, por ejemplo, que nos encontramos a finales de marzo y que registramos los asientos con fecha contable de febrero, cuando el diario y mayor de febrero ya hayan sido impresos y archivados. Imagine- mos además que, debido al diseño de los programas de edición, estos asientos no figuran en el diario ni en el mayor de marzo en el momento de su edi- ción. Resulta, por tanto, que los saldos de las cuentas han sido modificados por asientos que no aparecerán jamás en los listados contables legales, a reserva de retirar los del mes de febrero. La contabilidad de la empresa puede ser considerada como irregular, con las consecuencias que esta constatación puede acarrear, en particular cuando este tipo de anomalía se produce en repetidas ocasiones.

¿Cómo prevenirse contra este riesgo? La solución elegida habitualmente consiste en introducir en el sistema un parámetro que corresponda al mes contable en curso. El software rechaza entonces cualquier asiento cuya fecha contable sea anterior a esta fecha parámetro. Cuando los listados contables del mes en curso son editados, la fecha parámetro se pone al día, ya sea automáticamente, o bien manualmente por los usuarios.

En el momento de estos controles, el auditor se preocupará no solamente de la comprobación de la existencia de esta fecha parámetro, sino también de asegurarse que ésta se encuentra correctamente introducida. En efecto, y por más sorprendente que esto pueda parecer, la cantidad de programas mal di- señados o mal utilizados en la materia está lejos de ser despreciable.


• La simetría de los asientos

Es deseable conservar en los ficheros de asientos contables la «firma» de éstos, o sea, la identificación del usuario que haya introducido el asiento. Esta «firma» facilitará las búsquedas en caso de litigio en una operación.

Por supuesto, ésta sólo será eficaz cuando las identificaciones que permitan el acceso al sistema sean individualizadas y cuando las contraseñas correspondientes sean realmente confidenciales.

c) La modificación de los asientos contables

Por deseo de seguridad, después de que un asiento es validado, cualquier modificación debe estar prohibida. En caso de error, la corrección se hará por contrapartida del asiento erróneo e introducción del asiento correcto.

A título de anécdota, una vez audité un software que no sólo aceptaba modificaciones de asientos antiguos, incluso en los ejercicios anteriores ce- rrados, sino que además no llevaba a cabo ningún control en los asientos modificados. Los ficheros de archivos de los ejercicios anteriores no correspon- dían ya a las cuentas publicadas, y lo que es más,...¡los débitos no eran iguales a los créditos!

d) El cierre del ejercicio

La flexibilidad y la fiabilidad de un programa contable imponen que sea posible registrar, al principio del ejercicio y al mismo tiempo, los asientos del ejercicio y los asientos de cierre del ejercicio anterior.

En el momento del cierre definitivo:

— tratándose de las cuentas no marcables, un asiento de suma anterior se calcula automáticamente y será el primer asiento del ejercicio siguiente,

— tratándose de las cuentas marcables, el detalle de las cuentas no marcadas se toma en el ejercicio siguiente en la contabilidad auxiliar.

e) La generación automática de asientos

Los sistemas contables a menudo tienen que aceptar asientos que han sido generados automáticamente:

— Asientos de abonos que hayan sido objeto de un «parametraje» inicial y que se traspasa a la contabilidad cada mes.

— Asientos generados por aplicaciones ascendentes: pagas, facturación, gestión de imovilizaciones, etc.


Estos asientos deben estar claramente individualizados y ser objeto de una edición en los diarios correspondientes, a fin de facilitar el control.

f) Las disposiciones legales y fiscales

• Las disposiciones del plan general de contabilidad francés

Recordemos las disposiciones del plan general de contabilidad francés relativas a la utilización de los procesos informatizados.*

Estas disposiciones figuran en la sección IV del plan contable de 1982, hecha obligatoria por un decreto del 27 de abril de 1982.

«1. La organización del sistema de proceso debe garantizar todas las posibilidades de un control eventual.

2. El sistema de proceso debe establecer, en papel o eventualmente en cualquier soporte que ofrezca las condiciones de garantía y de conservación definidas en lo referente a prueba, los listados periódicos numerados y fe- chados recapitulando en orden cronológico todos los datos introducidos en él, bajo una forma que impida cualquier inserción intercalada o bien cualquier supresión ulterior.

3. El origen, el contenido y la imputación de cada dato deben estar indicados claramente. Además, cada dato debe estar basado en un justificante constituido por un documento escrito.

Cuando los datos son recogidos por un procedimiento que, de lo contrario, no dejaría ninguna pista, deben estar igualmente contrastados por un documento escrito fácilmente inteligible.

4. Debe ser posible, en todo momento, reconstruir a partir de los datos definidos a continuación los elementos de cuentas, listados e informaciones sujetos a la verificación o, a partir de tales cuentas, listados e informaciones, encontrar los datos introducidos.

De este modo se debe poder justificar cualquier saldo de cuenta por medio de un extracto de los asientos que le han dado origen, a partir de otro saldo de esta misma cuenta. Cada uno de estos asientos debe llevar una referencia que permita la identificación de los datos correspondientes.

5. El ejercicio de cualquier control debe comportar un derecho de acceso a la documentación relativa a los análisis, a la programación y a la ejecución de los procesos con el fin de proceder, entre otras cosas, a los tests necesarios.

(*) El PGC español no contempla este tipo de disposiciones.


6. Los procedimientos de proceso automatizados de las contabilidades deben estar organizados de manera que permitan controlar si las exigencias de seguridad y de fiabilidad requeridas en el tema han sido del todo respetadas.»

Hemos subrayado ya (en el apartado 1.3.4) que el artículo 4 consagra la noción de continuidad de la vía de revisión en los procesos contables. Los artículos 1, 5 y 6, relativos a las posibilidades de un control externo, serán comentados en el apartado 13.1.1.

El artículo 2 aclara las modalidades de edición del diario, o sea: ediciones periódicas numeradas y fechadas, respecto del orden cronológico de los asientos introducidos, imposibilidad de modificaciones posteriores.

Por último, el artículo 3 es relativo a la necesidad de conservar los justificantes para cada asiento contable.

• Las disposiciones del código de comercio

El artículo 16 del código de comercio francés prescribe que los libros contables obligatorios deben ser conservados en su formato original durante diez años a contar desde la fecha de la última inscripción en el libro.*

Los justificantes de la contabilidad deben igualmente ser conservados durante diez años. Si bien las facturas de compra deben ser archivadas en su forma original, es cada vez más frecuente que las facturas emitidas lo sean en forma de microfichas.

Por último, y de una manera general, notaremos que la responsabilidad del archivo de los libros contables y de los justificantes debe corresponder a los servicios de contabilidad y no al servicio de informática.

• Las disposiciones fiscales en materia de salvaguarda

Sobre este punto nos remitiremos al apartado 4.8, donde se mencionan las posibilidades de control informático por parte de la administración fiscal.

• Las disposiciones fiscales en materia de intercambio de datos informatizados (IDI)

El artículo 47 de la Ley de Finanzas corregida para 1990 introdujo, por primera vez, la noción de intercambio de datos informatizados en lo referente a facturación y justificación de facturas emitidas.

(*) Equivale al Artículo 30 del Código de Comercio español.


De este texto, entre otras cosas, recordaremos que:

— Bajo reserva de ser aprobadas por la administración fiscal, las facturas transmitidas por vía informática son consideradas como originales.

— Las empresas emisoras y receptoras deben conservar las facturas, por un primer período de tres años (período de prescripción) en un soporte mag- nético, después por un período adicional de tres años (durante el cual la administración sólo tiene un derecho de comunicación) en una forma definida por la empresa.

— Las listas de mensajes emitidos y recibidos deben ser editadas por las empresas que emitan y reciban las facturas.

— La administración dispone de un derecho de control de la aplicación del procedimiento.

g) La contabilidad auxiliar de clientes El auditor se interesará por la existencia y por la fiabilidad de algunos lis-

tados descritos anteriormente (apartado 7.1.2c), entre otras cosas:

— Las cartas de reclamación de pagos. — El balance atrasado. — El seguimiento del riesgo cliente. — La justificación del saldo de la cuenta de cliente.

Con relación a este último extracto, que suministra por cliente el detalle de los asientos no marcados, es decir, por lo general las facturas pendientes, citaremos un problema que encontramos con frecuencia.

Utilizado con fines de gestión (seguimiento de impagados), se edita a pe- tición y la fecha de tirada tiene poca importancia. Pero, también puede servir para justificar el saldo de la cuenta de clientes al cierre de un mes o de un ejercicio contable.

Ahora bien, el extracto de justificación de las cuentas de clientes al 31 de diciembre, si lo queremos cotejar con el balance, sólo puede ser editado al final de la introducción, a principio del ejercicio, de todos los asientos de cierre del ejercicio precedente. Pero es igualmente probable que sean introducidos, a principio del ejercicio, asientos del nuevo ejercicio marcando los asientos no marcados al 31 de diciembre anterior. Por ejemplo, se recibirá y registrará al 15 de enero el pago de un cliente que venga de liquidar una factura emitida en diciembre. Imaginemos, ahora, que las últimas facturas emitidas han sido registradas con retraso a finales de enero, que el ls de febrero paramos definitivamente las cuentas del ejercicio anterior y que, simultánea- mente, se edita el extracto de los asientos no marcados el 31 de diciembre.


La factura del 15 de diciembre pagada y marcada el 15 de enero deberá aparecer como no marcada en este extracto, ya que ella será considerada en el balance como pendiente de pago.

En el plan técnico, esto significa que es necesario conservar en los ficheros, no solamente el hecho de que los asientos sean marcados o no, sino igualmente la fecha de la imputación del mareaje.

Por lo general, el auditor se limitará en un primer momento, a comprobar que el saldo de la cuenta general de clientes pueda justificarse por medio de un detalle de asientos no marcados.

h) La contabilidad auxiliar de proveedores

El auditor controlará la existencia de los principales extractos descritos anteriormente (apartado 7.1.2 c) y la posibilidad de justificar el saldo de la cuenta general de proveedores.

i) La gestión de los efectos a pagar y de los efectos a cobrar

Como en el apartado anterior, el auditor controlará la existencia de las principales prestaciones (vencimientos, remesas a descuento y a cobro, aviso de domiciliación, etc.) y la posibilidad de justificar las cuentas generales de centralización.

7.2.2 La auditoría de la utilización de la aplicación

a) La validación de los datos introducidos

Los «borradores de registro», o sea, los extractos recuperables del registro servirán:

— para la validación de los datos introducidos por los usuarios, compa- rando con los justificantes o facturas,

— para un control por parte de un superior jerárquico.

b) La validación de los procesos

Citemos algunos de los principales controles que deben ser llevados a cabo cada mes:

— La suma de los movimientos en los borradores diarios de registro deben ser iguales a la suma de los movimientos en los diarios mensuales.


— La suma de los movimientos en los diarios mensuales debe ser igual a la suma de los movimientos en los libros de mayor mensuales.

— El total de los saldos iniciales deudores y acreedores del balance de un mes, adicionado a los movimientos del mes, debe ser igual al total de los saldos iniciales deudores y acreedores del balance del mes siguiente.

— El saldo de la cuenta general de clientes debe ser igual a la suma de los saldos de las cuentas auxiliares de clientes.

— El saldo de la cuenta general de proveedores debe ser igual a la suma de los saldos de las cuentas auxiliares de proveedores.

— Los saldos de las cuentas auxiliares de clientes y proveedores deben estar justificadas por medio de un detalle de los asientos no marcados.


Capítulo 8

El ciclo de las ventas

A lo largo de este capítulo y de los dos siguientes trataremos de aplicaciones muy relacionadas entre sí, son las siguientes:

— la gestión comercial y la facturación, o sea, el ciclo de ventas; — la gestión de aprovisionamientos, o sea, el ciclo de compras; — la gestión de existencias propiamente dicha, que constituye de alguna

forma el nudo central del conjunto.

Las cadenas de proceso propias de la gestión de producción, por lo general específicas a cada tipo de actividad, incluso a cada empresa, no serán es- tudiadas en esta obra.



a) Los ficheros de existencias Contienen, para cada artículo, además de sus referencias (código, deno-

minación) y la cantidad en existencia, informaciones que varían mucho se- gún el diseño de la aplicación, o sea: cantidad reservada para pedidos de clientes, cantidades pedidas en espera de entrega por parte de los proveedores, acumulado mensual de los movimientos de entradas y salidas, etc.

El ciclo de las ventas 139

b) El fichero de los movimientos de existencias

Incluido o no en el fichero de existencias, contiene, por tipo de movimiento (venta, compra, regularización, etc.), el detalle de los movimientos que hayan podido afectar las cantidades en los ficheros de existencias.

c) El fichero de precios

Común o no con el fichero de existencias, contiene para los productos comercializados, el detalle de las condiciones de venta: precio unitario, condiciones de descuentos en función de las cantidades vendidas, etc.

d) El fichero de cliente

Contiene para cada cliente los datos comerciales que le conciernen, tales como: razón social, dirección, nombre de los interlocutores, categoría de cliente, descuentos acordados, importe pendiente máximo autorizado, cifra de negocios, etc.

e) El fichero de las cuentas de clientes

Sacado de la contabilidad auxiliar de clientes, suministra el detalle de los asientos en las cuentas de clientes.

f) El fichero de los pedidos de clientes

Este fichero contiene el detalle de los pedidos de los clientes. Evoluciona con éstos, y un indicador permite conocer el estado del pedido, como por ejemplo: intención, pedido en firme, pedido servido (el albarán de entrega ha sido editado), pedido facturado.

Para cada pedido encontraremos:

— Un encabezamiento con el nombre del cliente, la dirección de factura- ción, las condiciones de facturación (las condiciones derogatorias respecto a las condiciones estándar del fichero de clientes pueden igualmente ser acordadas a nivel de cada pedido), el importe sin impuesto, el importe con impuestos incluidos, etc.

— Las líneas de pedidos por artículo, o sea, código del artículo, cantidad, descuento, etc.

De forma general, la gran mayoría de los datos que figuran en el fichero de los pedidos son automáticamente extraídas de los ficheros básicos (artícu-


los y clientes), con posibilidad de activación del proceso de información de- rogatoria en el momento de la introducción de los datos.

Además, en algunos casos, el fichero de facturas emitidas es un fichero distinto del de pedidos, pero con una estructura casi idéntica.

8.1.2 Los procesos

Las modalidades de introducción de datos están en función de la organi- zación de la empresa: toma de datos interactiva por los propios vendedores, por las secretarias comerciales, o bien una introducción de datos en microordenadores portátiles con transmisión regular de los pedidos al ordenador central (el caso de los comerciales itinerantes, etc.).

La aplicación controla la presencia de existencias disponibles en los ficheros y, en caso de necesidad (según el plazo de entrega) procede a hacer reservas de existencia.1 A menudo los albaranes de preparación destinados a los empleados del almacén son editados. Si se da el caso, las «devoluciones» se preparan durante el proceso nocturno. Los empleados del almacén preparan los pedidos y después registran las cantidades preparadas. Tras la intro- ducción de los datos, editan el albarán de entrega que acompañará el envío. Las existencias se actualizan automáticamente a partir de la salida de las mercancías.

Desde el momento en que un pedido ha sido servido, es posible pedir su facturación. Según la organización que se elija, la factura será editada en tiempo real, o bien en tiempo diferido. Además, a menudo ambas posibilidades son posibles, o sea: facturación inmediata para las ventas en el mostrador y diferida para las demás.

La facturación implica, en principio, la actualización de las cuentas de clientes, así como, mensualmente, la edición de los diarios de ventas.


8.2.1 La adecuación de las prestaciones a las necesidades de los usuarios

Las prestaciones detalladas del software de gestión comercial son, por lo

1. En algunos casos, en particular cuando el ciclo de fabricación es corto, no hay existencias y son los pedidos los que determinan la producción de las mercancías pedidas. Éste será, entre otros, el caso de pedidos de mercancías perecederas.


general, específicas a cada empresa. Nos limitaremos a mencionar a título de ilustración algunos puntos «sensibles»:

— La existencia de un control de pedidos. — La posibilidad de efectuar reservas de existencias. — La posibilidad de editar facturas en tiempo real.

8.2.2 La separación de funciones

En el caso particular del ciclo de ventas, los principios de separación de funciones conducen a distinguir:

— La actividad comercial. — La administración de ventas, o sea, el seguimiento administrativo de las

operaciones. — La expedición de las mercancías. — El seguimiento del riesgo-cliente.

Por lo general, la facturación está automatizada, es puesta en marcha pe- riódicamente por la administración de ventas y pone en marcha la actualiza- ción de las cuentas de clientes.

El seguimiento de las cuentas de clientes es, en sí mismo, de incumbencia de los servicios de contabilidad.

De una forma práctica, el respeto del principio de separación de las funciones se manifiesta a través de la limitación de acceso a cada transacción solamente a personas autorizadas. De este modo:

— el único que está autorizado a modificar los importes pendientes máxi- mos por cliente será el responsable del crédito-cliente;

— el único que está autorizado a introducir los albaranes de entrega será el responsable de las expediciones.

8.2.3 Los medios del control jerárquico

a) El control jerárquico a priori Por lo general, consistirá en pedir que los pedidos para los cuales se ha-

yan concedido condiciones especiales a los clientes, comerciales (comisiones) o financieras (descuentos, pago aplazado), sean objeto de una autoriza- ción por parte del superior jerárquico del vendedor (jefe de sección, director


comercial, etc.). Del mismo modo, los pedidos que sobrepasaran el importe pendiente autorizado para el cliente podrían necesitar una autorización jerárquica.

b) El control jerárquico a posteriori Este control puede ser llevado a cabo a partir de una lista exhaustiva de

las operaciones procesadas: facturas y abonos emitidos, diario de ventas, diario de abonos.

No obstante, a menudo las ediciones por excepción facilitarán el control por parte del responsable jerárquico, o sea:

— Lista de los abonos superiores a un cierto importe. — Lista de las entregas que estén amparadas por las condiciones derogato-

rias de facturación. — Lista de clientes cuyos valores pendientes de pago sea superior a un im-

porte determinado autorizado, o bien que supere el importe pendiente máximo autorizado para este cliente.

8.2.4 El seguimiento del riesgo-cliente

El riesgo mayor consistiría en que se aceptaran, por parte de los comerciales, pedidos de clientes para los cuales la empresa tenga todas las razones para rechazar, bien por el hecho de que el cliente esté en una situación difícil, o bien porque su importe pendiente de pago ya sea bastante importante. Un procedimiento apropiado podría ser el siguiente:

— El servicio de crédito define para cada cliente un importe pendiente de pago máximo autorizado, en función de los datos financieros y comerciales conocidos y lo introduce en fichero.

— Los pedidos que hacen sobrepasar el importe pendiente máximo son rechazados, salvo cuando están autorizados por un responsable capacitado.

— Se editan con regularidad los listados de importes pendientes de pago para su análisis.

8.2.5 El seguimiento de la cifra de negocios y de los márgenes

Ya hemos mencionado la utilidad de instrumentos de control jerárquico, por ejemplo, para el director comercial, en lo relativo a las condiciones con- cedidas por los comerciales a sus clientes.


Muy a menudo, es de esperar que la empresa disponga de estadísticas mensuales de las cifras de negocio y de los márgenes realizados:

— por cliente, — por vendedor, — por zona geográfica, — por producto o por familia de producto.

Las informaciones resumidas deben ser, de hecho, transmitidas a la Di- rección General por el auditor de gestión. Estas estadísticas, por supuesto, interesarán también al Director Comercial, para quien supondrán un instrumento privilegiado de dirección de la política comercial.

Los listados específicos se destinarán eventualmente al cálculo de las comisiones de los vendedores.

Tratándose del conjunto de estos listados estadísticos, además de su inte- rés y del hecho de que cubren la totalidad de las necesidades, el auditor se preocupará por la manera de controlar la coherencia de unos con otros.

8.2.6 El registro de los pagos de clientes

Sin volver sobre el conjunto del procedimiento de seguimiento y de control de las cuentas de cliente (capítulo 7), vale la pena recordar el caso espe- cífico del registro de pagos. La organización elegida debe garantizar a la vez la fiabilidad del procedimiento, con el fin de evitar cualquier riesgo de pér- dida o de robo de un pago y la rapidez de registro, a fin de evitar cualquier pérdida de tesorería en los plazos de remesa a bancos.

El software, por lo general, permitirá una introducción de datos interactiva de los pagos, con mareaje de las facturas correspondientes, y edición de los listados de remesa a banco. Con el fin de no retrasar el cobro, los pagos no imputables son destinados a una cuenta de pendientes de impu- tación.

8.2.7 La exhaustividad de las facturas y abonos emitidos

El control de la exhaustividad de las facturas emitidas sobrepasa ampliamente el marco estricto de la auditoría de una aplicación informatizada. So- lamente la definición de los procedimientos administrativos apropiados, y la realización de inventarios físicos regulares permitirán estar seguro de que toda mercancía que ha salido de las existencias ha implicado la emisión de un albarán de entrega y de una factura. No obstante, los programas o los con-


troles apropiados facilitarán la aplicación de estos procedimientos. Distin- guiremos dos tipos de organización.

• Cuando los albaranes de entrega se efectúan manualmente en talonarios matriz y son, después, introducidos para la edición de facturas informatizadas

No se deberá autorizar ninguna salida de mercancía sin que se haya hecho un albarán de entrega. Estando los talonarios matriz numerados de antemano, se introducirán los números de albarán de entrega en el sistema, el cual editará mensualmente la lista de los que faltan en la secuencia de los nú- meros de albaranes utilizados.

• Cuando los albaranes de entrega son procesados deforma informatizada

No se deberá autorizar ninguna salida de mercancía sin que vaya acom- pañada de un albarán de entrega. Un procedimiento manual sustitutorio, con la confección del albarán a partir de un talonario matriz, podrá ser autorizado para anticipar los casos de indisponibilidad del equipo.

Cualquiera que sea el procedimiento de la confección del albarán de entrega, cada entrega deberá dar lugar rápidamente a la facturación y registro en contabilidad, salvo en un caso especial, estrictamente individualizado y justificado.

De este modo:

— Los albaranes de entrega sólo podrán ser utilizados por un responsable jerárquico debidamente autorizado; los albaranes de entrega anulados aparecerán en un listado resumen mensual para ser controlados.

— La emisión de facturas a partir de las entregas estará automatizada; sólo un responsable jerárquico autorizado podrá pedir el saldo de la factura- ción.

— La emisión de la factura implica simultáneamente la actualización de la cuenta del cliente, sin posibilidad de derogación.

8.2.8 La separación de los ejercicios contables

Con el fin de respetar el principio de separación de los ejercicios contables, los servicios financieros necesitan generalmente de listados que les permitan pasar los asientos de cierre tales como:


— Lista de las mercancías servidas al 31 de diciembre y que están pendientes de facturación.

— Lista de las facturas emitidas al 31 de diciembre cuya mercancía todavía no haya sido servida (cuando el procedimiento autoriza este tipo de caso).

— Lista de mercancías devueltas por los clientes antes del 31 de diciembre y para las cuales no se haya emitido aún una nota de abono.

Cuando se emiten estados mensuales, éstos serán necesarios cada fin de mes.

8.3 LA UTILIZACIÓN DE LOS PROGRAMAS DE AUDITORIA

Citaremos a continuación algunos ejemplos de programas que podrán ser aplicados por el auditor, para análisis complementarios durante sus controles.

a) Búsqueda de facturas para las cuales las condiciones pactadas con el cliente sean diferentes de las condiciones normales que figuran en el fichero de clientes

Las condiciones normales de facturación del cliente pueden ser modificadas por regla general en el momento del registro de cada pedido. El objetivo es verificar que las condiciones pactadas por los vendedores están de acuerdo con la política comercial.

Se confrontarán las facturas emitidas durante un cierto período con el fichero de clientes, a fin de verificar que las condiciones pactadas (que se en- contrarán en el encabezamiento de la factura) son idénticas a las condiciones que figuran en el fichero de clientes.

A la vez, se podrá controlar las condiciones comerciales (descuentos) y, si fuese el caso, las condiciones financieras (plazo de pago, porcentaje de descuento).

No debe olvidarse que cuando las facturas son analizadas en un período importante, es posible que las condiciones generales que figuran en el fichero de clientes hayan sido modificadas durante el período.

b) Búsqueda de las líneas de facturas emitidas para las cuales el precio unitario de los artículos sea diferente del que figura en el fichero de precios

El objetivo será aquí verificar que los precios unitarios facturados estén de acuerdo con las listas de precios. Las diferencias podrían tener su origen


en errores de software, o en condiciones más favorables acordadas por los comerciales.

Con este fin, se confrontarán las líneas de artículos de las facturas emitidas durante un período dado con el fichero de listas de precios.

Cabe mencionar que cuando las facturas son analizadas en un período largo, es posible que los precios unitarios del fichero de lista de precios hayan sido modificados durante el período.

A título de anécdota, y para ilustrar el interés de este test, tomemos el ejemplo de un software en el cual la zona «precio unitario» de la línea de factura tenga, debido a un error, una extensión inferior a la zona «precio unitario» del fichero de listas de precios: los precios facturados de los artículos superiores a 10.000 pesetas se encuentran truncados. ¡De este modo, un ar- tículo de 11.500 pesetas será facturado por 1.500 pesetas! Esta anomalía de diseño será detectada inmediatamente por el test.

c) Búsqueda de clientes que dispongan permanentemente de condiciones especialmente ventajosas

El objetivo esta vez es asegurarse de que, debido a un error en la intro- ducción de datos o a un «regalo» por parte de un comercial, algunos clientes no se beneficien de forma permanente, de condiciones demasiado ventajosas.

Este test es particularmente simple, pues sólo basta una lectura secuencial del fichero de clientes, donde se encuentran las condiciones normales practicadas.

d) Búsqueda de los albaranes de entrega no facturados

En principio, cuando haya sido servido el pedido, la factura debe ser emitida inmediatamente. El objetivo aquí es detectar entregas cuya facturación haya sido aplazada de forma anormal.

Por lo general es fácil, con un barrido del fichero, detectar todos los pedidos servidos anteriormente a una fecha determinada y no facturados to- davía.

e) Búsqueda de los abonos más importantes

A través de un balance secuencial del fichero de los abonos emitidos, comprobaremos que éstos están justificados, ya sea por las devoluciones de mercancías o bien por los descuentos financieros o comerciales.


f) Búsqueda de los clientes cuyos importes pendientes sobrepasen los valores máximos autorizados por el servicio de crédito Buscaremos aquí los clientes a los cuales aceptaríamos servir incluso

cuando su importe pendiente sea demasiado alto. De hecho, el servicio de seguimiento del riesgo-cliente determina, por lo

general, un saldo máximo pendiente de pago autorizado en función de consideraciones propias a cada cliente, tales como: capacidad financiera, impagados anteriores, cifra de negocio anual realizada con él, etc.

El importe pendiente de pago está formado por:

— El saldo de la cuenta del cliente. — El saldo de los efectos a cobrar para este cliente. — Los efectos descontados pero no vencidos.

Este importe puede ser recalculado partiendo de los ficheros de la contabilidad auxiliar de clientes, pero, por necesidades de la aplicación, a menudo está controlado en una zona específica de este fichero.

El importe pendiente máximo autorizado aparece en el fichero de cliente. Si bien la aplicación de este test parece demasiado compleja, una variante simple consiste en listar todos los clientes cuyo importe pendiente máximo autorizado sobrepase un límite determinado.

Por último, cuando no existe un importe pendiente máximo en el fichero, una segunda variante consistirá en seleccionar los clientes cuyos importes pendientes sobrepasan un cierto límite.

De todos modos, después de la selección, el auditor intentará analizar el riesgo real en estos clientes.


Capítulo 9

El ciclo de las compras


9.1.1 Los ficheros principales

a) El fichero de existencias

Por supuesto, constituye la base del control de aprovisionamientos, ya que suministra para cada artículo sus referencias, su cantidad en existencia o en pedido, los datos del proveedor principal, los precios, etc.

Distinguiremos, en general, los aprovisionamientos en productos acabados, que serán revendidos en estas condiciones, en el marco de una actividad puramente comercial, y los aprovisionamientos en materias primas, que en- trarán en el ciclo de producción de la empresa, esta vez en el marco de una actividad industrial.

En el primer caso, el fichero de existencias es común al ciclo de ventas y de compras. En el segundo, por el contrario, las compras se destinan a «alimentar» los turnos o cadenas de control de producción, de donde saldrán las existencias de productos acabados.

b) El fichero de los movimientos de existencias

Conteniendo el detalle del conjunto de los movimientos de existencias, incluye entre otras cosas los movimientos de entradas de mercancías como consecuencia de las compras.

El ciclo de las compras 149

c) El fichero de proveedores El fichero permanente de los proveedores contiene los datos básicos rela-

tivos a cada proveedor, tales como: razón social, dirección, nombre de los corresponsales, descuentos obtenidos, forma de pago, etc.

d) El fichero de las cuentas de proveedores

Extraído de la contabilidad auxiliar de proveedores, contiene el detalle de los asientos en las cuentas de proveedores.

e) El fichero de listas de precios

Según las empresas, será útil (y posible) o no conocer en los ficheros informáticos las listas de precios de los principales proveedores de cada ar- tículo.

Las ventajas son evidentes: elección automática del mejor proveedor para cada artículo, control de las facturas recibidas, etc.

Pero, en contrapartida, esta gestión de las listas de precios es, a menudo, demasiado ardua por diferentes razones, entre las cuales están:

— Las referencias de los artículos muy raras veces son las mismas en una empresa y en su proveedor.

— En espera de obtener del proveedor la transmisión de las listas de precios en soporte magnético, las tareas del registro cuando ocurre cualquier modificación de las listas de precios son, a menudo, muy importantes y propiciatorias de errores.

Por este motivo, es frecuente que no se controlen las listas de precios de proveedores por medio de software.

No obstante, notaremos en este campo los progresos importantes que se han realizado durante los últimos años en materia de normalización de los códigos de productos, y, sobre todo, de intercambio de datos informatizados (IDI).

f) El fichero de los pedidos a proveedores

Contiene el detalle de los pedidos a proveedores y evolucionan con éstos: propuestas de pedidos, pedidos en firme y transmitidos al proveedor, pedidos servidos por el proveedor, pedidos facturados por el proveedor.

De una manera análoga al fichero de los pedidos de clientes, encontramos para cada pedido:


— Un encabezamiento que llevará los datos básicos del pedido, tales como: nombre y dirección del proveedor, condiciones de pago, importe sin y con IVA incluido de la factura, etc.

— Las líneas por artículo: referencia, precio unitario, descuento obtenido, tipo de IVA, etc.

Muchos de los datos que aparecen en este fichero son extraídos automáti- camente de los ficheros de proveedores, de artículos y de lista de precios, con posibilidad de activación del proceso del desarrollo de informaciones sustitutorias en el momento de la toma.

Según sea el caso, las facturas serán controladas en un fichero específico, o bien serán integradas en el fichero de pedidos, con un código particular denominado «situación del pedido».

9.1.2 Los procesos

Los pedidos de aprovisionamiento son introducidos manualmente, o preparados automáticamente con arreglo a las reglas establecidas previamente (existencia inferior a un límite fijo, existencia inferior al consumo de x meses anteriores, etc.). De todas formas, los pedidos son susceptibles de modificaciones antes de la autorización definitiva para emisión y envío al proveedor.

Igualmente, según sea el caso, y por las razones anteriormente citadas, el precio unitario de los artículos será conocido o no en los ficheros en el momento de efectuarse el pedido.

Las cantidades pedidas, artículo por artículo, serán conocidas en todo momento.

En el momento de la recepción de la mercancía, las cantidades recibidas son registradas, bien directamente en el momento del control de las cantidades, o bien a partir de un albarán de recepción rellenado después de contada la mercancía. Las cantidades recibidas deben, en principio, corresponder al albarán de entrega emitido por el proveedor. El procedimiento de registro consiste normalmente en recuperar el pedido y rellenarlo con las cantidades entregadas, las cuales son contrastadas con las cantidades pedidas.

A este nivel veremos que:

— Una recepción puede corresponder a varios pedidos. — Por el contrario, una recepción puede ser sólo parcial, ya sea debido a

que algunos artículos no son servidos, o bien porque lo son por una cantidad inferior a la pedida. Esta falta de correspondencia entre los pedidos realizados y las entregas del proveedor crea a menudo un problema de


diseño del software para el registro de las facturas de proveedor. Éstas son, de hecho, emitidas con cada entrega y es difícil cotejar las líneas de la factura y los pedidos, ya que una factura puede haber salido de varios pedidos y que una misma línea de pedidos ha podido dar lugar a varias entregas y, por consiguiente, a varias facturas.

Por este motivo, y para evitar hacer más difícil el diseño de los programas, se imponen muy a menudo procedimientos manuales a los usuarios, como por ejemplo:

— Las líneas de pedido se completan con los precios unitarios facturados, para servir de base a la valorización de las existencias, y el importe total de la factura es imputado en la contabilidad del cliente, si fuere el caso a través de un segundo registro totalmente independiente.

— En caso de entrega parcial por parte de un proveedor, una línea del pedido para el resto del pedido a ser servido, si se diera el caso, será registrado nuevamente, o bien creado de forma automática.

Por supuesto, los precios unitarios facturados por el proveedor serán o no controlados automáticamente según hayan estado o no cargadas en máquina las listas de precios de los mismos.

En algunos casos, la factura puede ser recibida por el servicio de contabilidad antes de la entrega de la mercancía.

Además, algunas veces, se devuelve la mercancía al proveedor cuando la entrega no está de acuerdo con el pedido o cuando existe algún problema con relación a la calidad.

La factura es entonces registrada en contabilidad, pero no da lugar naturalmente al pago, puesto que se espera un abono de parte del proveedor.

Por lo general, las facturas sólo son liquidadas después de la toma de una «señal» informática, correspondiente al «conforme para pago» colocado sobre la factura. El pago se genera automáticamente en la contabilidad de proveedores, según la forma de pago que figure en el fichero (talón, pagaré, et- cétera).

Nota:

El procedimiento que acabamos de describir se refiere a la compra de mercancías. En realidad, los programas permiten igualmente, a menudo, el control de pedidos de prestaciones inmateriales, o sea, que no generan nin- gún tipo de entrada física. Un indicador, colocado en la parte superior del pedido, especificará que éste no dará lugar a ningún tipo de actualización de existencias.


9.2 LA AUDITORÍA DE LA APLICACIÓN

9.2.1 La adecuación de las prestaciones a las necesidades de los usuarios

Entre las funciones cuya adecuación a las necesidades es especialmente útil controlar, podemos citar:

■ — La gestión automática de los aprovisionamientos. — La gestión del fichero de las listas de precios. — El registro de recepciones. — El registro de las facturas de proveedores. — La posibilidad de introducir un «conforme para pago» que condicione el

pago al proveedor. — El perímetro de aplicación del procedimiento (la no existencia de proce-

dimientos de compras que no pasen por el circuito de control de los pedidos).

— La existencia de los listados necesarios para el seguimiento contable de las compras.

9.2.2 La separación de funciones

Los imperativos de una buena separación de funciones conducen, por lo general, a distinguir las funciones siguientes:

— El solicitante de la compra, que está en el origen del pedido, y que autori- zará el pago.

— El servicio de compras, que pasa los pedidos y coordina las relaciones con los proveedores.

— El almacén, que es responsable de la conservación de los activos, y asegura el control, tanto cualitativo como cuantitativo, de las mercancías entradas.

— La contabilidad, que registra las facturas de proveedores. — La tesorería, que está en el origen del pago al proveedor.

9.2.3_Los controles jerárquicos

Enfocaremos aquí, muy en particular, el control jerárquico de la actividad de los compradores. Este control se ejerce ya sea a priori, debido a la necesidad que tienen éstos de contar con autorización para algunos pedidos

El control de las compras 153

(excepcionales por su importe o sus condiciones) por parte de un superior je- rárquico, o bien a posteriori por la emisión de listados que suministren perió- dicamente el resumen de los pedidos pasados, con el detalle de las condiciones negociadas.

Estos listados estadísticos pueden responder a diferentes criterios de aná- lisis, o sea:

— Volumen de negocios y descuentos obtenidos por proveedor. — Volumen de negocios y descuentos obtenidos por comprador.

9.2.4 La separación de los ejercicios contables ■

Tanto con fines contables como en la óptica de un buen seguimiento de los pedidos, es deseable conocer en todo momento, o cuando se emiten, los estados de cuentas de:

— Las mercancías entregadas para las cuales no se haya recibido aún la factura del proveedor.

— Las facturas recibidas de las cuales no hayan sido aún entregadas las mercancías.

— Los abonos a recibir.

Veremos, además, que un buen control de la separación de los ejercicios (es decir, del ejercicio de enlace de las facturas y los abonos) implica que las facturas sean transmitidas en el momento de su recepción a los servicios financieros para ser registradas en contabilidad, y esto incluso en el caso en que la factura debiera ser posteriormente impugnada.

Caso contrario, algunas facturas podrían «perderse por el camino» y no llegar al conocimiento del servicio de contabilidad al cierre del ejercicio. Este riesgo se refiere en particular a las prestaciones de servicios, para las cuales no se registra ninguna recepción al término de la prestación. Por esta misma razón, es además deseable que incluso las prestaciones de servicio den lugar al registro de un pedido.

9.2.5 El registro y el pago de las facturas de proveedores

Éste es un punto esencial, el procedimiento que debe garantizar que sólo se paguen a los proveedores las prestaciones realmente debidas. Con esta óptica:


— Los originales de las facturas se registran en contabilidad. — Las facturas registradas son numeradas en secuencias, o sea, con el nú-

mero colocado manualmente e introducido en el ordenador con la factura, o bien el número es colocado por el ordenador y puesto en la factura.

— Los originales de las facturas se transmiten a los servicios de autoriza- ción de pago para la colocación del «conforme para pago», después de la comparación de la factura con el albarán de recepción hecho por el alma- cén, cuando la factura corresponde a una entrega de mercancía.

— Los «conforme para pago» son registrados en el sistema informático y ponen en marcha los pagos automatizados.

— Se registra eventualmente un comentario en los pedidos con algún tipo de problema.

Este procedimiento permite, a la vez, conocer todas las facturas recibidas y pagar sólo las facturas autorizadas. En particular, la utilización de los originales de factura y su numeración evita cualquier doble registro o doble pago de una de ellas, y la comparación de la factura con el albarán de recep- ción evita pagar prestaciones incompletas o no satisfactorias.


Capítulo 10

La gestión de existencias

Evidentemente, la gestión de existencias está estrechamente relacionada con las cadenas ascendentes:

— La gestión de las compras está en el origen de las entradas en las existencias de materias primas (empresas industriales) o de productos acabados (empresas comerciales).

— La gestión de producción está en el origen de las salidas en las existencias de materias primas y de entradas en las existencias de productos acabados (empresas industriales).

— El ciclo de ventas está en el origen de las salidas en las existencias de productos acabados.

Citaremos en este capítulo los procesos propios de la gestión y de la valo- rización de existencias.



a) El fichero de artículo

Contiene los datos permanentes relativos a cada artículo, como:

— Referencia, denominación, localización habitual en almacén, proveedores) habitual(es), precio de compra, precio de venta, descuento por cantidad acordado, nomeclatura de producción, etc.


En algunos casos, se distingue el fichero de artículo y el fichero de lista de precio.

Además, el contenido exacto de este fichero depende, por supuesto, del tipo de artículo referenciado, por ejemplo: una materia prima tendrá las informaciones relativas a su tipo de aprovisionamiento y a su utilización en el ciclo de producción, un producto acabado tendrá los datos de gestión comercial, etc. En las empresas industriales, además, se distinguirán a menudo varios ficheros según la posición de los productos en el ciclo de pro- ducción.

b) El fichero de las existencias

Los datos cuantitativos de las existencias son, según sea el caso, incluidos o no en el fichero de artículo.

Citemos a título de ilustración estos datos:

— La cantidad en existencias, con una gestión eventualmente individuali- zada según el sitio de almacenaje.

— Las cantidades pedidas a los proveedores. — Las cantidades reservadas por los clientes. — Los precios de coste. — Las cantidades inventariadas. — El total de los movimientos del mes por tipo de movimiento.

c) El fichero de inventario

En algunos casos, la ejecución del inventario físico da lugar a la creación de un fichero específico. En otros casos, los datos de inventario están incluidos directamente en el fichero de existencias.

d) El fichero de los movimientos de existencias

Habíamos mencionado en el capítulo primero (apartado 1.3.1) la necesidad de crear en toda cadena de gestión de existencias un fichero de los movimientos de las mismas, que permita justificar las cantidades y la valoración de los artículos que figuran en el inventario permanente.

10.1.2 Los procesos

Citemos entre los principales procesos propios de la gestión de los ficheros de existencias:

La gestión de existencias 157

— La valoración de las existencias. — El proceso del inventario físico. — El registro de los movimientos de existencias que no tengan origen en las

cadenas ascendentes. — La preparación automática de reaprovisionamientos en función a límites

de alerta. — Diversas emisiones: listado de los movimientos, listado de las anoma-

lías, listado de las existencias valorizadas, etc.


Volvemos a hablar aquí de la auditoría de las principales funciones de la aplicación.

10.2.1 La valoración de las existencias

Una gestión informatizada de la valoración de las existencias implica la realización de un inventario permanente, es decir, de un seguimiento permanente de las cantidades en existencia con arreglo a las entradas y salidas registradas.

Las entradas en existencia serán valoradas a precio de adquisición, para los bienes adquiridos fuera de la empresa y a coste de producción, para los artículos fabricados en la empresa.

No detallaremos aquí las modalidades de cálculo del coste de producción ni el detalle de los cargos incorporados a este coste. El lector se informará, para mejor precisión sobre este tema, en las obras de contabilidad.

Tratándose de modalidades de valoración de existencia «contable» y fiscalmente admisibles, conviene distinguir entre los artículos identificables y los artículos intercambiables.

Los artículos identificables de una manera individual se valorizan a su coste real de entrada.

Los artículos intercambiables, en los cuales centraremos nuestra aten- ción, serán valorizados a un coste estimado de entrada. Se admiten dos mé- todos para evaluar este coste estimado:

— El método del «primero en entrar, primero en salir», llamado también el método del FIFO (first in, first out).

— El método del coste medio ponderado.


• El método FIFO

Cada salida se valoriza al coste más antiguo del producto en existencia, de donde viene la expresión de «primero en entrar, primero en salir».

En el plan informático este método implica conservar, para cada producto, el detalle de los movimientos de entrada correspondiente a las existencias presentes en la empresa. A continuación veremos un ejemplo de va- loración en FIFO.

Ejemplo de valoración en FIFO

Fecha Tipo de movimiento Cantidad

Precio unitario

de entrada

Valor délas

entradas

Valor délas

salidas

Cantidad restante

existencia

Valor déla

existencia 12/1 Compra 10 100 1000 10 1000 18/1 Compra 10 110 1100 20 2100 20/1 Venta 5 - 5001 15 1600 22/1 Compra 10 120 1200 25 2800 24/1 Venta 10 - 1O5O2 15 17503

1. La salida del 20/1 está valorada al coste de 5 entradas del 12/1. 2. La salida del 24/1 está valorada al coste de las otras 5 entradas del 12/1 (a 500 PTA) y de 5 entradas del

18/la 550 PTA). 3. Después de la venta del 24/1, los ficheros informáticos deben saber que el valor de la existencia se jus-

tifica por las 10 entradas del 22/1 (a 1.200 PTA) y 5 de las entradas del 18/1 (a 550 PTA).

Se comprenderá fácilmente, a vista de este ejemplo, que de una parte la gestión de un sistema de este tipo es relativamente trabajosa, y que, por otro lado, los volúmenes de los ficheros pueden tornarse considerables cuando las existencias de cada artículo se justifican por medio de un número importante de movimientos de entrada.

Cuando se emplea este método de valoración, el auditor se preocupará de comprobar que se trata de un «verdadero» FIFO. Algunas veces, de hecho, métodos más o menos próximos son calificados erróneamente de FIFO.

• El método del coste medio ponderado

Según este método, el coste medio ponderado se recalcula:

— ya sea en el momento de cada entrada; — o bien en un período que no sobrepase el coste medio de almacenaje.


He aquí un ejemplo de valoración al coste medio ponderado recalculado en el momento de cada entrada, que es notablemente el método más empleado en Francia y que presenta además la ventaja de la simplicidad.

Ejemplo de valoración de la existencia a coste medio ponderado

Fecha Tipo de movi-

miento Cantidad

Precio unitario

de entrada

Valor délas

entradas

Valor délas salidas

Cantidadrestante

existencia

Precio medio

existencia

Valor déla

existencia

12/1 Compra 10 100 1000 _ 10 100 1000 18/1 Compra 10 110 1100 - 20 105 2100 20/1 Venta 5 _ _ 525 15 105 1575 22/1 Compra 10 120 1200 - 25 111 2775 24/1 Venta 10 - - 1110 15 111 1665

En Francia no se admite ni contable ni fiscalmente ningún otro método de valoración de las existencias. No obstante, podemos citar otros métodos aplicados algunas veces:

— La valoración a coste de sustitución. — La valoración por el último precio conocido. — La valoración a coste estándar.

10.2.2 El inventario físico

Independientemente de las obligaciones legales y fiscales en la materia, el inventario físico de las existencias constituye una medida de control interna indispensable, que suministra información valiosa sobre la fiabilidad del inventario permanente.

El desarrollo de software específico es, por lo general, necesario para facilitar el buen funcionamiento de las operaciones de inventario.

• La preparación del inventario físico

La documentación del inventario, que será revisada por los equipos encargados de la operación, es generalmente impresa con anterioridad, por medio de un listado informático de los artículos por localización de almacenaje.

El inventario será más fiable si se realiza «a ciegas». Las cantidades teó- ricas en existencia, resultantes del inventario permanente informático, no constarán en la documentación de inventario.


• La toma de la documentación de inventario

Recordemos en primer lugar que un inventario físico fiable necesita en principio un recuento doble llevado a cabo por dos equipos de personal diferentes. Los resultados de cada recuento figuran en la documentación de inventario.

En cambio, no es necesario prever en la aplicación informática la intro- ducción para cada artículo de los resultados de cada uno de los dos recuen- tos. Sólo la cantidad definitiva en existencia será tomada.

• El proceso del inventario

Al término de la introducción de los datos del inventario, es deseable que se impriman para el análisis las diferencias significativas entre el inventario permanente y el inventario físico. El inventario físico será, si es necesario, corregido después del análisis.

Una vez que se hayan efectuado estas últimas correcciones, por lo general se preverá la sustitución automática en los ficheros del inventario permanente por el inventario físico, o bien la introducción de los movimientos de corrección de inventario.

Cuando el inventario físico ha sido realizado al cierre del ejercicio contable, los procesos informáticos se concluirán con la emisión de las existencias valoradas, que servirá de base para la introducción de los asientos contables de valoración de las existencias.

10.2.3 La introducción de las regularizaciones de existencias

Si bien la gran mayoría de los movimientos de existencias provienen de las cadenas ascendentes (compras, ventas, etc.), no obstante, es indispensable prever la posibilidad de registros de movimientos de regularización. Se- gún sea el caso, estas regularizaciones serán valorizadas (ejemplo: devoluciones de mercancías) o no (ejemplo: correcciones de inventario).

Los movimientos de regularización que afecten el valor de las existencias (sin movimiento de cantidad) deben igualmente poder ser introducidos.

Por supuesto, el acceso a la pantalla de introducción de datos de las regularizaciones debe estar estrictamente limitado. En particular y por razones de separación de funciones, estará prohibido a las personas responsables de la conservación de las existencias (personal de almacén).


10.2.4 La gestión de reaprovisionamientos

Es muy raro que la gestión de reaprovisionamientos sea totalmente automatizada. En cambio, se prevé que la aplicación proponga los pedidos a proveedores con arreglo a criterios definidos con anterioridad, tales como: existencias inferiores a un límite de alerta, fijo o variable (x meses de ventas, etc.).

10.2.5 Las ediciones periódicas

Citaremos algunas de ellas, que son necesarias para fines de gestión, y control o bien para fines puramente contables.

• El listado de valoración de las existencias

Tendrá la cantidad y el precio unitario de cada artículo, justificando de esta forma el valor total de las existencias.

• El listado de los movimientos de existencias

Ya hemos subrayado que es el garante del cálculo de las cantidades y de los valores de las existencias que figuran en el inventario permanente.

• El listado de las rotaciones lentas

Este listado responde a la vez a un objetivo de gestión (el conocimiento de las existencias paradas) y a un objetivo contable (el aprovisionamiento de todo o parte de tales existencias).

El criterio de selección de las rotaciones lentas será, por ejemplo, el siguiente:

— Una cantidad en existencias superior a x meses de salidas futuras previsi- bles.

— Una cantidad en existencias superior a x meses de salidas pasadas. Siendo este el criterio empleado con más frecuencia.

Tratándose de las tasas de provisiones contables, generalmente se definen diferentes zonas. Por ejemplo:

— Las cantidades en existencia que representen entre 3 y 6 meses de almacenaje se deprecian en un 25 %.


— Las cantidades en existencia que representen entre 6 meses y un año de almacenaje se deprecian en un 50 %.

— Las cantidades en existencia que representen más de un año de almacenaje se deprecian en su totalidad.

• El cálculo de la provisión por alza de los precios

Sin entrar en el detalle del cálculo de esta provisión, nos limitaremos a recordar que se trata de una provisión de tipo fiscal, destinada a cubrir los efectos de la inflación en el coste de recuperación de las existencias en pe- ríodo de alza de los precios.

Su cálculo, basado en la comparación de los costes unitarios de los ar- tículos en existencia durante tres ejercicios sucesivos, necesita, por lo general, el desarrollo de un software específico.

Para más precisión sobre este tema el lector debe recurrir a las obras sobre contabilidad.

10.3 LA UTILIZACIÓN DE LOS PROGRAMAS DE AUDITORIA

Distinguiremos en este nivel:

• Los programas destinados a recalcular los resultados de un proceso ya desarrollado por la empresa con fines de validación, o también a conseguir este resultado para paliar su falta en la empresa:

— Cálculo de la valoración de las existencias. — Detección de rotaciones lentas y cálculo de la provisión contable. — Cálculo de la provisión por alza de precio. — etcétera.

• Los programas destinados a seleccionar, para un análisis complementario, los artículos que presenten las siguientes características particulares:

— Lista de artículos cuyo precio unitario haya subido más de X % de un ejercicio al otro. Nos aseguraremos de que este aumento esté justificado y que no esconda un error en el cálculo del precio unitario que resulte en una supervaloración del valor de las existencias.


— Lista de los artículos cuya cantidad en existencia del inventario permanente sea negativa. Esta lista revela eventuales puntos débiles en el inventario permanente, debidos a errores de software, a una mala aplica- ción del procedimiento (por ejemplo, de entradas de mercancías registradas con retraso).

— Lista de las diferencias más significativas entre inventario físico e inventario permanente. Pondrá en evidencia, cuando son muchas las diferencias, una falta de fiabilidad del inventario permanente (¡A menos que ésta no sea del inventario físico!); a menudo, las diferencias más importantes se deben a anomalías flagrantes, por ejemplo, un error de unidad (se han contado las botellas por paquetes de seis mientras que en el inventario permanente se cuentan por unidades de botellas); el auditor se asegurará entonces de que finalmente se corrijan estas anomalías.


Capítulo 11

La nómina y la gestión del personal

11.1 PRESENTACIÓN DE LA APLICACIÓN

Si bien es cierto que, hoy día, la nómina tan sólo representa un subcon- junto de una función mucho más amplia (la gestión de los recursos humanos), no es menos verdad que, tratándose de procesos informáticos, la nó- mina constituye evidentemente la aplicación más sensible, que justifica un interés particular por parte de los auditores por el contenido de esta función. El presente capítulo se centrará, por tanto, principalmente en la gestión del fichero de personal y el proceso de la nómina.


a) El fichero de personal Constituye, por supuesto, el fichero básico de la gestión de los recursos

humanos. Para cada asalariado contendrá: el nombre, los apellidos, la dirección, el

cargo, la función, la remuneración, las primas, la fecha de nacimiento, los di- plomas, el seguimiento del absentismo, seguimiento de las vacaciones, si- tuación familiar, etc.

La mayoría de las veces, contendrá igualmente los acumulados anuales necesarios para la elaboración de los listados fiscales y sociales obligatorios.

La nómina y la gestión del personal 165

El fichero de personal se actualiza constantemente por un procedimiento interactivo.

b) Los ficheros propios del proceso de la nómina

• El fichero de los movimientos de la nómina (o hechos que hagan cambiar la misma)

Este fichero contiene cada mes los movimientos variables necesarios para el establecimiento de los recibos de salarios, tales como: horas trabaja- das, horas extra, absentismo, vacaciones, primas extraordinarias, etc.

• El fichero preparatorio de la nómina

En la gran mayoría de los casos, la preparación de la nómina a final de mes se lleva a cabo en dos fases, con algunos días de intervalo, conserván- dose entre ambas un fichero preparatorio para la confección de las hojas de salarios.

• Los ficheros de los parámetros de nómina

Contienen todos los parámetros necesarios para la preparación de la nó- mina, como: tasa de cotización, límites, etc.

• Los ficheros de las transferencias de nóminas

Se transmite cada mes al banco de la empresa para efectuar las transferencias correspondientes a la remuneración neta de los salarios.

11.1.2 Los principales procesos

a) Los procesos relacionados directamente con la fijación de la nómina

Cada mes, después de terminadas las actualizaciones del fichero de personal con la introducción de los hechos susceptibles de variar la nómina del mes, se ejecuta el proceso de la nómina. Este proceso en tiempo diferido (figura 5) se desarrolla por costumbre en dos etapas, que son:

— Una primera etapa que conduce a la ejecución de un listado preparatorio para ser aprobado por parte del servicio de personal y, si fuere el caso,


Figura 5. Presentación sintética de la preparación mensual de la nómina.


para efectuar correcciones en los ficheros y, la mayoría de las veces, para la edición de un fichero intermedio que servirá para la edición de las hojas de salarios.1

— Una segunda etapa, algunos días después de la primera, que conduce a la emisión de las hojas de salario definitivas, a la emisión del libro de salarios y del diario de salarios contable, a la actualización en el fichero de personal de los acumulados necesarios para la edición a final de año de los listados obligatorios y también a la emisión de los listados necesarios para el pago de las cotizaciones patronales y de todos los listados estadís- ticos.

Al final del año se estudian los listados de declaración anual de remuneraciones (DADS1 en Francia) destinados a la Seguridad Social y a la admi- nistración fiscal.

b) Los procesos propios de la gestión de recursos humanos

Sin pretender que la lista sea exhaustiva, a continuación citaremos de forma abreviada algunas prestaciones propias de la gestión de recursos humanos:

— Seguimiento individual del historial de evolución de las funciones ocupadas, de las posiciones jerárquicas, de las remuneraciones, de las formaciones seguidas, etc.

— Simulación relativa a la evolución de las remuneraciones. — Gestión de los mandos superiores y dirigentes, por medio de un fichero

específico. — Gestión previsional del empleo. — Control de la movilidad (gestión de un fichero de las ofertas de empleo,

seguimiento de los colaboradores que buscan cambio de categoría la- boral).

— Control de la formación (catálogo de formación, seguimiento individual, etcétera).

— Seguimiento de vacaciones y absentismo. — Gestión de la contratación.

1. Si tras del control no hace falta ninguna corrección, el proceso definitivo consistirá en ejecutar la segunda fase a partir del fichero intermedio, mientras que, en el caso contrario, las dos fases se ejecutarán sucesivamente después de la modificación de los ficheros básicos.



Presentaremos en forma de un cuestionario algunos puntos importantes de control de la aplicación de gestión del personal y, más en particular, del proceso de la hoja de salarios.

• P. ¿Están los parámetros necesarios para la confección de la hoja de salarios incluidos en las tablas y actualizados por el departamento de personal?

Algunas veces se encuentran todavía (felizmente muy raramente) programas específicos «desarrollados» internamente, en los cuales los paráme- tros de la hoja de salarios (cuotas salariales y patronales, topes, etc.) vienen incluidos «de origen» en los programas. Hay que sustituir este tipo de software lo más rápido posible.

Más frecuente es el caso en el que estos parámetros se incluyen en las tablas, pero, teniendo en cuenta la complejidad de la aplicación, son actualizados por el departamento de informática a petición del de personal. Esta forma de actuar, si bien es admisible de forma transitoria en el momento de la aplicación del programa, no es aconsejable a largo plazo. El departamento de personal debe ser responsable de la utilización del programa de cálculo de la nómina y, por lo tanto, en particular, de su «parametraje».

Diremos de paso que la gestión del «parametraje» del conjunto del programa representa a menudo una carga de trabajo relativamente elevada y compleja (el parametraje de algunos programas se parece casi a la utiliza- ción de un lenguaje de «programación»2), y que, además, es indispensable, por razones de seguridad, que por lo menos dos personas estén capacitadas para llevar a cabo esta función.

• P. ¿Se conserva en un fichero específico el historial de actualización realizado sobre la base de los parámetros de la hoja de salarios?

Este historial es indispensable para llevar a cabo búsquedas eventuales, en caso de necesidad, con la finalidad de reconstruir una hoja de salarios corres-

2. En especial, deben ser parametrados: las tasas y topes necesarios para la fijación de la nómina, los con- ceptos de nómina y las modalidades de cálculo de la remuneración correspondiente a cada concepto, las modalidades de creación de los asientos contables, etc. Esto explica que cuantas más posibilidades funcionales ofrezca el sistema de parametraje, más compleja será su utilización.


pondiente al mes anterior. Puede ser tanto informatizada, por medio de un fichero de las modificaciones de parámetros, o bien manualmente; en este caso los parámetros se editarán en archivos en el momento de cada puesta al día.

• P. ¿Es correcto el cálculo de las remuneraciones y de las cotizaciones de trabajadores y patrones?

Si bien esta cuestión parece básica en el marco de la auditoría de la hoja de salarios, desgraciadamente no es fácil detectar anomalías que sólo se ma- nifestarían en casos específicos y muy infrecuentes.

Un indicador de fiabilidad de la aplicación reside en el análisis de las reclamaciones que llegan al departamento de personal durante un período de tiempo determinado. La utilización de software de auditoría puede de la misma forma permitir detectar, si fuera el caso, las incoherencias importantes.

• P. ¿Las hojas de salario están de acuerdo con la reglamentación?

Señalemos, entre otras cosas, las obligaciones legales de 1988 concernientes a la mención en las hojas de salario de las informaciones relativas a las cotizaciones patronales y a las vacaciones remuneradas.

• P. ¿Permite el software la edición del libro de salarios?

Este listado obligatorio reproduce, en orden cronológico, algunas informaciones que aparecen en las hojas de salarios.

• P. ¿Permite el software la creación de las cintas de transferencia de salarios a los bancos?

Éste es el caso de la gran mayoría de los programas.

• P. ¿Se ha previsto una actualización automática de los acumulados necesarios para establecer la Declaración Anual de Remuneraciones destinada a la Seguridad Social (DADS1 en Francia)?

Éste es igualmente el caso de la gran mayoría de los programas.


• P. Si hay un procedimiento de actualización directa de las zonas correspondientes a los acumulados anuales, ¿se encuentra ésta completamente asegurada?

Si bien la existencia de un procedimiento de este tipo es, por lo general, deseable, de forma que pueda corregir anomalías eventuales, se compren- derá fácilmente que debe estar completamente asegurada, en la medida en que es susceptible de crear heterogeneidades entre las remuneraciones remi- tidas y las declaraciones a la Seguridad Social y a la administración fiscal y, por tanto, de tener defraudadores eventuales entre el personal de la empresa.

La utilización del procedimiento será, por lo tanto, cuidadosamente controlada; cualquier modificación de los parámetros, reservada a un número muy limitado de operadores, debe, por ejemplo, ser precedida de la aproba- ción del jefe de personal.

• P. ¿El procedimiento de preparación de la nómina garantiza la coherencia del fichero de personal, hoja de salarios, libro de salarios, asientos contables, ficheros de acumulados anuales para la Declaración Anual de Remuneraciones (DADS1) y listados estadísticos?

El diseño mismo del procedimiento debe garantizar la coherencia entre el conjunto de estos elementos.

Ilustraremos mejor este tema por medio de un ejemplo de contraste. Ima- ginemos dos procedimientos análogos al descrito en la figura 5, pero en los cuales los acumulados anuales estén actualizados en el fichero de personal desde la primera etapa, permitiendo el procedimiento, además, la posibilidad de modificar el fichero preparatorio de la nómina, sin modificación previa de los ficheros básicos (fichero de personal, fichero de los cambios de nómina, fichero de parámetros).

Este procedimiento no será, en ningún caso, satisfactorio en la medida que:

— Las remuneraciones que figuran en las hojas de salario pueden diferir de las que aparecen en el fichero de personal en caso de intervención manual, de donde resulta un caso flagrante de discontinuidad de la vía de re- visión.

— La terminación del proceso implica que las zonas de acumulados anuales sean corregidas «manualmente» en el fichero de personal posteriormente a la emisión de la hoja de salarios, por lo que existe un riesgo importante de error en la aplicación del procedimiento.


• P. ¿Hay una fase de autorización previa para la preparación de la nómina antes de editar las hojas de salarios definitivas?

Esta fase, de la cual hemos hablado en la descripción del proceso, permite detectar eventuales anomalías previamente al envío de las hojas de salarios y de las órdenes de transferencia.

• P. ¿Se procede a la comprobación manual entre el libro de salarios, los asientos contables y los diversos listados estadísticos después del proceso de la nómina?

Estas confrontaciones, en caso de incoherencia, revelarían anomalías en el software, o bien maniobras fraudulentas.

• P. ¿Se llevan a cabo comprobaciones de cuentas bancarias con regularidad?

Una técnica de fraude en materia de nómina, y cuya divulgación ha sido muy extendida, consiste en modificar la cinta de transferencias entre su pre- paración y su envío al banco.

La técnica de comprobación bancada que permite, en este caso en concreto, cotejar los créditos de la cuenta «banco» en la empresa, tal y como han sido creados a partir de la preparación de la nómina, con los débitos en los extractos enviados por el banco, permite poner en evidencia este tipo de ma- nipulación.

• P. ¿Permite el software la creación de la declaración anual de los salarios (DADS1)3?

Ésta debe ser enviada antes del 1 de febrero a la Seguridad Social y a la administración fiscal.

En lo sucesivo, será enviada en un soporte magnético.

• P. ¿Son satisfactorios los procedimientos de confidencialidad de acceso al software?

Uno se interesará, por ejemplo, por la lista de las personas autorizadas a utilizar el software, por la calidad de las contraseñas elegidas, etc.

3. DADS1 es el resumen de remuneraciones que se presenta anualmente en la Seguridad Social Francesa. Equivale al TC2 utilizado en España con periodicidad mensual.


• P. ¿Permite el software el control de las vacaciones y las bajas?

• P. ¿Permite el software efectuar el historial de los datos necesarios para la gestión del personal?

Citemos, por ejemplo:

— Historial de remuneraciones. — Historial de las funciones ocupadas. — Historial de las posiciones jerárquicas. — Historial de bajas.

• P. ¿Está prevista una separación de Junciones entre las personas responsables del registro de los hechos que modifican la nómina y las responsables de la preparación y del control de la misma?

• P. ¿Han sido satisfechas las necesidades expresadas por la Dirección de Recursos Humanos en términos de la gestión de los recursos humanos (exceptuándose el proceso de la nómina)?

11.3 LA UTILIZACIÓN DEL SOFTWARE DE AUDITORIA

Se podría pensar en la posibilidad de controlar la presencia de operaciones fraudulentas, por medio de la utilización de programas de auditoría en el campo de la nómina y de la gestión de personal. En realidad, el simple hecho de analizar el contenido de los ficheros que conforman esta aplicación sólo permitiría detectar malversaciones groseras, pero no las operaciones más sofisticadas.

Tomemos, por ejemplo, un caso frecuente de fraude, la creación en el fichero de personal de asalariados ficticios. Si el que concibe la operación es alguien un poco ingenuo, es posible que haya domiciliado la transferencia del sueldo del empleado ficticio en su propia cuenta. Un análisis sistemático apropiado del fichero de personal (o de la cinta de remesa) detectará sin dificultad la manipulación. Pero si nuestro defraudador ha tomado la precaución de domiciliar este salario en la cuenta de un cómplice que no pertenezca a la empresa, ningún análisis informático podrá revelar el fraude. Sólo los análi- sis de dossieres del personal y de las autorizaciones, complementados, si


fuere el caso, por visitas al lugar de empleo, permitirán al auditor poner en evidencia la operación. Muy a menudo, además, el auditor preferirá comprobar la correcta aplicación de los procedimientos de contratación y de des- pido, con el fin de limitar los riesgos, más que buscar las operaciones fraudulentas.

Hecho este preámbulo, veremos, a continuación, algunos ejemplos de tests de auditoría de la nómina y del fichero de personal, dejando claro que el objetivo que se pretende es más el control de la coherencia del software y de la correcta aplicación de los procedimientos que la búsqueda de malversaciones:

— Control de la coherencia de las remuneraciones en función del fichero de personal.

— Búsqueda de los incrementos salariales más significativos para asegurarse de que éstos hayan sido aprobados con normalidad.

— Control de coherencia de las primas pagadas en función del contenido del fichero de personal.

No desarrollaremos más estos pocos ejemplos, ya que la experiencia nos enseña que, por lo general, su aportación es relativamente limitada.

Citemos, por último, el interés de algunos controles de uso puramente contable, por ejemplo:

— Validación de la provisión para vacaciones pagadas. Nos preocuparemos al 31 de diciembre, a la vez, de las vacaciones devengadas relativas al período en curso, que terminará el 31 de mayo próximo, y de las vacaciones restantes a ser disfrutadas por los empleados relativas al año anterior.

— Validación del importe de los compromisos preventivos de jubilación para los empleados todavía activos (contablemente estos compromisos están en forma de provisión, o bien constan en compromisos fuera del balance).

— Validación del importe de las primas adeudadas al personal en 31 de diciembre y no liquidadas todavía.


Capítulo 12

La gestión de las inmovilizaciones

12.1 DESCRIPCIÓN DE LA APLICACIÓN


El principal fichero que constituye la aplicación es, por supuesto, el fichero de las inmovilizaciones que contiene, si fuere el caso, algunas subdivi- siones (adquisiciones del ejercicio, detalle de las amortizaciones llevadas a cabo, etc.).

Citemos algunos de los principales elementos incluidos en este fichero:

— El título de la inmovilización. — Número de referencia. — Tipo de la inmovilización.1 — Importe bruto. — Período de amortización. — Tipo de amortización (lineal o decreciente). — Tipo de amortización considerado como económicamente justificado

(para el cálculo de amortizaciones eventuales sustitutorias). — Fecha de entrega. — Fecha de puesta en marcha.

1. El tipo de la inmovilización permitirá, entre otras cosas, un reagrupamiento de acuerdo con el plan contable.

La gestión de las inmovilizaciones 175

— Fecha de inicio de amortización.2 — Acumulado de dotaciones constatadas a partir de la adquisición del in-

mueble. — Tipo de compra (nuevo o de segunda mano). — Fecha de salida. — Historial de las amortizaciones anuales desde el principio.

Veremos igualmente la existencia de diferentes tablas: tabla de tipos de inmovilización, tabla de las tasas de amortización, etc.

12.1.2 Los procesos principales

Las funciones principales de un software de gestión son las siguientes:

— El registro interactivo de las adquisiciones y de las salidas de inmovilizaciones y la actualización de las fichas de inmovilizaciones existentes.

— Los procesos mensuales y anuales de cálculo de amortización en tiempo diferido.

12.1.3 Los listados principales

Los listados resultantes de la gestión de inmovilizaciones tienen, para la gran mayoría, un interés esencialmente contable y financiero.

• Los planes de amortización

El plan contable prevé que se defina, en el momento de la adquisición de cualquier nueva inmovilización, su plan de amortización, o sea, en función del modo y del período preventivo de amortización del bien.

Es, por lo tanto, indispensable que se prevea en cada software la edición de una ficha por inmovilización que contenga su plan de amortización.

• La lista de adquisiciones y cesiones del período (mes o ejercicio)

Este listado es necesario para hacer los asientos contables apropiados.

2. En caso de amortización lineal, la fecha del inicio de la amortización es la fecha de la entrada en servicio y la primera anualidad se calcula por prorrata del número de días; en caso de amortización decreciente, la fecha de inicio de la amortización es la fecha de adquisición y la primera anualidad se calcula por prorrata a contar desde el primer día del mes de la adquisición.


Tratándose de las cesiones, se debe especificar el valor neto contable de las inmovilizaciones cedidas, al igual que la plusvalía o minusvalía resultante.

• El cálculo de las dotaciones para amortizaciones del período

Las inmovilizaciones serán clasificadas contablemente con el objeto de efectuar los asientos apropiados.

La periodicidad de cálculo de las dotaciones será, según las empresas, mensual, trimestral o anual.

• El listado de las inmovilizaciones en una fecha concreta

Suministrando el valor bruto, el valor neto contable, el valor neto contable revalorizado3 y el importe de las amortizaciones sustitutorias por tipo de inmovilización y por inmovilización, permite justificar las cuentas del inmovilizado en el balance.


Citaremos en forma de cuestionario los aspectos principales de la audito- ría del software.

• P. ¿Permite el software la emisión de los planes de amortización?

Sobre este punto recurriremos al apartado anterior.

• P. ¿Permite el software procesar a la vez las amortizaciones decrecientes y las amortizaciones lineales?

No volveremos a hablar aquí de las modalidades detalladas de cálculo de la amortización decreciente y de la amortización lineal, que encontraremos en las obras sobre contabilidad. Recordamos a título ilustrativo que la amor- tización lineal corresponde a una amortización constante del bien durante su período de vida, mientras que la amortización decreciente permite, para al-

3. Las nociones de revalorización y de amortización sustitutoria se aclaran en la continuación del capí- tulo.


gunas inmovilizaciones, una amortización acelerada durante los primeros años.

La casi totalidad del software existente permite procesar estos dos tipos de amortizaciones.

• P. ¿Permite el software procesar las amortizaciones sustitutorias?

La amortización sustitutoria, que forma parte de los activos propios de la empresa, constituye el excedente de la amortización autorizada por el fisco sobre amortizaciones económicamente justificadas. Más concretamente, si se amortizan las inmovilizaciones de forma decreciente cuando la amortiza- ción económicamente justificada es la lineal, la diferencia entre las dos se traspasa a la cuenta de amortizaciones sustitutorias.

• P. ¿Permite el software procesar las revalorizaciones de inmovilizado?

El código de comercio autoriza, bajo ciertas condiciones, la revaloriza- ción del inmovilizado. El proceso contable de esta revalorización implica que se siga la diferencia de revalorización resultante de esta operación, de donde surgen los procesos informáticos apropiados.

• P. ¿Permite el software separar las adquisiciones y las cesiones, así como las plusvalías y las minusvalías obtenidas?

Ya hemos indicado la utilidad de estas informaciones para fines contables y financieros.

• P. ¿Se ha previsto conservar para cada inmovilización el historial de las amortizaciones practicadas?

Me he encontrado en varias ocasiones con software concebido para inmovilizaciones amortizadas de forma lineal, que no preveían la conserva- ción en el fichero del valor neto contable de los bienes. Éste era recalculado cada año desde el valor bruto y la fecha de inicio de la amortización.

Esta práctica resulta bastante peligrosa en la medida en que no deja ninguna pista de las modificaciones que se producen posteriormente a la primera anualidad de amortización en cuanto a las modalidades de la misma (período, tasa, importe bruto o modo). De este modo, conduce a una pérdida de la vía de revisión, pues las dotaciones del ejercicio que incluyen una recu- peración o un complemento de las dotaciones relativas a los ejercicios anteriores, de los cuales no conserva ningún rastro, ya no se justifican.


Es de desear, por tanto, que se conserve al final de cada ejercicio el valor neto contable de cada inmovilización y, en la medida de lo posible, el detalle de las amortizaciones anteriores.

• P. ¿Se llevan a cabo regularmente inventarios físicos de las inmovilizaciones?

Recordemos a título de información, al margen de las cuestiones relativas a la auditoría de la aplicación en sentido estricto, la importancia de un inventario físico regular de las inmovilizaciones.

Teniendo en cuenta la dificultad de una operación de esta índole, no obstante, es razonable que se lleve a cabo durante un período comprendido entre dos y cuatro años.

Si fuera el caso, se deben prever los listados informáticos específicos preparatorios de este inventario.

12.3 LA UTILIZACIÓN DEL SOFTWARE DE AUDITORIA

El desarrollo del software de auditoría para los ficheros del inmovilizado es particularmente útil en el caso de una revisión de la contabilidad. De hecho, permite una validación eficaz y exhaustiva de los cálculos en aquellos puntos en los cuales el revisor contable sólo habría podido controlar de forma manual un número muy limitado de fichas. Permiten, además, dar validez a la coherencia de algunos datos existentes en las fichas.

Citaremos, a título de ejemplo, los tests a tener en cuenta:

— El recálculo de las dotaciones del ejercicio. — La comprobación para cada inmovilización del respeto de una dotación

acumulada por lo menos igual a la amortización lineal (cuando la dota- ción acumulada es inferior al mínimo lineal, la diferencia entre las dos se pierde fiscalmente y no será deducible).

— El control de la coherencia de las fechas de inicio de la amortización de las inmovilizaciones (un error simple en la introducción de datos puede, en este caso, tener consecuencias financieras temibles).

— El control de la coherencia de la duración de la amortización. — El control de la coherencia entre la fecha de adquisición, la puesta en ex-

plotación y la fecha del principio de la amortización. — La validación de las plusvalías y minusvalías registradas.


Cuarta parte

LA GESTIÓN

DE LA AUDITORÍA

INFORMÁTICA

Hemos estudiado a lo largo de la segunda y la tercera parte de la obra los aspectos técnicos de la auditoría de un entorno informático y de la auditoría de una aplicación.

Sin embargo, la capacidad técnica del auditor, si bien es una condición necesaria para la calidad y para el buen fin de la misión, no es en sí misma suficiente. El éxito de la misión exige, de hecho, por parte del auditor tanto cualidades humanas y de relación como cualidades de gestor y de organizador.

• Las cualidades humanas y de relación

Sólo citaremos a título de información estas cualidades indispensables en todo auditor, y, en particular en el auditor de informática, debido al carácter técnico de la misión.

Éste deberá ser, en efecto:

— Un buen comercial, capaz de «vender» su misión. Si bien esta observa- ción pueda parecer una perogrullada en cuanto a los auditores externos, en la realidad, es también aplicable a los auditores internos, los cuales deben convencer a sus interlocutores de la legitimidad de la misión propuesta.

La gestión de la auditoría informática 181

— Un buen diplomático, capaz de conducir su misión en entornos algunas veces difíciles, incluso hostiles. Debe, en efecto, lograr que su presencia sea aceptada por los informáticos que se encuentran, gran parte del tiempo, sobrecargados de trabajo y presiones por los retrasos y que, ade- más, dudan de la utilidad y la oportunidad de la intervención.

— Un buen pedagogo, capaz de explicar el contenido o las conclusiones de misiones muy técnicas a públicos muy variados, desde el neófito más completo, que a menudo suele ser el Director General, hasta el mejor especialista de uno u otro campo.

• Las cualidades de gestor y de organizador

El éxito de la misión consiste en que su responsable haya sabido elegir las herramientas y métodos mejor adaptados al objetivo deseado, y que haya planificado el conjunto de las tareas en el tiempo deseado. La gestión de la misión no está, de hecho, exenta de dificultades y de «trampas», ante las cuales el auditor inexperto caerá en falta.

Éstos son los principales aspectos teóricos y prácticos de la gestión y de la organización de la misión que mencionaremos en esta cuarta parte. En- contraremos de forma sucesiva:

— Una presentación general de la diligencia del auditor informático. — Un enfoque de la conducción de la misión de auditoría de la función in-

formática. — Un enfoque de la conducción de la misión de auditoría de una aplicación

informatizada. — Un estudio del perfil del auditor informático y de los problemas relacio-

nados con su contratación y con su evolución.


Capítulo 13

Presentación general de la gestión

A lo largo de este capítulo volveremos sobre la misión general de la audi- toría informática, para desarrollar algunos aspectos ya citados en la primera parte de la obra.

13.1 LOS PARTICIPANTES

Recordemos algunos de los participantes potenciales de una misión de auditoría informática, aclarando los objetivos de cada uno de ellas.

13.1.1 El auditor de cuentas

a) El papel del auditor de cuentas

El auditor contable tiene como responsabilidad la verificación de que las cuentas presentadas estén regularizadas, sean verdaderas y que proporcio- nen una imagen fiel de la situación de la empresa. Su presencia es obligatoria en la gran mayoría de las empresas comerciales (sociedades anónimas, sociedades en comandita por acciones, así como, más allá de unos límites determinados, las sociedades de responsabilidad limitada, las sociedades en comandita simples y las sociedades colectivas) y en algunas sociedades, em-

Presentación general de la gestión 183

presas o agrupaciones (GIE, sociedades civiles inmobiliarias, asociaciones, etc.) más allá de determinados niveles.

b) El enfoque de la auditoría

La gestión del auditor contable se puede resumir muy brevemente por medio del esquema de la figura 6.

Figura 6. Presentación simplificada de la gestión del auditor de cuentas.

La fase de examen del control interno tiene como objetivo, para cada uno de los ciclos de la empresa,1 detectar los puntos fuertes y débiles y también aislar los principales factores de riesgo concernientes a la fiabilidad de las cuentas.

Los ciclos cuyo control interno sea considerado insuficiente serán objeto de controles contables generales, mientras que los ciclos cuyo control in-

1. Los principales ciclos de la empresa son: la producción, las compras, las ventas, la gestión del personal, la gestión de existencia, la contabilidad, la gestión de tesorería, la gestión de las inmovilizaciones.


temo sea considerado satisfactorio pueden ser objeto tan sólo de controles contables limitados.

c) Tipología de las intervenciones

Bajo el término de auditoría informática podemos imaginar tres tipos de intervenciones por parte del auditor de cuentas, son las siguientes:

— El examen del control interno de la función informática. La informática que conduce a la producción de diversos listados con repercusiones contables, la fiabilidad del entorno informático en sí mismo sólo puede constituir una preocupación del auditor de cuentas.

— El examen de aplicaciones informatizadas. Aquí también, estando la gran mayoría de los ciclos de la empresa altamente informatizados, el examen de la fiabilidad del control interno para cada uno de estos ciclos pasa por el examen de la fiabilidad de las aplicaciones.

— La utilización de la informática para controles contables. Numerosos asientos contables se originan, directa o indirectamente, por medio de los sistemas informáticos, algunas veces el control de las cuentas se facilita enormemente a través del desarrollo de software de control.

Por este motivo, los gabinetes de auditores de cuentas, por lo menos los más importantes, disponen de equipos de auditores informáticos cuya fun- ción es dar asistencia a los revisores contables en el marco de sus controles, programando software de análisis específicos.

d) Legitimidad de la intervención

El Plan General de Contabilidad Francés de 1982, de obligatorio cumplimiento para todas las empresas industriales y comerciales, según decreto del 27 de abril de 1982, modificado el 9 de diciembre de 1986, legitima totalmente las intervenciones informáticas del auditor de cuentas.*

«1. La organización del sistema de proceso debe garantizar todas las posibilidades de un control eventual...

2. El ejercicio de todo control debe comportar un derecho de acceso a la documentación relativa a los análisis, a la programación y a la ejecución de los procesos con vistas a proceder, entre otras cosas, a los tests necesarios.

(*) La legislación contable española no contempla este tipo de disposiciones.


3. Los procedimientos de proceso automático de las contabilidades deben estar organizados de manera que permitan controlar si las exigencias de seguridad y de fiabilidad requeridas en la materia han sido respetadas en su conjunto.»

De hecho no cabe duda de que la noción de «proceso automatizado de las contabilidades» cubre no solamente la contabilidad general en el sentido estricto del término, sino también generalmente los procesos ascendentes que crean los asientos contables (nómina, facturación, inmovilizaciones, etc.).

En cuanto al hecho de «controlar si las exigencias de seguridad y de fiabilidad requeridas en la materia han sido respetadas en su conjunto», se trata de hecho del examen del control interno de las aplicaciones a que atañe.

13.1.2 El auditor externo contratado

Las misiones que son susceptibles de ser confiadas a auditores externos contratados son de tipo muy diverso:

— Examen de control interno de la función informática. — Auditoría de la seguridad física del centro de proceso. — Auditoría de la confidencialidad de acceso (en el marco de una misión

importante, se harán los «tests de penetración»). — Auditoría de actuaciones. — Auditoría de una aplicación. — Etcétera.

Las competencias exigidas del auditor son, además, igualmente variadas. También, la presencia de uno o varios auditores informáticos puede ser

necesaria cuando se contraten misiones de auditoría más amplias, tales como:

— Auditoría contable o financiera contractual (el apoyo del auditor infor- mático será entonces similar al dado en el marco del auditor de cuentas).

— Auditoría operativa de un ciclo de la empresa (compras, ventas, tesore- ría, producción, etc.). El auditor informático tendrá que controlar entre otras cosas el software propio de este ciclo.

Por supuesto, la variedad de las misiones implica la variedad de las competencias exigidas para asumirlas y, por lo tanto, la variedad de los perfiles de los auditores.


13.1.3 El auditor interno

Las misiones susceptibles de ser confiadas al auditor informático interno son a priori las mismas que las susceptibles de ser confiadas a los auditores externos.

En cambio, si bien las misiones confiadas a los gabinetes externos son, a menudo, puntuales y responden a una necesidad específica, el auditor interno, que puede pertenecer tanto a la Dirección de Informática como al servicio de auditoría, se enfrenta a un problema delicado. ¿Cómo cubrir en un plazo razonable el conjunto de los riesgos informáticos? A continuación pro- pondremos un esbozo de respuesta a esta pregunta (apartado 13.2).

13.1.4 El controlador fiscal

El artículo 97.1 de la ley de finanzas francesa de 1982, cuyo texto se cita en el apartado 4.8, prevé explícitamente la posibilidad para la administración fiscal: *

— de controlar la documentación relativa a los análisis, a la programación y a la ejecución de los procesos;

— de llevar a cabo tests de control en los ficheros y software utilizados por la empresa.

La aplicación práctica de esta ley, a pesar de algunas precisiones aporta- das por el decreto nº 82-1142 de 29 de diciembre de 1982 y el artículo 103 de la ley de finanzas de 1990 (apartado 8), levanta, no obstante, varias interro- gantes tales como: ¿Cuál es el contenido de la documentación a ser entregada en caso de control? ¿Cuáles son los ficheros y software a salvaguardar?... Las precisiones complementarias sobre la materia estarían bienvenidas.

13.2 EL PLAN PLURIANUAL DE AUDITORIA INFORMÁTICA

La definición de un plan plurianual, que permita cubrir en un período «razonable» (por ejemplo, del orden de 3 a 4 años) el conjunto de los compo-

(*) La normativa fiscal española no contempla este tipo de disposiciones.


nentes del riesgo informático, se plantea tanto a los auditores internos como a los auditores de cuentas. Éstos tienen además bastante interés en definir los programas de trabajo complementarios en la materia.

Por supuesto, no es posible definir un «plan de auditoría tipo» aplicable a todas las empresas. Las prioridades son específicas de cada entorno. Noso- tros nos limitaremos, por tanto, a proponer una cronología lógica de las intervenciones.

Por lo general y de hecho es deseable, en el momento de una primera in- tervención en un emplazamiento, proceder a un reconocimiento del entorno y a un examen del control interno de la función informática.

Esta primera intervención permitirá, en efecto, no solamente hacer un primer diagnóstico sobre la función informática, sino también preparar las misiones futuras en las mejores condiciones.

Durante las intervenciones posteriores, es deseable prever, en un ciclo de algunos años, la auditoría del conjunto de las principales aplicaciones infor- máticas. Por último, se preverá como necesidad, auditorías generales de ciertos campos en particular (seguridad física, seguridad lógica, etc.) utilizando, si fuere necesario, empresas especializadas en alguno de estos campos.

A título ilustrativo, veremos a continuación dos ejemplos, voluntaria-

Plan plurianual de la intervención del equipo de auditores informáticos de un gabinete de auditoría en el marco de la auditoría de cuentas de una

PYME con un emplazamiento informático único

Temporada2 Trabajos planificados 1991/1992 Toma de conocimiento con el entorno informático

Examen limitado del control interno de la función informática

1992/1993 Análisis de la aplicación de gestión de ventas y de contabilidad auxiliar de clientes

1993/1994 — Actualización del informe de 1992 sobre el control interno de la función informática — Análisis de la aplicación de gestión de existencias

1994/1995 — Análisis de aplicación de gestión de compras y de contabilidad auxiliar de proveedores

Nota: Las aplicaciones de gestión de las inmovilizaciones y de proceso de la nómina se han considerado como exentas de riesgos por los revisores contables, y no dan lugar a una misión específica.

2. La misión del auditor de cuentas es una misión permanente, pero los programas de trabajo se definen generalmente por «temporada», que va de septiembre a junio. De este modo, en el marco del control de las cuentas del ejercicio 1991, los trabajos interinos se llevarán a cabo en el otoño de 1991, aunque el control final de las cuentas tendrá lugar en el curso del primer semestre de 1992.


Plan plurianual de la intervención del equipo de auditoría informática interna en un grupo empresarial con emplazamientos múltiples

Año Trabajos planificados

1992 — Examen del control interno de la función informática en la sede en París. — Auditoría general de informática de la filial X — Examen limitado del control interno informático del establecimiento de Lyon y estudio general del software de gestión de pro- ducción de este establecimiento

1993 — Auditoría general de la informática de la filial Y — Análisis de la aplicación de gestión del personal en la sede — Examen general del control interno informático del establecimiento de Lille

1994 — Estudio del conjunto de la gestión de la seguridad informática en el grupo. — Auditoría del software de gestión de existencias del establecimiento de Lille — Auditoría general de la informática en la filial Z

1995 — Examen del control interno de la función informática en la sede en París (actualización del informe de 1992) — Estudio del conjunto de la gestión de la seguridad física en el grupo (misión llevada a cabo conjuntamente con un gabinete extemo) — Auditoría del software de gestión de pedidos y de facturación del establecimiento de Lyon

mente simplificados, de planes plurianuales de auditoría informática, el primero relativo a las intervenciones de un auditor de cuentas en uno de sus clientes y el segundo relativo a las actuaciones del servicio de auditoría interna de un grupo de empresas.

13.3 EL PROGRAMA ANUAL DE TRABAJO

El programa anual de trabajo empieza estableciendo las fechas y las modalidades de actuación, las misiones previstas en el plan plurianual. Ade- más, algunos trabajos diversos, eventualmente no indicados en el plan plurianual, se incluirán en este programa de trabajo. Se trata, por ejemplo de:

— Misiones de asistencia, puntuales o recurrentes, tales como: participa- ción en la definición de una nueva aplicación (por ejemplo, bajo el án-


guio de la seguridad), participación en talleres de tipo MARIÓN (apartado 4.1).

— Trabajos específicos realizados por los auditores informáticos en el marco de misiones de auditoría operativa o de auditoría financiera.

En esta página y en la siguiente señalaremos a título informativo los planes anuales correspondientes a los planes plurianuales del apartado 13.2.

Nota: Las cargas de trabajo que aparecen en estos ejemplos son mera- mente indicativas. Volveremos con más detalle en los capítulos 14 y 15 sobre la estimación del volumen de trabajo a prever en el marco de las misiones de auditoría.

Plan anual del equipo de auditores informáticos en el marco de una auditoría de cuentas en una PYME (Temporada 91-92)

Fecha Naturaleza de la actuación Carga de trabajo (en jornadas-hombre)

Octubre 1991

Toma de conocimiento con el entorno informático Examen limitado del control interno de la función informática

8

Diciembre 1991

Preparación y test de software de auditoría aplicable al fichero de las inmovilizaciones, para analizar los resultados en el marco de los trabajos de control de las cuentas

5

Marzo 1992

Ejecución de software de auditoría relativo al fichero de las inmovilizaciones al final de 1991

2

13.4 LAS HERRAMIENTAS DEL AUDITOR INFORMÁTICO

Repetimos aquí dos tipos de herramientas importantes, de las cuales puede disponer el auditor informático en el marco de su actividad:


Plan anual del equipo de auditoría informática interna (2 auditores) del Grupo para 1992

Fecha Naturaleza de la actuación Carga de trabajo (en jornadas-hombre)

Enero a marzo

Examen del control de la función informática en la sede

60

Abril a mayo

Participación de un auditor en la misión de auditoría de la gestión de la tesorería del grupo

40

Abril a julio

Auditoría general de la informática en la filial X

80

Septiembre a

diciembre

Ejemplo limitado del control interno informático del establecimiento de Lyon y estudio general del software de gestión de producción de este establecimiento

80

A partir de

septiembre

Participación en un grupo de trabajo «Seguridad», en el marco de la creación de una nueva aplicación de gestión de aprovisionamiento del Grupo

20

Enero a diciembre

Participación en un taller MARIÓN sobre la seguridad informática

10

Noviembre diciembre

Participación de un auditor en una misión de auditoría contable de una filial

20

Formación de los auditores informáticos 20

Potencial disponible para misiones excepcionales no planeadas

70

— Los métodos de análisis de riesgos informáticos. — El software de auditoría.

13.4.1 Los métodos de análisis de riesgos informáticos

Existen en el mercado diferentes métodos cuyo objetivo es suministrar una evaluación global de la seguridad y de los riesgos informáticos en el seno de una empresa.


Entre ellos el más conocido es, sin lugar a dudas, el método MARIÓN,3

elaborado por el CLUSIF (Club de la Seguridad Informática Francesa) ema- nado de la APSAIRD (Asamblea Plenaria de Sociedades de Seguros contra el Incendio y los Riesgos Diversos).

Citemos igualmente el método MELISA, desarrollado para la defensa nacional.

Estos métodos tienen todos en común el suministro de:

— Un cuestionario detallado de la evaluación del riesgo: cada pregunta da lugar a una anotación del entorno estudiado.

— Una presentación clara de los resultados de la evaluación, generalmente después de la introducción de las respuestas al cuestionario en un microordenador y del proceso de los resultados.

Podemos citar para ilustrar esta facilidad el célebre «rosetón» de presen- tación de los resultados de un taller MARION (figura 7). Cada campo que lo conforma recibe, después de procesar los resultados del cuestionario detallado, una nota global comprendida entre 0 (nivel de riesgo máximo) y 4 (seguridad máxima), y las calificaciones obtenidas por cada campo se representa en un rosetón.

Si nos fijamos bien, existen, no obstante, diferencias notables entre estos métodos de evaluación del riesgo. De este modo, MARION no es un método de auditoría, sino más bien un método de autoevaluación del riesgo por parte de los propios informáticos y usuarios. La buena evolución de un taller MA- RIÓN necesita, sin embargo, la presencia de un animador que conozca perfectamente el método. Esta es la razón por la cual la gran mayoría de las empresas que efectúan un taller MARION recurren a la asistencia, aunque de forma puntual, de un gabinete de asesores externos.

13.4.2 El software de auditoría

Ya hemos mencionado en la primera parte de la obra (ver apartado 1.3.4 d) la utilización por parte de los auditores de lenguajes de interroga- ción de ficheros, a veces llamados errónea o acertadamente, programas de auditoría.

Encuentran su utilidad en la gran mayoría de las misiones confiadas al auditor informático. De este modo:

3. Metodología de Análisis de Riesgos Informáticos y de Optimización por nivel.


Figura 7. Ejemplo de representación de evaluación de la seguridad de un entorno informático según el método MARIÓN.

— En el marco de una auditoría de aplicación, permiten controlar el contenido de los ficheros y detectar anomalías eventuales.

— En el marco de la asistencia a la revisión contable, permiten validar los resultados de algunos procesos, o también poner en evidencia las informaciones anómalas o erróneas.

Volveremos posteriormente en el capítulo 15 sobre las modalidades prác- ticas de la utilización de los programas de auditoría.


PRESENTACIÓN SIMPLIFICADA DEL MÉTODO MARIÓN

El método MARIÓN comporta seis etapas:

— El análisis de los riesgos tiene como objetivo el recuento de los riesgos y la evaluación del coste máximo de pérdidas consecutivas a cada riesgo enumerado.

— La expresión del riesgo máximo admisible permite definir, de acuerdo con la Dirección de la empresa, el nivel crítico a partir del cual el riesgo ya no es admisible.

— El análisis de la seguridad existente, basada en las respuestas a un cuestionario de evaluación, establece una síntesis del riesgo en que se incurre en la forma del célebre «rosetón» (figura 7).

— La evaluación de los inconvenientes permite tener en cuenta lo existente en el análisis de los riesgos y la definición de las soluciones: inconvenientes técnicos, humanos.

— La elección de los medios define los medios a aplicar para mejorar la seguridad de manera coherente.

— La definición del plan de seguridad define las modalidades prácticas se- gún las cuales la seguridad será mejorada.

¿A FAVOR O EN CONTRA DE MARIÓN? Los argumentos a favor o en contra del lanzamiento de talleres de análisis del

riesgo de tipo MARIÓN están ampliamente desarrollados en la obra Les techniques de l'organisation informatíque. Citaremos aquí algunos de una forma simplificada.

A FAVOR: — El lanzamiento de un taller de tipo MARIÓN permite estar seguro de con-

tar con un soporte metodológico. — Un taller de análisis del riesgo permite sensibilizar al conjunto de los acto-

res, tanto informáticos como usuarios, sobre el problema de la seguridad. — La atribución de notas tiende a fundamentar la evaluación del riesgo en

criterios objetivos.

EN CONTRA: — Los talleres de análisis llevan a menudo a una autoevaluación del riesgo

por parte del personal de la empresa, por lo que es difícil creer que sea del todo objetiva.

— Si bien tales talleres aportan, por lo general, una buena apreciación de la candad del control interno de la función informática, permiten con mucha más dificultad apreciar la fiabilidad de las aplicaciones.

— La aplicación de una misión de este tipo es a menudo costosa, tanto en tér- minos de intervenciones externas como, y sobre todo, en lo relativo a la falta de disponibilidad del personal de la empresa.

En resumen, podemos considerar que la aplicación de un taller de tipo MARIÓN será aún más útil cuando el personal esté insuficientemente sensibilizado con los problemas de seguridad informática.


Capítulo 14

La dirección de la misión de auditoría

Recordaremos a lo largo de este capítulo las modalidades prácticas de la dirección de una misión de auditoría informática, poniendo en evidencia las etapas que deben necesariamente ser respetadas en la intervención y los principales problemas prácticos que pueden surgir en el curso de cada una de estas etapas.

Además, si bien se puede considerar que existe una metodología general de intervención, cualquiera que sea la naturaleza exacta de la misión, no se- rán menos las peculiaridades importantes según el tipo de objetivo. De este modo, los métodos de investigación propios de una auditoría pueden ser bastante diferentes de los métodos de investigación propios del examen del control interno de la función informática. Cada tipo de intervención será objeto de desarrollos específicos.

14.1 LA PREPARACIÓN DE LA MISIÓN

Es difícil definir una norma en cuanto a la duración y a las modalidades prácticas exactas de la fase de preparación de la misión. De este modo, una auditoría externa tendrá como objetivo, por razones comerciales, fijar lo más rápidamente posible una primera propuesta de intervención, con el riesgo de prever en la misma una fase de investigaciones previas a partir de la cual se fijarán los límites de la misión.

La dirección de la misión de auditoría 195

En cambio, un servicio de auditoría interna, libre de la obligación financiera relativa a la incertidumbre en cuanto a la aceptación o no de una propuesta, podrá preferir, según sea el caso, una fase de estudio preliminar relativamente extenso, con el fin de llegar a una propuesta de intervención lo más precisa y completa posible, o bien, una fase preliminar extremadamente corta, con una propuesta de intervención lo más abierta posible.

Esto no quiere decir que algunos trabajos preparatorios sean indispensables para el buen desarrollo de la misión. De una manera general, se trata del conjunto de las investigaciones necesarias para la elaboración de dos documentos previos al inicio de la misión, uno para uso externo y el otro para uso interno.

El documento para uso interno constituirá el programa de trabajo de los auditores.

14.1.1 La propuesta de intervención

Este documento materializa el acuerdo entre el que solicita la misión (a menudo la dirección general de la empresa) y el que la tiene que ejecutar (auditoría externa o auditoría interna) sobre el contenido y las modalidades prácticas de la misión. Legitima, además, la intervención ante los servicios auditados. Estudiemos ahora las principales incertidumbres que deben ser eliminadas por medio de este documento.

a) Los objetivos de la misión

Hemos mostrado en la primera parte de la obra que los objetivos que se buscan en una misión de auditoría informática podrían ser muy variados, tales como: examen del control interno de la función informática, examen de la seguridad física, auditoría de las protecciones de acceso, control de los métodos de desarrollo, auditoría de las actuaciones, auditoría de una aplica- ción específica, etc.

La propuesta de intervención deberá, por tanto, eliminar cualquier ambi- güedad aclarando los objetivos a que se destina.

b) El perímetro de la misión

La propuesta de intervención definirá claramente las empresas y establecimientos y los emplazamientos correspondientes para los trabajos. En el caso de una auditoría de aplicación, serán las funciones auditadas las que se autodefinirán.


c) El período de intervención

Se especificarán aquí la duración global de la misión y sus plazos principales (fecha de inicio y fin de los trabajos, etapas intermedias, fecha de envío de las conclusiones, etc.)

d) Los inconvenientes a tener en cuenta para los servicios auditados

En particular, es de desear que se precise, desde el inicio de la misión, la disponibilidad que será exigida a los servicios auditados. La sobrecarga de trabajo demasiado elevada causada por una auditoría es, a menudo, objetada por éstos, por error o con razón, y es, también, la causa de relaciones di- fíciles.

En el caso de utilizar software de auditoría, los inconvenientes específi- cos deben ser previstos también por los servicios auditados. Volveremos sobre este tema en el capítulo 15.

De la misma manera, la aplicación del juego de prueba necesita, la mayo- ría de las veces, un trabajo preparatorio importante.

e) Los métodos de trabajo empleados

La definición detallada de los métodos de trabajo empleados es más bien de incumbencia del programa de trabajo, documento interno, que de la propuesta de intervención. No obstante, es deseable especificar, por lo menos a grandes rasgos, estos métodos de trabajo: utilización o no de cuestionarios, métodos basados en las entrevistas o en el estudio de documentos, aplica- ción de juegos de prueba, utilización de software, etc.

f) La formación del equipo

La composición del equipo y el nombre del responsable de la misión se- rán especificados aquí. En el caso de misiones importantes de auditoría externa, es deseable, por lo general, que se suministre un curriculum vitae muy sucinto de los diferentes participantes.

g) Los documentos preparatorios

Con el fin de facilitar la puesta en marcha de la misión, una lista de documentos preparatorios a ser suministrada a los auditores será, si fuera el caso, incluida en las propuestas de intervención, o transmitidas a los servicios auditados previamente a la primera entrevista. Éstos serán, por ejemplo:


Para un examen del control interno de la función informática

- El organigrama del servicio. - La descripción de la configuración física. - Una descripción sucinta del software utilizado. - La lista de los programas. - Las notas principales relativas a la actividad informática en la empresa y a la organización del servicio. - El plan informático. - El presupuesto del servicio informático. - Los informes de las últimas reuniones del comité de informática.

• Para una auditoría de una aplicación informatizada

— El organigrama del servicio y la lista de los principales interlocutores a encontrar (usuarios e informáticos).

— Los documentos de presentación de la aplicación. — Si fuera el caso, la descripción del contenido de algunos ficheros en los

cuales se espera realizar controles.

Programa de trabajo de la misión de auditoría del software de gestión del personal por parte del auditor de cuentas en un entorno PYME (presupuesto

80 horas)

— Lanzamiento de la misión 4 horas — Toma de conocimiento de la aplicación: entrevis-

tas con el jefe de proyecto y con los principales usuarios, lectura de la documentación disponible 16 horas

— Análisis crítico de las prestaciones de la aplica- ción (véase cuestionario estándar) 8 horas

— Examen del control interno de la función infor-

mática para esta aplicación: procedimientos de desarrollo y explotación, análisis de la documen- tación, etc. (véase cuestionario estándar) 16 horas

— Desarrollo de software de auditoría (prestaciones a ser definidas en el momento de la toma de conocimiento de la aplicación) y análisis de los resultados 20 horas

— Redacción del informe y síntesis 16 horas

198

Técnicas de la auditoría informática

14.1.2 El programa de trabajo

El programa de trabajo define claramente los métodos de auditoría elegidos y el trabajo a realizar por parte de los auditores.

Contiene una división de las cargas de trabajo previstas para cada mó- dulo de auditoría.

En el recuadro que aparece al final de la página anterior se incluye un ejemplo de programa de trabajo resumido de una misión de auditoría de apli- cación.

En el próximo apartado trataremos la elección de los métodos de investi- gación, y de la carga de trabajo necesaria para llevar a cabo el conjunto de las tareas previstas.

14.2 LOS MÉTODOS DE INVESTIGACIÓN

Distinguiremos en este campo la auditoría del control interno de la fun- ción informática y la auditoría de una aplicación informatizada. Pero antes que nada, sin ningún lugar a duda, vale la pena recordar brevemente las ca- racterísticas generales de la metodología en materia de auditoría del control interno.

14.2.1 La gestión general de la evaluación del control interno

Veremos en la figura 8 una presentación esquemática del enfoque de eva- luación del control interno.

La toma de conocimiento y el análisis de los procedimientos del sistema evaluado permiten evidenciar sus puntos fuertes y débiles teóricos. De todos modos, un punto fuerte teórico sólo lo es realmente cuando el procedimiento descrito es exactamente el que se describe. El objeto de los tests de permanencia es asegurar esta permanencia de la aplicación del procedimiento teórico.


Figura 8. Evaluación del control interno.

14.2.2 La evaluación del control interno de la función informática

a) La evaluación de los puntos fuertes y débiles teóricos El análisis de los procedimientos, necesario para una primera evaluación

de las fuerzas y debilidades del sistema, se hará esencialmente a través de:

— Entrevistas a los responsables del servicio de informática y, por lo general, a los principales servicios de usuarios.

— Un trabajo sobre el conjunto de los documentos disponibles en el servicio: plan informático, normas internas, organigramas, plan de seguridad, etc.


Los cuestionarios de auditoría detallados pueden constituir un apoyo para el auditor. Sin embargo, podemos considerar que los principales puntos clave que conviene estudiar en el marco de esta evaluación del control interno son aquellos que han sido descritos en la segunda parte de la obra.

b) Los tests de permanencia Una cualidad primordial de un buen auditor será la validación sistemá-

tica de sus conclusiones. No es cuestión de describir aquí los procedimientos de validación para cada punto auditado. Éstos surgen, la mayoría de las veces, de sí mismos.

Sin embargo, a título de información, encontraremos en el cuadro que se expone a continuación ejemplos de un programa de validación de las respuestas a algunas de estas cuestiones descritas en la segunda parte de la obra.

EJEMPLO DEL PROGRAMA DE VALIDACIÓN DE LAS CONCLUSIONES EN MATERIA DE CONTROL INTERNO DE LA FUNCIÓN INFORMÁTICA

A continuación veremos ejemplos de un programa de trabajo para la vali- dación de las respuestas a algunas preguntas relativas al examen del control externo de la función informática.

La organización general del servicio de informática Pregunta: ¿Hay un plan informático? Validación: Obtener una copia del plan informático P.: ¿Se hace un seguimiento de la actividad del personal de informática? V.: Controlar las fichas de actividad más recientes de algunos colaboradores

del servicio de informática. P.: ¿Cualquier elección de prestación material (equipos) o de software da lu-

gar a un concurso público? V.: Pedir los concursos y el análisis de las ofertas para las últimas adquisicio-

nes más significativas.

Los procedimientos de desarrollo y de mantenimiento de las aplicaciones P.: ¿Se elabora siempre un pliego de condiciones previo al lanzamiento de la

realización de nuevo software? V.: Pedir los pliegos de condiciones de las últimas aplicaciones puestas en ex-

plotación. P.: ¿Existen normas en materia de desarrollo de aplicaciones? V.: Pedir el dossier de las normas de desarrollo, y controlar su calidad y su

exhaustividad. P.: ¿Son los proyectos objeto de una coordinación suficiente? V.: Pedir los informes de reunión de los grupos de trabajo encargados de la

coordinación.


El entorno de producción P. : ¿Son satisfactorios los procedimientos de puesta en explotación del software? V. : Controlar por sondeo la coherencia entre las versiones fuente y objeto del

software que está siendo utilizado. P. : ¿Se edita y archiva sistemáticamente el «diario de a bordo»? V. : Pedir el diario de a bordo de una jornada tomada al azar. P. : ¿Se analiza con regularidad el contenido de los discos para suprimir fi-

cheros inútiles? V. : Seleccionar algunos ficheros que figuren en el espacio disco y asegurarse

de que todavía están en uso. P. : ¿Se salvaguardan con regularidad el conjunto de los ficheros y software

necesarios para el desarrollo y la explotación? V. : Seleccionar algunos ficheros en una o varias aplicaciones y asegurarse de

que exista una versión de seguridad. P. : Cuando la cantidad lo justifique, ¿hay un software de gestión de las cintas

o de los cartuchos? V. : Seleccionar algunas cintas mencionadas en el software y verificar que se

encuentren en sitio seguro (y eventualmente que sus contenidos sean verdaderamente los indicados), después seleccionar algunas cintas de los lugares de almacenaje y verificar si están incluidas en el software.

P. : ¿Se ha previsto un procedimiento que permita un rearranque en un emplazamiento exterior en un plazo satisfactorio?

V. : Verificar que el procedimiento haya sido probado hace menos de 6 meses. Pedir el informe del test.

14.2.3 La auditoría de la aplicación

Hemos citado en la primera parte de la obra la diversidad de los objetivos que se busca en el marco de una auditoría de aplicación y que son:

—Auditoría de la adecuación del software desarrollado a las necesidades especificadas en el pliego de condiciones.

— Auditoría de la adecuación del pliego de condiciones a las necesidades de un control interno satisfactorio (posibilidad de controles jerárquicos y de una separación de funciones, continuidad de la vía de revisión, et- cétera).

— Auditoría de la adecuación del pliego de condiciones a las necesidades de una gestión eficaz (se verificará que todas las prestaciones necesarias para la optimización de la actividad de los usuarios hayan sido previstas).

— Auditoría de la utilización del software (se verificará, por ejemplo, que los controles de explotación adaptados hayan sido aplicados, que las protecciones de acceso previstas sean efectivas, etc.).

— Auditoría de la calidad técnica de los métodos de desarrollo empleados y del software realizado.


— Auditoría del control interno de la función informática para esta aplica- ción (calidad del software, los procedimientos de explotación).

— Etcétera.

Hemos subrayado igualmente la dificultad que encuentra el auditor para dar respuesta a estos objetivos, y la complementariedad de los diferentes medios a su alcance, los cuales pasamos a enumerar a continuación:

• La entrevista

Además de las entrevistas con los responsables del desarrollo y de la ex- plotación de la aplicación, se programarán igualmente entrevistas con los principales usuarios involucrados.

• Los controles de la documentación

Según los objetivos exactos de la misión, harán referencia, por ejemplo, a:

— Los documentos previos al desarrollo de la aplicación (esquema guía, estudio previo, estudio detallado).

— La documentación de estudio. — La documentación de explotación. — Los manuales para los usuarios. — Los manuales de procedimientos. — Los programas mismos.

No obstante, notaremos que, salvo estudio a fondo, el auditor, la mayoría de las veces, sólo podrá pronunciarse sobre el aspecto formal de estos documentos, pero no sobre el fondo de su contenido.

• Juegos de prueba

Esencialmente permiten controlar la adecuación del software desarrollado en el pliego de condiciones. En cambio, no aportan ninguna ayuda a la evaluación de la calidad del pliego de condiciones.

Además, su principal inconveniente estriba en la carga de trabajo importante que implican, tanto para los auditores como para los auditados.

• El desarrollo de software de auditoría

Los programas permitirán llevar a cabo los controles:


— bien sobre el contenido de algunos ficheros, verificando la coherencia de los datos;

— o bien en la fiabilidad de algunos procesos, desarrollando software que tenga funciones más o menos similares.

Si bien no permiten pronunciarse sobre la fiabilidad del conjunto de la aplicación, por lo menos suministran los resultados concretos. Las anoma- lías eventualmente detectadas son, en este sentido, indicadores valiosos.

El capítulo 15 estará dedicado en particular a la utilización del software de auditoría.

• La realización de «códigos» de control de los procesos

Si bien el diseño de estos códigos es, en principio, de incumbencia de los servicios de usuarios, algunos controles simples dan al auditor una primera idea de la coherencia de los procesos. De este modo, en materia de contabilidad, el auditor podrá confrontar:

— Las cuentas generales y las auxiliares. — Los diarios, los libros de mayor y los balances.

14.3 LA VALORACIÓN JDEL VOLUMEN DE INTERVENCIÓN

La apreciación de la carga de trabajo a tener en cuenta para realizar la mi- sión presenta el problema crucial de la necesidad de un compromiso entre la búsqueda de un coste de intervención mínimo y la realización de unas investigaciones lo más completas posibles.

De antemano, conviene tener bien claro que, aunque la carga de realiza- ción de una aplicación, que responda a las necesidades claramente definidas en un pliego de condiciones, es fija e incompresible, la carga de realización de una auditoría informática está en función del programa de trabajo y puede también modularse, por lo menos dentro de ciertos límites.

El objeto de este apartado es definir los dos límites «razonables»:

— Un límite inferior por debajo del cual es razonablemente imposible llevar a cabo una apreciación motivada.

— Un límite superior más allá del cual la aportación marginal de las investigaciones complementarias a las conclusiones de la auditoría es demasiado limitada para que tengan algún interés.


a) Examen del control interno de la función informática

Veremos en el cuadro que sigue una estimación bastante indicativa de las cargas de trabajo a tener en cuenta para una misión general de examen del control interno de la función informática.

Cargas de trabajo indicativas para el examen del control interno de la función informática

Pequeño centro

de proceso1 Centro de proceso de

porte medio2 Gran centro de proceso3

Examen limitado del control interno de la función informática

2-3 d 5-7 d 8-10 d

Examen «normal» del control interno de la función informática

5-7 d 10-12 d 15-30d

Examen completo del control interno de la función informática

10-15 d 20-30 d 40-80 d

1. Se consideran pequeños los centros con menos de 10 a 15 personas y cuyo presupuesto sea de menos de 200.000 a 250.000 PTA.

2. Se consideran medios los centros con personal entre 10 y 100 personas y el presupuesto entre 250.000 y 1.500.000 PTA.

3. Se consideran grandes los centros en los cuales el personal suma más de 100 personas o el presupuesto sea superior a 1.500.000 PTA.

Esta estimación no incluye, sin embargo, instrucciones completas eventuales sobre los aspectos especiales (estudio de la seguridad física, estudio de las protecciones de acceso con tests de penetración, estudio de las actuaciones, etc.), las cuales pueden presentar cada una de ellas varias decenas de días de trabajo.

Debe ser, además, manipulada con prudencia. En efecto, la carga de trabajo, independientemente de la magnitud del centro, depende de varios pará- metros, como por ejemplo: perímetro exacto de la misión, procedimientos de validación, calidad y acabado del informe, etc.


b) Auditoría de una aplicación Veremos en el cuadro siguiente una estimación, igualmente bastante in-

dicativa, de las cargas de trabajo que se deben tener en cuenta para una mi- sión de auditoría de aplicación.

Estimación indicativa de la carga de trabajo de una auditoría de aplicación

Pequeña aplicacióna

Aplicación mediab

Aplicación importantec

Examen limitado de la aplicación1

2-3 d 5-7 d 8-10d

Auditoría «normal» de la aplicación2

5-10d 10-15 d 20-30 d

Auditoría profunda3 20-30 d 30-60 d 60-100 d

1. El examen limitado consistirá en un control formal de los procedimientos de desarrollo y de la docu- mentación, así como de un análisis muy sucinto de las principales funcionalidades. Se basa esencialmente en las entrevistas y en un control directo de la documentación.

2. La auditoría «normal» debe permitir un control formal relativamente profundo, acompañado de una revista de las principales funcionalidades.

3. La auditoría profunda utilizará técnicas de control más sofisticadas que las entrevistas y los controles directos: desarrollo de software de control, juego de prueba.

a) Se considera pequeña una aplicación cuya carga de desarrollo sea inferior a 100 d x h. b) Se considera mediana una aplicación cuya carga de desarrollo esté entre 100 y 500 d x h. c) Se considera importante una aplicación cuya carga de desarrollo sea superior a 500 d x h.

Si bien esta estimación debe ser también manipulada con prudencia, no obstante, es innegable que la auditoría de una aplicación constituye una ope- ración costosa para una eficacia desigual.

Los métodos de investigación, al igual que el nivel del detalle de las tareas planificadas, también se deben definir con cuidado.

14.4 LA PRESENTACIÓN DE LAS CONCLUSIONES

El final de la misión de auditoría se materializa, por lo general, con una presentación contradictoria con los servicios auditados de las principales conclusiones, seguido de la emisión de un informe. Además de un análisis


crítico, es deseable que el informe aporte una síntesis de las recomendaciones formuladas por el auditor.

14.5 EL SEGUIMIENTO DE LAS RECOMENDACIONES

Cuando se hayan enumerado las debilidades graves es bastante deseable que los auditores puedan asegurar un seguimiento de la aplicación de las recomendaciones formuladas por ellos. Este seguimiento se podrá, entre otras cosas, asegurar:

— bien a través de una participación regular en las principales reuniones de síntesis relativas al avance de los trabajos;

— o bien, a través de la realización de misiones breves de actualización del informe.


Capítulo 15

La utilización de los programas informáticos de auditoría

Hemos citado en varias ocasiones a lo largo de la obra el desarrollo, por parte de los auditores, de programas informáticos específicos de control en el marco de su misión.

El presente capítulo constituye una síntesis relativa a la utilización de esta técnica, dejando claro por supuesto que, incluso cuando utilizamos el término «software de auditoría», el lenguaje de programación empleado no es necesariamente un lenguaje dedicado a los auditores y puede ser una herramienta de infocentro, incluso un lenguaje de programación tradicional. En los entornos específicos, he tenido que desarrollar en varias ocasiones software de auditoría en COBOL.

15.1 LOS OBJETIVOS DEL DESARROLLO DE UN SOFTWARE DE AUDITORIA

Distinguiremos estos objetivos según se trate:

— De una misión de auditoría de aplicación. — De la asistencia a la auditoría contable, campo en el cual se aprecia en

particular el aporte del software de auditoría.


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

Los objetivos que se buscan serán esencialmente de dos tipos:

a) Control de la coherencia de los datos que figuran en los ficheros

El objetivo aquí será buscar en los ficheros que conforman la aplicación los datos «dudosos», susceptibles de detectar anomalías en el software o en la aplicación de los procedimientos.

Citemos algunos ejemplos simples:

— En un software de control de existencias, selección de existencias negativas en el inventario informático permanente. Unas existencias negativas traducen un error del software, o un error en la introducción de datos, o también una mala aplicación de los procedimientos (registro de una salida antes del registro de una entrada, la cual era cronológicamente previa a ésta).

— En un software de facturación, selección de facturas para las cuales los artículos hayan sido facturados a un precio diferente del que aparece en el fichero de lista de precios: otra vez veremos la señal, en caso de diferencias importantes no justificadas por condiciones especiales concedi- das voluntariamente al cliente, bien de un error en la introducción de datos, o bien, de un error de programación del software.

— En un software de gestión comercial, selección de los clientes que tengan descuentos superiores a ciertas normas, que puedan proceder de anoma- lías en la introducción de datos o bien por incumplimiento de los procedimientos por parte de los comerciales.

b) Control de la coherencia de los resultados de los programas que conformen la aplicación

Este control se llevará a cabo:

— Por medio del desarrollo de un software que tenga estrictamente las mismas funciones que el software auditado, el cual debe también llevar al mismo resultado.

— Por medio del desarrollo de un software que tenga funciones similares, que permitan controlar la coherencia de los datos resultantes de la apli- cación.

La utilización de los programas informáticos 209

• Desarrollo de un software que tenga las mismas funciones

Esta técnica sólo puede ser utilizada de una manera puntual, y para una prestación en particular. En el caso contrario, conducirá a una segunda re- dacción de la aplicación auditada, con las consecuencias que podemos imaginar en la duración y el coste de la auditoría.

De este modo, podemos imaginar:

— El recálculo del importe de las existencias valoradas a partir del fichero de inventario.

— El recálculo del total de los créditos de clientes superiores a 6 meses, a partir del fichero de cuentas de clientes.

— El recálculo de la dotación contable a las amortizaciones del ejercicio, a partir del fichero de las inmovilizaciones.

• Desarrollo de un software que tenga funciones similares

Permite definir un software de auditoría cuyas prestaciones serán más sencillas que las del software auditado, pero cuyos resultados darán elementos de comparación.

Citamos por ejemplo:

— Una estimación para un mes dado de la masa salarial neta, a partir del fichero de personal y de una evaluación global de las cargas sociales. Nos basaremos en un fichero «fin de mes» sin tener en cuenta los casos particulares de modificaciones habidas durante el mes.

— Una estimación de la cifra de negocios del mes partiendo de las facturas emitidas en el mes.

15.1.2 La asistencia a la revisión contable

Se puede manifestar:

— En el marco de las tareas denominadas «interinas», realizadas durante el ejercicio, en particular cuando éstas se refieren a la valoración del control interno de un ciclo de la empresa.

— En el marco de las tareas de control de las cuentas propiamente dichas, posterior al cierre del ejercicio.

Veremos en este marco varios tipos de software.


• El software de análisis del contenido de los ficheros

El objetivo será poner en evidencia las anomalías existentes en el contenido de los ficheros, como en el caso de la auditoría de aplicación, o bien, los datos significativos por su importancia que necesitan un análisis complementario.

Así, en un software de gestión de préstamos, en un establecimiento financiero, se separan todos los préstamos superiores a un cierto nivel para analizar en el dossier las condiciones de concesión de este préstamo.

• El software de validación de los resultados obtenidos de la aplicación con una incidencia contable directa

Se intentará también dar validez dentro de la aplicación de control de existencias a la valorización del inventario al cierre, al cálculo de las diversas provisiones (provisión para rotación lenta, provisión para la subida de los precios), al valor de las mercancías recibidas y no facturadas por el proveedor, etc.

• El software que tenga como única función la automatización del trabajo del revisor contable

Citemos, por ejemplo:

— El envío de las cartas circulares a algunos clientes. — La automatización de los procedimientos de muestreo previos a los con-

troles de los documentos.

15.2 LA ELECCIÓN DE UN SOFTWARE DE AUDITORIA

Se impone una pregunta previa: ¿Es preferible que el auditor utilice su propio software o bien que utilice los disponibles en el emplazamiento auditado?

Por supuesto, el auditor preferirá la primera hipótesis. Ella le permitirá trabajar con la herramienta escogida por él mismo y que estará mejor adap- tada a sus necesidades. Sobre todo, le permitirá no tener que reciclarse a nivel de lenguaje cada vez que cambie de entorno.

Por el contrario, la segunda hipótesis, cuyo trabajo preparatorio previo a la misión (instalación del software, copia de algunos ficheros, etc.) no será tan importante, será a menudo la preferida por el auditado.


Como conclusión, podemos considerar que es preferible que el auditor disponga de su propio software, salvo en caso de inconvenientes técnicos o de sobrecargas humanas especiales que justificasen que el auditor utilice un lenguaje de tipo infocentro.

Por supuesto, en el caso particular de un servicio de auditoría interna en un entorno de emplazamiento único, el software elegido podrá ser instalado definitivamente en el equipo, evitando así el problema de su instalación y desinstalación sucesiva. Si fuere el caso, el servicio de auditoría podrá, ade- más, elegir por su propia cuenta el o uno de los lenguajes de infocentro puestos a disposición de los usuarios.

* * *

En el caso de la elección por parte del equipo de auditoría de un software específico, nos queda estudiar los principales criterios de esta elección. És- tos estarán relacionados con las características técnicas del software, con las modalidades prácticas de la utilización que se piensa realizar, y, claro está, con las condiciones financieras propuestas.

• ¿Lenguaje descifrado o lenguaje compilado?

En un lenguaje descifrado, las instrucciones programadas serán analizadas por el intérprete en cada ejecución del programa. Por el contrario, en un lenguaje compilado, el programa-fuente (en lenguaje de programación) se transforma por medio del compilador en lenguaje-objeto (lenguaje má- quina). La ejecución del programa se hará directamente partiendo del programa-objeto, produciendo así un ahorro de tiempo apreciable, cuando un mismo programa deba ser explotado con regularidad.

Tratándose del auditor, si sólo desea hacer el lanzamiento de las peticiones ocasionales y no repetitivas, la distinción entre los intérpretes y los compiladores no será determinante en la elección. En cambio, si las peticiones se tienen que ejecutar regularmente, y a fortiori deben comportar volúmenes de fichas importantes, es imprescindible orientarse hacia la elección de un compilador, para economizar el consumo de los recursos máquina.

• ¿Generador de programa o no?

Algunos lenguajes de programación rápida son en efecto generadores de programas, o sea, que crean las instrucciones en un lenguaje de programa- ción tradicional (COBOL, GAP, FORTRAN), y el programa creado es compilado a continuación.


La evolución futura deberá tender a la desaparición de los generadores de programa, en provecho de lenguajes compilados directamente sin pasar por una etapa intermediaria. Sin embargo, hoy día, la adquisición de un software de tipo generador de programa no debe ser rechazada a priori.

• ¿Software ejecutado en unidad central o en microordenador?

Esta cuestión no habría tenido ningún sentido hace algunos años. Las posibilidades de los microordenadores, ya sea en términos de potencia del mi- croprocesador o de capacidad de almacenamiento en el disco, eran insuficientes para permitir la ejecución de software de análisis de ficheros.

En la actualidad, es totalmente al revés. La gran mayoría de los proveedores de lenguajes de auditoría o de infocentro proponen un software que funciona en microordenador, después de introducir en él un fichero, o la totalidad o una parte de una base de datos.

Este tipo de soluciones son a la vez económicas (el consumo de medios está totalmente controlado) y fáciles. Deberían ser repetidas durante los pró- ximos años.

La alternativa principal debería residir en el desarrollo de equipos com- partidos entre diferentes usuarios, pero totalmente dedicados al infocentro y a las consultas ocasionales.

• ¿Lenguaje orientado hacia los informáticos o lenguaje orientado hacia los usuarios?

Aun cuando todos los distribuidores que velan por la promoción de lenguaje de infocentro (por lo tanto destinado a los usuarios), califican los lenguajes de lenguaje de cuarta generación (L4G), o también lenguaje de software de auditoría, y les atribuyen cualidades funcionales (lenguajes sin procedimiento) y de simplicidad (lenguajes end-user, o sea, orientados hacia el usuario final), no es menos cierto que existe una gran diversidad entre estos lenguajes. Muy grosso modo, podemos clasificarlos en dos categorías:

— Lenguajes de programación rápida, esencialmente destinados a los infor- máticos.

— Lenguajes destinados a los usuarios, particularmente adaptados para peticiones sencillas.

Los lenguajes de programación rápida ofrecen funciones casi análogas a las de los lenguajes «tradicionales», con un número reducido de instrucciones. Son, además, algunas veces utilizados como software de desarrollo de aplicación. Su principal inconveniente, relacionado con la concisión del len-


guaje, estriba en la dificultad para los usuarios de controlar bien la progra- mación de los casos más complejos. La experiencia nos enseña que la puesta a disposición de los usuarios no informáticos de tales herramientas acaba, la gran mayoría de las veces, en problemas. En cambio, los informáticos las prefieren, porque les permiten llevar a cabo desarrollos puntuales con una gran rapidez.

Por el contrario, los lenguajes orientados a los usuarios se preferirán para peticiones especialmente sencillas, pero rápidamente surgirán sus limitaciones a partir del momento en que la necesidad alcanza un cierto nivel de complejidad.

Tratándose del auditor, podremos considerar que:

— Cuando el software está destinado a auditores informáticos con experiencia como realizador de aplicaciones, es preferible recurrir a un lenguaje de programación rápida.

— Cuando el software está destinado a ser utilizado por los auditores no especializados en informática, la elección de un lenguaje orientado al usuario es imperativo.

• ¿Software destinado específicamente a los auditores o no?

Algunos software de programación rápida son bautizados, algunos sin mucha originalidad, como software de auditoría por la existencia en los mismos de algunas «rutinas» (subprogramas) destinadas muy particularmente a los auditores, tales como: muestreo, funciones estadísticas, etc.

La presencia de estas «rutinas» no siempre es una ventaja determinante, y el auditor pondrá todo su interés en comprobar, caso por caso, su utilidad... Más aún cuando estas funciones especializadas son a menudo objeto de una facturación complementaria por parte del proveedor y, lo que es más, en su gran mayoría muy raramente son utilizadas y no siempre han sido probadas como deberían.

• El coste del software

El coste del software puede revelarse muy heterogéneo de un producto al otro, y variará notablemente entre los lenguajes de interrogación en microordenadores, por ejemplo, y el software para grandes sistemas.


15.3 LAS PRINCIPALES FASES DE LA INTERVENCIÓN

El desarrollo de software de auditoría, que representa en sí una actividad relativamente simple que no requiere un gran nivel técnico, es innegablemente para el auditor de informática el campo más cargado de «trampas». Recordaremos además, que si bien el auditor, por lo general, tiene en su actividad una función de mediador, el auditor informático, en este caso en especial, tiene una función de resultado basándose en los tests que se comprome- tió a llevar a cabo.

Cualquier misión de desarrollo de software de auditoría es, por tanto, cuidadosamente preparada y planificada. Desde esta óptica, veremos a con- tinuación una presentación de las principales fases de la intervención.

a) El pliego de condiciones del software de auditoría a ser desarrollado

La definición del software a desarrollar implica a menudo varios actores:

— El servicio de informática: si la definición del test concierne esencialmente al personal de estudio (que suministrará la documentación de la aplicación y las descripciones de los ficheros), es igualmente deseable que el personal de explotación sea informado.

— Los servicios de usuarios: son ellos los que conocen mejor las prestaciones de la aplicación auditada y el contenido de los ficheros.

— El auditor informático: es el que redactará el pliego de condiciones de los tests.

Por último, es frecuente que el auditor informático sólo intervenga en apoyo técnico por cuenta de un responsable de misión.

El pliego de condiciones, que define exactamente los tests que se espera llevar a cabo, permitirá materializar la comprensión mutua de estos diferentes participantes del contenido exacto del software a desarrollar, y, si fuera el caso, de los objetivos buscados y los resultados obtenidos.

b) La salvaguarda de los ficheros necesarios para la auditoría

De un modo general, es indispensable, por razones de seguridad, que los auditores trabajen con copias de los ficheros de explotación, salvo que el software de protección de acceso permita tener absoluta garantía de que sólo se puedan hacer consultas. De hecho, he vivido el caso del auditor que destruye por descuido la cinta de seguridad que le había sido confiada para analizar. Incluso cuando, en este caso, el servicio de informática fuese por lo


menos tan responsable como el auditor, esta situación no es de ningún modo propicia a las relaciones armoniosas entre auditores y auditados. Introducido este principio, distinguiremos tres casos:

• El software de auditoría debe analizar los ficheros presentes en la empresa en el momento de la intervención

En este caso, la preparación de los ficheros se limitará a una copia el día de la llegada del auditor.

• El software de auditoría debe analizar los ficheros en su estado en una fecha anterior

Este es a menudo el caso de los trabajos realizados en el marco de una auditoría contable, la cual se lleva a cabo, la mayoría de las veces, en los ficheros de cierre mensual o de cierre de ejercicio.

La salvaguarda de los ficheros en el tiempo deseado se debe prever con mucho cuidado.

• La ejecución del software necesita la creación de un fichero de extracción intermedia

Este caso se presenta cada vez con más frecuencia tras la aparición de las bases de datos, cuyo volumen es bastante importante para que se pueda poner a disposición de los auditores una copia sobre el espacio de disco.

A menudo se debe prever la creación de un fichero reducido extraído en la fecha deseada, que será cargado sin dificultad.

c) La preparación del software de auditoría

Según las circunstancias y las herramientas de que disponga, el auditor efectuará sus tareas:

— En el equipo de explotación o en el equipo de infocentro de su «cliente» (ya sea interno o externo).

— En su propia unidad central: algunos gabinetes de auditoría disponen también de una configuración gran sistema IBM (de tipo 43 XX) en la cual procesan las cintas que contienen los ficheros de sus clientes.

— En un microordenador.

En todos los casos, el auditor debe disponer de una copia de los ficheros o de las bases de datos necesarios para su trabajo, o de una extracto de éstos.


Además, cuando trabaja en un equipo puesto a su disposición, se le debe destinar:

— Una parte del espacio de disco y los recursos de máquinas. — Un terminal. — Una clave de acceso.

Algunas veces, el software de auditoría debe, antes de nada, ser instalado en el equipo de explotación.

Si bien esta instalación es la mayoría de las veces «relativamente» rá- pida, necesita siempre una asistencia del personal del servicio de informá- tica. Esta asistencia, en el mejor de los casos inferior a una hora, llega algunas veces a varias horas en los sistemas más complejos.

Comprendemos en estas condiciones la importancia que reviste la plani- ficación de la intervención, tanto para los auditores como para los auditados.

Por último, veremos que con frecuencia es deseable, a fin de disponer de una mayor comodidad en la observación del plazo, de disociar la fase de pre- paración y de test del software de auditoría de su ejecución real.

De este modo, si se ha previsto realizar controles en los ficheros de existencias al 31 de diciembre, que sólo estarán disponibles el 15 de febrero, es posible prever que el auditor prepare y compruebe sus programas en el mes de noviembre, para no tener que volverlos a ejecutar el 15 de febrero.

d) El análisis de los resultados

Es raro que los resultados fruto del diseño y la ejecución de un software de auditoría suministren conclusiones inmediatas. La mayoría de las veces, necesitan un análisis complementario, el cual también tiene que estar planificado.

De este modo, en el caso de un software que edite las existencias negativas, la sola ocurrencia de ello no constituye una información suficientemente exacta. Convendrá también analizar total o parcialmente los casos se- ñalados para determinar la causa de esta anomalía.

Del mismo modo, en el caso de un software que recalcule para validación el valor de las existencias, será muy raro que, desde el primer cotejo, los resultados sean estrictamente idénticos a los obtenidos de la aplicación auditada. Entonces se debe prever una fase de análisis de los resultados que, muy a menudo, pondrá en colaboración al conjunto de los actores que han partici- pado en el diseño del pliego de condiciones.

Esta última fase de la misión debe ser tanto más planificada cuanto que, frecuentemente, es menospreciada o abandonada por falta de tiempo, trans- formando así en inútiles todas las tareas anteriores al llegar a su término.


15.4 LA PLANIFICACIÓN DE LA INTERVENCIÓN

En el momento de la preparación de la intervención, el conjunto de las fases precedentes descritas deben ser planificadas, y las cargas de trabajo correspondientes deben ser estimadas.

A título informativo, veremos en el cuadro que sigue un ejemplo de pla- nificación de intervención de un equipo de personal informático de un gabinete de auditores de cuentas para la realización de una «ronda» de comprobaciones en el fichero de las inmovilizaciones.

Plan de actuación de un gabinete de auditoría contable para realización de tests informatizados en el fichero de las inmovilizaciones

de uno de sus clientes

Fecha Trabajo a realizar

Carga de

trabajo Responsables

Personas del cliente

a contactar Septiembr

e 1991

Planificación de la misión

1 d x h — Director del dossier — Director del equipo de auditoría informática

Director de informática

Octubre 1991

Preparación del pliego de condiciones

2dxh — Jefe de la misión de revisión contable — Jefe de misión del equipo de auditoría informática

— Jefe del proyecto informático — Jefe de contabilidad

Diciembre 1991

Después de la aprobacióndel pliego de condiciones,texto y tests de los programas de auditoría

4dxh — Auditor informático — Jefe de proyecto informático — Responsable de la explotación

Marzo 1992

Ejecución en el fichero de las inmovilizaciones a finales de 1991 del software preparado en diciembre

1 d x h — Auditor informático — Jefe de proyecto informático — Responsable de la explotación

Marzo 1992

Análisis de los resultados 2dxh — Auditor informático Revisor contable

— Jefe de proyecto informático — Jefe de contabilidad

218

Técnicas de la auditoría informática

Capítulo 16

El auditor informático: perfil, contratación y perspectivas de evolución

16.1 PERFIL DEL AUDITOR INFQRMATICO Y NATURALEZA DE LA MISIÓN

No es necesario repetir aquí las cualidades humanas que se exige del auditor informático, que debe ser al mismo tiempo diplomático, buen comercial y buen pedagogo.

En cambio, vale la pena aclarar las cualidades técnicas que se esperan de él. Éstas presentan de hecho un doble aspecto:

— Un conocimiento de las técnicas de auditoría. — Una competencia en materia informática.

Esta dualidad explica por sí sola la diversidad de perfiles de los auditores informáticos. Algunos serán profesionales de auditoría, a los cuales se les ha dado una formación en informática, otros serán informáticos a los cuales se les habrá dado una formación en auditoría.

Más exactamente, las competencias técnicas exigidas a los auditores dependen fundamentalmente de la naturaleza de las misiones que les son confiadas.

El auditor informático 219

a) Las misiones de auditoría de la función informática Estas misiones requieren de los auditores una amplia competencia téc-

nica en el campo de la informática; métodos de desarrollo, métodos de ex- plotación, características de los principales equipos y software básicos. Esta competencia es, además, necesaria, no solamente por el hecho del nivel téc- nico de las investigaciones y de las conclusiones a ser emitidas, sino también por razones de credibilidad frente a los interlocutores.

A priori el perfil mejor adaptado a esta función es el de un diplomado superior (Ingenieros, MBA, etc.) que haya ejercido durante algunos años las funciones operativas en el seno de un servicio de informática, por ejemplo, como encargado de proyecto. Cuando se tienen en vistas intervenciones de alto nivel técnico (pruebas de penetración, auditoría de las actuaciones, audi- toría de la actividad del sistema, auditoría de las bases de datos, auditoría de la red, etc.), el reclutamiento de especialistas en estos campos debe ser previsto. Sin embargo, nos aseguraremos previamente, con mucho cuidado, de que la actividad del equipo de auditoría informática justifique una contrata- ción como ésta, teniendo en cuenta la gran especialización de estos perfiles y su nivel de remuneración.

b) Las misiones de auditoría de aplicaciones informatizadas Contrariamente a las misiones de auditoría informática, éstas no necesi-

tan grandes competencias técnicas en materia informática. En cambio, implican buenos conocimientos en los campos auditados: la auditoría de una cadena de control de producción requiere el dominio de esta actividad, la auditoría de la «cadena especial» en un establecimiento financiero requiere una competencia en materia bancaria, la auditoría de una cadena de control de las inmovilizaciones requiere conocimientos contables, etc.

Es absolutamente imposible contratar un especialista en cada tipo de actividad de la empresa. Los responsables de estas misiones deberán también al mismo tiempo:

— Ser profesionales de la auditoría, capaces de adaptar su técnica a exigencias operativas variadas.

— Pertenecer a la plantilla fija de la empresa y tener un buen conocimiento de la organización de la empresa y de sus funciones principales.

— Disponer de conocimientos básicos en materia informática.

Esta diversidad de competencias exigidas es, además, una de las causas de la dificultad para llevar a buen fin estas misiones. Se tendrán en cuenta para ocupar estas funciones:


— Los jefes de proyectos informáticos confirmados. — Los auditores con varios años en esta función que dispongan de conoci-

mientos en materia de informática.

c) La utilización del software de auditoría Se trata esta vez de una función asistencial a los equipos de auditoría

contable, financiera u operativa, para la realización de tests informatizados. Si bien el diseño de los tests y, si fuere necesaria, la implantación del

software necesitan una experiencia práctica en materia informática, la realización del software no debe en sí misma exigir competencias de primera clase, por lo menos en los casos en los cuales no se ha pensado en tests demasiado complejos. Una formación básica en informática, completada con una formación de algunos días en el software utilizado parece suficiente.

Esta capacidad técnica mínima exigida no excluye además un gran potencial. El auditor deberá estar capacitado en plazos muy cortos para adaptarse a varios entornos.

Tales trabajos deben ser confiados, por lo general, a los nuevos colaboradores, que encontrarán en ellos una formación concreta y práctica:

— En los sistemas de explotación y en los lenguajes de programación infor- mática.

— En las técnicas de auditoría.

Tendremos la mayoría de las veces para asumir esta función:

— Jóvenes licenciados en estudios superiores (ingenieros, escuelas de negocios, etc.);

— Auditores contables u operativos que, después de una formación de corta o media duración (de algunas semanas a algunos meses), evolucionarán hacia las funciones de auditor de informática.

16.2 LA CONSTITUCIÓN DEL EQUIPO DE AUDITORIA INFORMÁTICA

La constitución del equipo de auditoría informática es, por supuesto, la consecuencia de los perfiles requeridos para cada tipo de misión y de la naturaleza de las tareas confiadas a este equipo.


Un equipo de auditores informáticos cuya vocación es de integrarse en equipos «generalistas» para ayudarlos a diseñar y realizar los tests informatizados, no tendrá nada que ver con un equipo de auditores esencialmente destinados a realizar misiones difíciles y profundas en el seno de los servicios informáticos.

Más allá de estas características generales, nuestro objetivo será aquí mencionar algunas cuestiones concretas y prácticas que pueden surgir en la constitución del equipo «ideal», por lo menos en el plano teórico.

• ¿Es preferible contratar principiantes o personal experimentado?

Si bien la responsabilidad de la misión de auditoría informática sólo puede ser confiada a personal con experiencia, es posible en cambio, en la formación del equipo, atribuir algunas tareas a los principiantes. También hace falta que éstos tengan el potencial para adaptarse rápidamente a las diversas situaciones tanto en el plan técnico como en el humano.

Podemos imaginar, por ejemplo que, en el seno del equipo, el personal principiante estaría encargado, durante sus dos primeros años, de:

— La realización de los tests ayudados por software de auditoría. — La participación en misiones de auditoría de la función informática o de

auditoría de aplicación, sobre la base de un programa de trabajo detallado.

— Trabajos de asistencia en materia de ofimática.

De esta forma, irán progresivamente asumiendo la responsabilidad de todo tipo de misiones. Veremos, no obstante, que para un auditor informá- tico el hecho de no haber ejercido nunca responsabilidades operativas puede constituir un handicap, a la vez técnico, por razones que podemos imaginar fácilmente, y psicológico, ante los servicios auditados.

Además, la integración de auditores principiantes en el equipo comporta el problema de sus perspectivas de evolución. Tras algunos años estos generalmente tendrán que elegir entre:

— Ejercer las funciones operativas en el seno de un servicio informático. — Proseguir su carrera en la auditoría y la asesoría, ampliando sus campos

de competencias (auditoría contable, auditoría operativa, asesoramiento en informática, etc.)

En definitiva, y salvo en los casos donde la naturaleza de la misión lo impida, haremos todo lo posible para mezclar en el seno del equipo de auditoría a responsables de misiones «difíciles», que hayan ejercido tanto responsabi-


lidades operativas (jefe de proyecto, etc.) como responsabilidades de misión de auditoría, con los auditores juniors, principiantes o que tengan de dos a tres meses de experiencia.

• ¿Profesionales de la auditoría o profesionales de la informática?

Hemos mencionado la dualidad de las competencias exigidas al auditor informático:

— Competencia técnica en un campo que está en evolución permanente. — Conocimiento de los métodos y las técnicas de auditoría.

Surge entonces una pregunta: ¿Quién será el mejor auditor, entre el profesional de la auditoría al cual habremos dado una formación en informática y el profesional de la informática a quien habremos dado una formación en auditoría?

La respuesta es fácil de imaginar. No hay ninguna regla general y los ejemplos tanto de fracasos como de éxitos se encuentran en ambos lados. Antes de nada, es posible precisar esta respuesta, indicando las causas más frecuentes de los fracasos.

En cuanto a los profesionales de la auditoría, las más usuales son imputables a una sobrevaloración de las competencias técnicas exigidas. Con de- masiada frecuencia, los auditores contables piensan que pueden, mediante algunos días de formación, «desmitificar» la informática, y sólo ven el eso- terismo del vocabulario. ¡Error craso! De igual modo que no se puede ser un buen auditor contable sin conocer la contabilidad, no se puede ser un buen auditor informático sin conocer la informática. Y este conocimiento de la in- formática no puede ser sólo teórico y pasa imperativamente por varios años de trabajo práctico.

A la inversa, los fracasos de los profesionales de la informática están, en su gran mayoría, relacionados con su dificultad para abstraerse de su propia capacidad técnica. Ante todo porque corren el riesgo de perder de vista lo esencial (conduciendo el trabajo con «la nariz pegada al volante»), posteriormente porque, estando demasiado especializados, les cuesta algunas veces ser suficientemente didácticos, por último, y sobre todo, porque carecen de competencias en estos campos. Éstas, sin embargo, son necesarias para sus misiones tales como: organización, gestión, contabilidad, etcétera.

No obstante, hemos de concluir diciendo que no corremos ningún riesgo en afirmar que los informáticos obtienen mejores resultados en la auditoría de la función informática, mientras que los profesionales de la auditoría lo obtienen en la auditoría de aplicación. Los auditores de origen contable son


los que cosechan más éxitos en la asistencia a la auditoría contable. Nadie puede renegar totalmente de su pasado.

16.3 LA SELECCIÓN DE LOS AUDITORES INFORMÁTICOS

El mercado de la auditoría, y en particular el de la auditoría informática, es hoy día un mercado particularmente difícil.

Citemos a título ilustrativo algunos métodos de selección:

— Los anuncios en la prensa diaria nacional. — Los anuncios en la prensa de informática. — El envío de fichas de la oficina a los departamentos de alumnado de las

escuelas superiores y a las asociaciones de antiguos alumnos (escuelas de ingenieros, escuelas de negocios, etc.).

— El envío de cartas a los alumnos provenientes de la especialidad de infor- mática de algunas promociones de estas escuelas.

— La participación en los foros. — Recurrir a gabinetes especializados. — Las relaciones (en un mercado crítico, algunas empresas no vacilan en

remunerar aquellos de sus colaboradores que favorezcan las selecciones presentando candidatos).

16.4 EL CONTROL DE LOS EQUIPOS

Si bien no se trata aquí de citar todos los aspectos de la dirección de un servicio o de un equipo, vale la pena recordar algunas consideraciones propias de la actividad de la auditoría informática.

• ¿Los auditores informáticos deben estar especializados por tipo de misión?

Contrariamente a lo que podríamos pensar en el primer momento, las misiones confiadas a los auditores informáticos son bastante variadas, tanto por las competencias técnicas exigidas como por los métodos de enfoque elegidos.

224 Técnicas de la auditoría informático

Por eso, ¿los auditores deben estar capacitados, en función de sus propias competencias, para tomar parte en todo tipo de misión? La respuesta parece condicionada por dos principios básicos:

— Sería peligroso confiar a cualquier auditor novato cualquier tipo de misiones, salvo cuando su experiencia previa le haya preparado para la misma.

— No es deseable especializar el auditor en un tipo específico de actividad, durante toda la duración de su paso por el equipo.

Verdaderamente, la mejor solución consiste en proponer a cada auditor, en el momento de su llegada, una evolución que le permita progresar a medida que vaya adquiriendo competencias y fortaleciendo su experiencia.

Esta progresión se podrá materializar:

— Por medio de una evolución técnica: el auditor será asignado a misiones que requieran una capacidad técnica cada vez más importante.

— Por medio de una evolución jerárquica: el auditor será nombrado responsable de misiones «simples», después progresivamente, de misiones cada vez más complejas.

— Por medio de una evolución en la naturaleza del objetivo pretendido: en particular, cuando al servicio de auditoría se le confían misiones de asistencia y asesoría, que exigen a la vez un alto nivel técnico y aptitudes co- municativas evidentes, éstas se reservan primordialmente a los auditores con experiencia.

• ¿Algunos auditores deben estar especializados en la utilización del o de los programas (software) de auditoría?

Una primera constatación se impone: un auditor generalista al cual se le pide que utilice, en el marco de sus misiones, el software de auditoría, sólo será eficaz cuando pase por lo menos del 25 al 30 % de su tiempo en esta actividad. Por debajo de este umbral, teniendo en cuenta que no es un especialista de la informática, su insuficiente dominio de la herramienta será a la vez fuente de pérdida de tiempo y de una baja fiabilidad de los desarrollos.

Este inconveniente ha llevado a la gran mayoría de las grandes empresas o de los gabinetes de auditoría a formar equipos especializados en la utiliza- ción del software. Por razones de eficacia, es deseable que cada miembro del equipo pase por lo menos el 50 % de su tiempo en esta actividad. Se pretende que el paso por este equipo sea de corta duración, por ejemplo de uno a dos años.


• La remuneración

Sería desastroso dar las estadísticas sobre las remuneraciones de los auditores de informática, teniendo en cuenta la diversidad de los perfiles en- contrados. Veremos, de todos modos, que este mercado es muy crítico teniendo en cuenta la doble penuria sobre el mercado de auditores y sobre el mercado de informáticos. Veremos igualmente que, en estos dos campos, las remuneraciones de los principiantes evolucionan muy rápidamente durante los primeros años de experiencia. No obstante, es indispensable, en el momento de la selección de un nuevo colaborador, prever un margen de progre- sión significativo en caso de éxito en este puesto.

La responsabilidad del equipo de auditoría informática deberá tener en mente a la vez, las gamas de remuneración de los auditores y las de los infor- máticos.

16.5 PERSPECTIVAS DE EVOLUCIÓN DE LOS AUDITORES INFORMÁTICOS

Enfocaremos sucesivamente la evolución del auditor informático hacia tres tipos de funciones:

— La función de especialista en auditoría informática. — Las funciones de auditor. — Las funciones operativas.

La figura 9 ilustra estas perspectivas de evolución para algunos tipos de carreras que tengan como denominador común el paso por las funciones de auditoría.

a) El especialista de la auditoría informática

La auditoría informática ha conocido a lo largo de los diez últimos años un desarrollo considerable. Aun cuando la progresión debería, antes de nada, tender a estabilizarse, actualmente es posible enfocar una carrera en la audi- toría informática. Esta carrera desembocará en funciones tales como responsable de «risk management», responsable de la auditoría informática en el seno del servicio de auditoría (o de inspección en un establecimiento financiero), responsable de la seguridad en el seno de una Dirección informática, etcétera.


Figura 9. Ejemplo de carrera pasando por las funciones de auditor.


El auditor informático que pretende una carrera de este tipo debe, por tanto, tener en mente un doble riesgo:

— Las carreras en informática, las cuales permiten ascensos muy rápidos durante los primeros años, son a menudo delicadas a partir de la edad de 40 años, teniendo en cuenta el prejuicio que se relaciona, por lo general, con esta actividad de alto nivel técnico.

— El hecho de no haber llevado a cabo nunca una actividad operativa puede constituir un factor de incremento del riesgo anterior.

b) La carrera de auditor

Las funciones de auditoría, tanto internas como externas, ofrecen actualmente buenas perspectivas, y hacen falta muchos años en esta función para poder ser considerado como un especialista.

Ahora bien, para el auditor, el paso durante algunos años por las funciones de auditoría informática constituye un «plus» innegable, y será considerada en el futuro como una condición sine qua non.

Podemos entonces enfocar:

— Un inicio de carrera en la auditoría informática antes de evolucionar hacia funciones de auditor contable u operativo. .

— O, por el contrario, un paso por la auditoría informática después de algunos años de auditoría contable u operativa.

Estas opciones deben, por lo tanto, ser elaboradas suficientemente para evitar los riesgos de fracaso.

c) Las funciones operacionales

La función del auditor informático constituye un puesto de observación y de reflexión privilegiado en una carrera que tiene que aspirar a responsabilidades operativas importantes. En efecto, permite conocer el conjunto de las actividades de un servicio de informática. A título de ejemplo, un antiguo jefe de proyecto, ejerciendo las funciones de auditor informático, estará a continuación en posición de postular por un puesto de responsable de estudios o de jefe de servicio. El ingeniero que haya iniciado su carrera en la auditoría informática podrá aspirar a un puesto de jefe de proyecto.

Por tanto, veremos que, bajo esta óptica, es deseable no sobrepasar un período de tres a cinco años en esta función.

* * *


Bibliografía

Libros

IFACI, Les principes de la sécurité informatique: Guide d'audit, Clet-Dunod, 1990. JAN (C), SABATIER (G.), La sécutité informatique, Eyrolles, 1989. LAMERÉ (J.-M.), La sécurité informatique, approche méthodologique, Dunod, 1985. LAMERÉ (J.-M.), LEROUX (Y.), TOURLY (J.), La sécurité des réseaux: méthodes et

techniques, Dunod, 1989. LAMERÉ (J.-M.), TOURLY (J.), La sécurité des petits et moyens systémes informati-

ques, Dunod, 1988. LEFEBVRE (Francis) Memento comptable. "Progiciels de comptabilité, critéres de conception et de choix", Estudio de la Com-

pagnie nationale des Commissaires aux Comptes et de l'Ordre des Experts comptables et des comptables agréés, Mayo 1990.

PLANS (J.), Lapratique de l'audit informatique, Eyrolles. PLANS (J.), La qualité informatique: comment maitriser les systémes d'information

dans les entreprises, Dunod, 1988. RAFFEGEAU (J.), RITZ (A.),Audit et informatique, coll. "Que sais-je?", PUF, 1986. THORIN (M.), L'audit informatique, méthodes, regles et normes, Masson, 1991.

Revistas

Le Monde informatique 01 HEBDO Revista de l'AFAI (Association fran?aise des auditeurs informatiques) Revista de l'IFACI (Instituí francais des auditeurs consultants internes) Encuestas de l'APSAIRD (Assemblée pléniére des sociétés d'assurance contre

l'incendie et les risques divers) sobre la seguridad informática Encuestas y estudios del CLUSIF (Club de la Sécutité informatique francaise).

Bibliografía 229

técnicas de la auditoría informática.pdf

Documents