Vous êtes sur la page 1sur 241

Tcnicas de la

auditora
informtica

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 presentacin digna de su
contenido y est poniendo todo su empeo y recursos para que
sea ampliamente difundida, a travs de su red de comercializacin.
Usted puede obtener fotocopias de las pginas del libro para
su uso personal. Pero desconfe y rehse cualquier ejemplar
"pirata" o fotocopia ilegal del mismo porque, de lo contrario,
contribuira al lucro de quienes, consciente o inconscientemente, se aprovechan ilegtimamente del esfuerzo del autor y del
editor.
La reprografa indiscriminada y la piratera editorial, no
solamente son prcticas ilegales, sino que atenan contra la
creatividad y contra la difusin de la cultura.
PROMUEVA LA CREATIVIDAD
RESPETE EL DERECHO DE A UTOR

ESTRATEGIA Y GESTIN
COMPETITIVA

Tcnicas de la

auditora
informtica
Yann Derrien

marcombo

BOIXAREU EDITORES

Ttulo de la obra original


Les techniques de l'Audit informatique
Copyright by Dunod, Pars
Traduccin de
Jos Ribamar Rodrigues Silva
Coordinacin de la coleccin
Juan Luis Segurado Llorente

Reservados todos los derechos de publicacin,


reproduccin, prstamo, alquiler o cualquier
otra forma de cesin del uso de este ejemplar
de la presente edicin en espaol por
MARCOMBO, S.A. 1994
Gran Via de les Corts Catalanes, 594
08007 Barcelona (Espaa)

Quedan rigurosamente prohibidas, sin la autorizacin escrita de los titulares del Copyright, bajo las sanciones
establecidas en las leyes, la reproduccin total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la reprografa y el tratamiento informtico, y la distribucin de ejemplares de ella mediante alquiler o
prstamo pblicos, as como la exportacin e importacin de esos ejemplares para su distribucin en venta, fuera
del mbito de la Unin Europea.
ISBN: 978-84-267-0960-8
ISBN: 2-10-001154-5, Dunod, Pars, edicin original
Depsito Legal: B-12.670-94
Impreso en Espaa
Printed in Spain
Composicin, compaginacin y fotolitos: ApG - Entenza, 218 - 08029 Barcelona
Impresin: Gersa, Industria Grfica, Tambor del Bruc, 6,08970 Sant Joan Despf

ndice general

Advertencia .................................................................................................

PRIMERA PARTE. OBJETIVOS Y MTODOS DE LA AUDITORA


INFORMTICA
Captulo 1. Los objetivos de la auditora informtica ..............................
1.1 El estudio de fiabilidad del entorno informtico...............................
1.2 El estudio de la eficacia y de las actuaciones de la
actividad informtica ........................................................................
1.3 Estudio de fiabilidad de una aplicacin informatizada .....................
1.3.1 Los objetivos de la auditora......................................................
1.3.2 Los demandantes de una auditora de aplicacin
informatizada ............................................................................
1.3.3 Las dificultades de la auditora de una aplicacin
informatizada ............................................................................
1.3.4 Los mtodos de auditora de una aplicacin informatizada.......
1.3.5.Los principales grupos de aplicaciones ...................................
1.4 Utilizacin del instrumento informtico en el marco de
una misin de auditora .....................................................................

5
7
11
12
12
15
16
17
25
25

SEGUNDA PARTE. AUDITORA DE LA ACTIVIDAD INFORMTICA


Captulo 2. La organizacin general del servicio informtico.................
2.1 La estructura del servicio informtico ..............................................
2.2 La planificacin de la actividad informtica......................................
2.3 El seguimiento de costes ....................................................................
2.4 Las prcticas contables y financieras .................................................
2.5 Las relaciones con los servicios de usuarios ......................................
2.6 La separacin de funciones ................................................................
2.7 El control de la actividad ...................................................................
2.8 El entorno social ................................................................................
2.9 Las relaciones con los proveedores....................................................

29
29
35
36
38
39
40
41
42
45

Captulo 3. Los procedimientos de desarrollo y de mantenimiento


del software ...............................................................................
3.1 La metodologa de desarrollo de las aplicaciones .............................

50
50

ndice general

3.2 La calidad del software.......................................................................


3.3 La documentacin...............................................................................
3.4 El mantenimiento................................................................................
3.5 Los procedimientos de puesta en explotacin del software................

59
61
62
62

Captulo 4. El entorno de produccin ........................................................


4.1 Los procedimientos de puesta en explotacin ..................................
4.2 Los procedimientos de toma de datos................................................
4.3 La ejecucin de los procesos en tiempo diferido................................
4.4 El control de supervisin del entorno de produccin .........................
4.5 El control de la calidad de la produccin informtica ........................
4.6 La gestin del espacio en disco ..........................................................
4.7 La gestin de las bibliotecas de programas .......................................
4.8 La gestin de las copias de seguridad.................................................
4.9 Los procedimientos de recuperacin en emplazamientos externos
(back-up).............................................................................................
4.10 La seguridad fsica............................................................................
4.11 Los seguros .......................................................................................
4.12 Las obligaciones legales de declaracin ...........................................

63
63
66
68
71
71
73
73
74

Captulo 5. Las funciones de asistencia tcnica .........................................


5.1 Las bases de datos ..............................................................................
5.2 La gestin de redes .............................................................................
5.3 La microinformtica ...........................................................................
5.4 Los mtodos........................................................................................
5.5 El infocentro .......................................................................................
5.6 La funcin sistema.............................................................................
5.7 La funcin seguridad ..........................................................................

90
90
92
95
101
102
103
104

Captulo 6. La proteccin y la confidencialidad de los datos ...................


6.1 El acceso no autorizado a los datos que se encuentran en
el emplazamiento central....................................................................
6.1.1 Medidas de prevencin por la identificacin del
individuo recurrente...................................................................
6.1.1.1 El modo de identificacin del individuo recurrente .......
6.1.1.2 Las tcnicas de software de proteccin..........................
6.1.2 Las medidas de prevencin de acceso por identificacin
del terminal recurrente ..............................................................
6.1.3 Las medidas de prevencin de acceso a las formas de
datos y su soporte de almacenamiento.......................................
6.2 El robo o la copia de ficheros o software que se encuentran
en un soporte de papel o magntico ...................................................
6.3 La conexin fsica con las lneas en las cuales circulan los datos ......

106

VI

80
81
83
84

106
107
107
109
115
116
117
119

Tcnicas de la auditora informtica

TERCERA PARTE. EL CONTROL DE LAS APLICACIONES


INFORMATIZADAS
Captulo 7. La contabilidad general, analtica y auxiliar........................
7.1 Presentacin general de la aplicacin ...............................................
7.1.1 Los principales ficheros ...........................................................
7.1.2 Los procesos.............................................................................
7.2 La auditora de la aplicacin .............................................................
7.2.1 La auditora de las posibilidades funcionales...........................
7.2.2 La auditora de la utilizacin de la aplicacin ..........................

124
124
124
126
130
130
137

Captulo 8. El ciclo de las ventas ...............................................................


8.1 Presentacin general de la aplicacin ...............................................
8.1.1 Los principales ficheros............................................................
8.1.2 Los procesos .............................................................................
8.2 La auditora de la aplicacin .............................................................
8.2.1 La adecuacin de las prestaciones a las necesidades
de los usuarios ...........................................................................
8.2.2 La separacin de funciones ......................................................
8.2.3 Los medios del control jerrquico ............................................
8.2.4 El seguimiento del riesgo-cliente .............................................
8.2.5 El seguimiento de la cifra de negocios y de los mrgenes ........
8.2.6 El registro de los pagos de clientes ...........................................
8.2.7 La exhaustividad de las facturas y abonos emitidos .................
8.2.8 La separacin de los ejercicios contables..................................
8.3 La utilizacin de los programas de auditora .....................................

139
139
139
141
141
141
142
142
143
143
144
144
145
146

Captulo 9. El ciclo de las compras ............................................................


9.1 Presentacin general de la aplicacin ................................................
9.1.1 Los ficheros principales ............................................................
9.1.2 Los procesos..............................................................................
9.2 La auditora de la aplicacin ..............................................................
9.2.1 La adecuacin de las prestaciones a las necesidades
de los usuarios ...........................................................................
9.2.2 La separacin de funciones .......................................................
9.2.3 Los controles jerrquicos ..........................................................
9.2.4 La separacin de los ejercicios contables..................................
9.2.5 El registro y el pago de las facturas de proveedores .................

149
149
149
151
153
153
153
153
154
154

Captulo 10. La gestin de existencias .......................................................


10.1 Presentacin general de la aplicacin ..............................................
10.1.1 Los principales ficheros.........................................................
10.1.2 Los procesos ..........................................................................
10.2 La auditora de la reaplicacin .........................................................
10.2.1 La valoracin de las existencias ............................................
10.2.2 El inventario fsico ................................................................
10.2.3 La introduccin de las regularizaciones de existencias ........

156
156
156
157
158
158
160
161

ndice general

VII

10.2.4 La gestin de reaprovisionamientos ......................................


10.2.5 Las ediciones peridicas ........................................................
10.3 La utilizacin de los programas de auditora ...................................

162
162
163

Captulo 11. La nmina y la gestin del personal .....................................


11.1 Presentacin de la aplicacin............................................................
11.1.1 Los ficheros principales .........................................................
11.1.2 Los principales procesos ........................................................
11.2 La auditora de la aplicacin.............................................................
11.3 La utilizacin del software de auditora............................................

165
165
165
166
169
173

Captulo 12. La gestin de las inmovilizaciones ........................................


12.1 Descripcin de la aplicacin.............................................................
12.1.1 Los ficheros principales .........................................................
12.1.2 Los procesos principales ........................................................
12.1.3 Los listados principales..........................................................
12.2 La auditora de la aplicacin.............................................................
12.3 La utilizacin del software de auditora ...........................................

175
175
175
176
176
177
179

CUARTA PARTE. LA GESTIN DE LA AUDITORA INFORMTICA


Captulo 13. Presentacin general de la gestin ........................................
13.1 Los participantes...............................................................................
13.1.1 El auditor de cuentas ..............................................................
13.1.2 El auditor externo contratado.................................................
13.1.3 El auditor interno ..................................................................
13.1.4 El controlador fiscal ...............................................................
13.2 El plan plurianual de auditora informtica ......................................
13.3 El programa anual de trabajo............................................................
13.4 Las herramientas del auditor informtico .........................................
13.4.1 Los mtodos de anlisis de riesgos informticos ...................
13.4.2 El software de auditora .........................................................

183
183
183
186
187
187
187
189
190
191
192

Captulo 14. La direccin de la misin de auditora .................................


14.1 La preparacin de la misin..............................................................
14.1.1 La propuesta de intervencin .................................................
14.1.2 El programa de trabajo...........................................................
14.2 Los mtodos de investigacin...........................................................
14.2.1 La gestin general de la evaluacin del control interno.........
14.2.2 La evaluacin del control interno de la funcin informtica ....
14.2.3 La auditora de la aplicacin ..................................................
14.3 La valoracin del volumen de intervencin......................................
14.4 La presentacin de las conclusiones ................................................
14.5 El seguimiento de las recomendaciones ...........................................

195
195
196
199
199
199
200
202
204
206
207

VIII

Tcnicas de la auditora informtica

Captulo 15. La utilizacin de los programas informticos de auditora....


15.1 Los objetivos del desarrollo de un software de auditora ....................
15.1.1 Desarrollo de un software de auditora en el marco de
una misin de auditora de una aplicacin informatizada .........
15.1.2 La asistencia a la revisin contable..........................................
15.2 La eleccin de un software de auditora .............................................
15.3 Las principales fases de la intervencin .............................................
15.4 La planificacin de la intervencin ....................................................

209
210
211
215
218

Captulo 16. El auditor informtico: perfil, contratacin y perspectivas


de evolucin .............................................................................
16.1 Perfil del auditor informtico y naturaleza de la misin......................
16.2 La constitucin del equipo de auditora informtica ...........................
16.3 La seleccin de los auditores informticos.........................................
16.4 El control de los equipos ...................................................................
16.5 Perspectivas de evolucin de los auditores informticos.....................

219
219
221
224
224
226

Bibliografa...................................................................................................

229

ndice general

208
208

IX

Advertencia

La auditora informtica no se parece en nada a la cocina. Esta obra no


tiene por vocacin ser un libro de recetas. Muy a menudo, tenemos la tendencia a juzgar la calidad de los programas de evaluacin de un entorno informtico por el nmero de preguntas que lo componen. Quin no habr
odo decir alguna vez: El software Y, que acaba de salir, est compuesto por
ms de 800 preguntas! Luego, el software X es obsoleto?
Uno de los efectos dainos ms desastrosos de esta actitud reside en estos
escuadrones de auditores jnior desembarcados ante los responsables informticos veteranos teniendo como nico equipaje los cuestionarios, algunas veces de calidad mediocre, y, de todos modos, dominando slo superficialmente el significado de sus preguntas.
He escuchado muy a menudo a los auditores hacer la misma pregunta
bajo dos formas diferentes, sin tan slo darse cuenta. El resultado es siempre
catastrfico. O se dan cuenta inmediatamente los responsables informticos
de la falta de formacin de sus interlocutores, o bien sospechan que utilizan
procedimientos maquiavlicos destinados a llevarlos a contradecirse. En
ambos casos, la imagen de la misin es deplorable. Y lo que es ms, como el
auditor no domina del todo ni el significado de las preguntas propuestas ni el
de las respuestas dadas, la relacin es muy a menudo imprecisa y algunas veces equivocada.
En otras palabras, aun siendo el cuestionario de auditora un soporte metodolgico del todo eficaz, no podr jams paliar una experiencia insuficiente.
Por qu esta advertencia? Para explicar que ms que ahorrar al lector un
aluvin de preguntas, mi objetivo, al final de los captulos, ha sido justificar
el inters de la auditora informtica, pero tambin hacer tomar conciencia
de sus lmites. No hay peor publicidad para la profesin que una incursin en
objetivos poco precisos, donde el mandatario, nefito en la materia, se encontrar en definitiva decepcionado por los resultados obtenidos.
Por supuesto, una buena comprensin del proceso necesita que ste sea
ilustrado por varios modelos, por ejemplo, por medio de cuestionarios. Pero,
Advertencia

tratndose de una iniciacin, mi inters radica en la presentacin y la explicacin de los objetivos bsicos (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 inters primordial ser hacer entender bien al
lector que la auditora informtica no es un fin en s mismo, sino que se trata
ms bien de un conjunto de tcnicas muy diversas que permiten dar respuesta a objetivos tambin muy variados.

Tcnicas de la auditora informtica

Primera parte

OBJETIVOS
Y MTODOS
DE LA AUDITORA
INFORMTICA

Qu es la auditora informtica? Si bien el concepto de la auditora informtica est hoy da ampliamente difundido, este trmino genrico en realidad abarca objetivos y mtodos de trabajo muy variados.
Para el Director general poco versado en la materia, se trata a menudo de
una forma de ver un poco ms clara la actividad de uno de los servicios
clave de su empresa. Para el Director informtico, la auditora informtica
aporta, adems de un asesoramiento sobre la organizacin, dado por especialistas externos, el medio de seguir y justificar la aplicacin de nuevas estructuras o de nuevos mtodos. El Director financiero, en lo que le concierne,
ver ms 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 utilizacin del instrumento informtico para establecer y fundamentar su opinin.
Estos pocos ejemplos ilustran muy bien que, bajo un mismo trmino, se
escondan objetivos totalmente diferentes. Por lo mismo, los mtodos de trabajo y los instrumentos utilizados tambin sern diferentes. Esta heterogeneidad se dar incluso dentro del perfil de los auditores informticos. Aunque algunos encargos sern llevados a cabo por auditores habituales o
Objetivos y mtodos de la auditora informtica

comunes que hayan tenido una formacin complementaria de corta duracin, por ejemplo en la utilizacin de software especializado, otros necesitarn imperativamente la presencia de hiperespecialistas. Pero, es necesario no equivocarse!
Esta primera parte de la obra, tiene como finalidad establecer una tipologa de los objetivos de la auditora informtica y de los medios a utilizar para
obtener estos objetivos.

Tcnicas la auditora informtica

Captulo 1

Los objetivos de la
auditora informtica

Si exceptuamos el caso en el cual el trmino de auditora informtica designa, adems de una manera impropia, la utilizacin del instrumento informtico en el marco de una misin ms amplia (auditora contable, auditora
financiera, auditora operacional), el objetivo principal de una auditora informtica es siempre el mismo: comprobar la fiabilidad de la herramienta
informtica y la utilizacin que se hace de la misma.
Desgraciadamente, este objetivo fundamental es difcil de alcanzar. La
complejidad de un entorno informtico 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 ms competente que sea e incluso al final de un
estudio de larga duracin.
De este modo, un software de facturacin en una empresa industrial
puede ser, aparentemente, de una fiabilidad total, gracias a una redaccin
clara y funcional de los programas, una documentacin precisa y detallada,
unos procedimientos de utilizacin 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 ms elevados, y poner de esta manera la empresa en una situacin de ventas con prdida verdaderamente involuntaria.
Ahora bien, el auditor, a travs del anlisis y de la relectura de los programas
(software), tendr poqusimas oportunidades de descubrir esta anomala.
A la inversa, un software puede estar mal documentado, ser poco accesible, ser utilizado en condiciones deplorables y revelarse en el uso perfectamente fiable!
Los objetivos de la auditora informtica

Adems, la paradoja slo es aparente. La informtica, a pesar de las evoluciones de los dos ltimos decenios, contina siendo un mbito de fuerte
tecnicidad y cuyos especialistas son bastante celosos de sus prerrogativas y
los programadores ms competentes y los ms activos no estn siempre muy
motivados a documentar los programas de los cuales son autores.
Adems, el imperativo dado por la Direccin General de una utilizacin
rpida puede contribuir a la insuficiencia de la documentacin en aplicaciones que, sin embargo, son fiables. Ms 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 direccin.
Y lo que es ms, es sabido que, al igual que el hombre, ningn 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 ms sofisticados.
De este modo, se sabe que en los sectores de actividades tan estratgicas como la espacial, la militar o la aeronutica, el nmero de bugs1 en los
programas est lejos de ser cero, aunque stos sean desarrollados por
los tcnicos ms capacitados, disponiendo adems de presupuestos considerables.
Cmo podra, en estas condiciones, nuestro pobre auditor informtico,
en un perodo de tiempo limitado, elaborar la clasificacin entre los errores
que pueden atentar contra la integridad de las aplicaciones y los errores menores?
Tanto ms cuanto el auditor, aun siendo un especialista de informtica, 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 auditora,
intervendr en los sectores de actividades diversas, y pasar de empresas industriales a empresas comerciales hasta incluso a bancos o compaas 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 sera debido a la diversidad de actividades de las filiales
de la mayora de los grupos nacionales o multinacionales.
Las conclusiones de estas cuestiones preliminares pueden parecer
bastante sombras. Tiene la auditora informtica alguna utilidad desde
el momento en que ninguna tarea, aunque sea difcil y costosa, no puede
dar certeza alguna en cuanto a la fiabilidad del software? Puede llegarse
a la conclusin que las aplicaciones ms fiables son las menos documentadas?
1. Errores de programa.
6

Tcnicas de la auditora informtica

En realidad, y a pesar de todas las reservas precedentes, la auditora informtica tiene, sin ninguna duda, su razn de ser. En primer lugar porque, incluso si no puede dar ninguna exactitud, puede suministrar opiniones serias
sobre la Habilidad de un entorno. Una aplicacin, aunque sea mal documentada, puede ser fiable si el programador que la ha desarrollado es competente
y si l asegura el mantenimiento. No obstante, esta insuficiencia de documentacin tendr en todos los casos una consecuencia casi segura que es que
el mantenimiento de la aplicacin se har extremadamente delicado desde el
momento en que el mismo no estar ya asegurado por su autor. Peor todava,
adems ste habr estado genial y adems el mantenimiento ser difcil,
pues habr utilizado tcnicas de programacin lo ms sofisticadas, de difcil
dominio por parte de sus sucesores.
Por otro lado, una cosa esencial que puede hacer la auditora informtica
es comprobar que el servicio informtico aplique la poltica que le ha sido
dictada por la Direccin General. Es del todo admisible que una empresa no
disponga permanentemente de un emplazamiento de emergencia para sus
aplicaciones, a condicin de que se trate de una decisin de la Direccin motivada por la comparacin 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 auditora informtica es til, pero no constituye una ciencia exacta.
Debe apoyarse en un conjunto de suposiciones. Esta es la razn por la cual
los objetivos precisos asignados a una misin de auditora y las tcnicas utilizadas son tan variables. Son estos objetivos los que especificaremos a continuacin en este captulo.

1.1 EL ESTUDIO DE FIABILIDAD DEL


ENTORNO INFORMTICO
a) El inters de un buen control interno
Antes de nada, especifiquemos la nocin 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 proteccin y salvaguarda del
patrimonio y la calidad de la informacin, y por otro, la aplicacin de las, instrucciones de la direccin y favorecer la mejora de las actuaciones. Se manifiesta por medio de la organizacin, los mtodos y procedimientos de algunas de las actividades de la empresa para mantener la perennidad de la
misma.
Los objetivos de la auditora informtica

A la vista de esta definicin se comprende fcilmente el inters de un


buen control interno de la funcin informtica. Una buena organizacin de
conjunto de esta actividad, la existencia de procedimientos y mtodos satisfactorios constituyen, de hecho, un primer supuesto de fiabilidad y de perennidad del software desarrollado.
A ttulo de ejemplo, en ausencia de la definicin de una poltica 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 programacin deja a
cada programador la libertad de eleccin de su mtodo, lo que origina una
mayor dificultad de mantenimiento de las aplicaciones y, por consiguiente,
una degradacin progresiva de la fiabilidad de las mismas.
Por el contrario, la existencia de procedimientos de control y de autorizacin de acceso a las aplicaciones limita innegablemente, incluso sin suprimirlos, los riesgos de manipulaciones fraudulentas por parte de los usuarios.
De la misma manera, una gestin seria de las bibliotecas de programas en
uso, la implantacin de software dedicado a la seguridad y a la confidencialidad de los datos, o aun la realizacin sistemtica de un control de explotacin a posteriori, estn encaminados a reducir los riesgos de operaciones
equivocadas o fraudulentas de parte de los informticos.
Los retos de la puesta en marcha de un buen control interno en el seno de
un servicio de informtica deben, adems, estar claramente explicitados. Los
procedimientos demasiado formalistas son, a menudo, interpretados por los
informticos como un signo de desconfianza, incluso como una sospecha
con relacin a ellos. Son susceptibles de daar la motivacin de los grupos
de trabajo, con lo que se consigue el efecto contrario al deseado.
En realidad, estos procedimientos apuntan mucho ms a reducir los riesgos de errores lamentables, en otras palabras, proteger a los informticos
ante ellos mismos, que revelar operaciones malvolas. 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 informtica.

b) Los demandantes de una auditora de la actividad informtica


Los demandantes potenciales de una auditora de la actividad informtica
son mltiples.
En primer lugar, la Direccin de la empresa ha entendido bien las razones evidentes que le llevan a cuestionarse sobre la calidad de un instrumento que hoy da es la piedra angular de muchas empresas. Esta inquietud es tanto ms comprensible en cuanto que, si existen los medios
8

Tcnicas de la auditora informtica

cuantitativos y cualitativos eficaces para evaluar la mayora de los dems


sectores de la actividad (produccin, comercial, compras, etc.), el director
de empresa est a menudo en inferioridad de condiciones ante una actividad tcnica en la cual, generalmente, no ha sido formado. Por lo tanto, es
del todo legtimo que haga uso de las competencias necesarias para comprobar el seguimiento de las directrices que, en principio, fueron definidas
por l mismo.
El responsable informtico igualmente puede recurrir a la auditora de su
servicio. De esta forma, podr obtener la opinin motivada de especialistas,
al contacto con varios emplazamientos, sobre su propia organizacin. En un
contexto de reorganizacin, la auditora ser tambin 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, administracin fiscal, comisin bancaria en los establecimientos financieros, Tribunal de Cuentas, etc.) tienen igualmente la vocacin de interesarse por la calidad del entorno informtico, ya que ella es la condicin
primordial de la fiabilidad de los programas, y de los datos cifrados que estn obligados a utilizar o a controlar.
De este modo, la funcin informtica, al igual que las dems funciones de
la empresa, debe ser auditada regularmente. Adems, se puede constatar
que, si hace una dcada los auditores eran, a menudo, vistos en los servicios
informticos con sorpresa y a veces con recelo, el primer sentimiento ha desaparecido y hoy en da la auditora informtica es aceptada al mismo nivel
(o casi) que la auditora financiera.
Tambin ah conviene estar vigilante y aclarar bien las razones de la auditora. Encargada por la Direccin general en un contexto de relacin tensa
con la Direccin informtica, el auditor ser considerado (a veces con razn)
como un cortacabezas. Encargada por la Direccin de informtica hacindose cargo de sus funciones, no es la auditora el pretexto para una crtica 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 auditora informtica pierde una
buena parte de su inters tcnico y se transforma tan solo en el medio de ratificar las decisiones ya tomadas hace mucho tiempo.

c) Los componentes de una auditora de la actividad informtica


Por lo general, en la auditora de un entorno informtico se distinguen
cuatro componentes:
Los objetivos de la auditora informtica

El examen de la organizacin general del servicio.


El examen de los procedimientos relativos al desarrollo y al mantenimiento de las aplicaciones.
El examen de los procedimientos relativos a la utilizacin de las cadenas
de tratamiento.
El examen de las funciones tcnicas.
Incluiremos igualmente los controles tcnicos especficos relativos a la
proteccin y a la confidencialidad de los datos.
Volveremos ms detalladamente sobre estos diferentes aspectos en la segunda parte de la obra.

d) Los mtodos de auditora de la actividad informtica


En el marco del control de la fiabilidad del entorno informtico, el auditor pondr su atencin en un conjunto de puntos clave, que constituyen un
buen o un mal control interno.
Por lo general, formar su opinin tanto a travs de entrevistas con el personal del servicio informtico como con un determinado nmero de usuarios. Proceder igualmente al control de documentos y listados para ratificar
las respuestas obtenidas o bien para completar su informacin sobre ciertos
mbitos.
Para ayudarle en su tarea, el auditor cuenta hoy da con diferentes instrumentos, comercializados en el mercado por los bufetes de auditora o empresas de servicios, cuyas prestaciones estn, en realidad, muy cercanas las unas
a las otras.
Estos instrumentos tienen todos como base un cuestionario de auditora,
ms o menos detallado segn el caso. Por lo general, un software va acompaado del mtodo y las respuestas son entonces introducidas en un microordenador y las conclusiones de la auditora son presentadas posteriormente
bajo formas asequibles y didcticas (rosetn de auditora, o sea, notacin
que pone en evidencia los puntos fuertes y dbiles, etc.).
Sin querer adelantar la presentacin de estos mtodos, lo que encontraremos en la cuarta parte de la obra (captulo 13), nos limitamos aqu a sugerir
algunos temas para reflexin:
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?
Ms generalmente, se puede confiar en ciertos mtodos basados en una
autoevaluacin por parte de los informticos y de los usuarios de sus propias fuerzas y debilidades?
10

Tcnicas de la auditora informtica

No siendo la seguridad informtica 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 INFORMTICA
La seguridad de un centro informtico es una cosa y su eficacia y actuacin 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 presupuestarios son a veces necesarios.
As, en materia de back-up2, una solucin 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 solucin casi nunca se adopta debido
a su coste. Se prefieren generalmente medidas menos onerosas tales como:
un contrato de puesta a disposicin en caso de necesidad de un emplazamiento de back-up a travs de un suministrador externo, una sala vaca lista
para recibir el equipamiento en caso de necesidad, duplicacin de las mquinas de explotacin con el funcionamiento estropeado de una de ellas, si se
diera el caso, etc.
Generalmente, la auditora de la eficacia se interesa ms bien por aquellos aspectos no cubiertos por la auditora de seguridad. En especial, se estudiarn a fondo las prestaciones y la dimensin de los equipos fsicos. De hecho, aun cuando un exceso de capacidad de las unidades centrales o de los
discos con relacin a las necesidades no estorban al buen control interno del
centro, no deja de ser un factor de coste adicional intil.
La adecuacin a las necesidades del software de sistema constituye igualmente un tema interesante. Ciertas PYME no cuentan con grandes sistemas
informticos con un software sofisticado, pero necesitan la presencia de tcnicos 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 auditora de eficacia en la materia comprobar que
no se hayan implantado configuraciones desproporcionadas slo por amor al
arte.
2. Procedimientos de reinicio de explotacin.

Los objetivos de la auditora informtica

11

Para tales misiones se reciben rdenes ya sea de la Direccin general, interesndose sobre el coste de su informtica, o bien del responsable de informtica deseoso de comprobar la pertinencia de su configuracin. Se entiende fcilmente que estos encargos exigen por parte de los auditores unas
competencias tcnicas 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 APLICACIN


INFORMATIZADA
1.3.1 Los objetivos de la auditora
La finalidad primordial, claro est, es pronunciarse sobre la calidad de
una aplicacin dada, por ejemplo: gestin de existencias, gestin de produccin, contabilidad general, auxiliar y analtica, compras, gestin comercial,
etctera.
En realidad detrs de este objetivo bsico se pueden ocultar motivaciones
bastante diferentes, en funcin de las cuales convendra elegir las tcnicas de
auditora ms apropiadas.
Control de la/labilidad del software o control del uso que se da al
mismo
Muy burdamente, podramos considerar que en el primer caso es la prestacin del servicio informtico 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 mayora de los programas contables, con el fin de corregir las anomalas en el contenido de los ficheros, admiten un procedimiento de introduccin de datos desequilibrados (o sea, donde el debe no es
igual al haber) debiendo esta operacin estar reservada excepcionalmente
slo a los usuarios competentes. Si es utilizado de forma abusiva, este procedimiento, aunque responda a una necesidad real, puede conducir a situaciones totalmente anrquicas.
12

Tcnicas de la auditora informtica

Por supuesto, la diferenciacin entre el control del programa y el control


de la utilizacin del mismo es voluntariamente caricaturesca, y las cosas son
en realidad ms sutiles. Un buen programa contiene protecciones contra
una mala utilizacin 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 desigualdad entre dbitos y crditos 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 exclusin para el anlisis. Tambin es necesario examinar y conservar esta lista!
No es menos verdad que la fiabilidad de una aplicacin informtica
resulta de la conjuncin de un buen programa y de una utilizacin satisfactoria.
Control de la adecuacin del software desarrollado a las
especificaciones funcionales o control de la adecuacin de
las especificaciones funcionales para un buen control interno
Aqu tambin se encontrar por decirlo as la dualidad auditora de los informticos frente a auditora de los usuarios.
Verificar la adecuacin del software desarrollado segn 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 informtica estn de acuerdo con las necesidades
expresadas.
Pero esta adecuacin no es suficiente para garantizar la calidad de la aplicacin en su conjunto, puesto que las especificaciones funcionales pueden
ellas mismas revelar insuficiencias o anomalas.
Imaginemos, por ejemplo, un software de gestin 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 peridico de los listados editados implica la previsin de la edicin 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 va de revisin, 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 valoracin de existencias. La aplicacin no lograra ser considerada
como fiable si no se hubiera previsto la edicin de la lista de movimientos de
existencias en el pliego de condiciones.
Otro ejemplo: la concepcin de las aplicaciones debe permitir respetar
Los objetivos de la auditora informtica

13

los principios de separacin de las funciones. De este modo, en materia financiera, las operaciones de contabilizacin y las de tesorera, en principio,
deben estar conducidas por personas distintas. La concepcin y la utilizacin
del software deben tambin permitir respetar esta separacin, principalmente gracias a la puesta en prctica de controles de acceso apropiados.
ltimo ejemplo: un buen control interno implica la existencia de controles jerrquicos de las operaciones. Este principio tiene como consecuencia
informtica la definicin:
ya sea de procedimientos de ratificacin de las operaciones por un superior jerrquico desde su introduccin;
ya sea de procedimientos de edicin de listados de control de las operaciones introducidas (exhaustivo o por exclusin) para ser analizados a
posteriori por un superior jerrquico;
o bien, de una combinacin de ambos tipos de procedimientos.
De este modo, en materia de gestin comercial, algunas operaciones especficas introducidas por los vendedores, tales como unas comisiones acordadas, superiores a un cierto umbral, o superacin por parte de un cliente del
crdito mximo autorizado, etc., sern sometidas a la confirmacin del director comercial.

Bsqueda defraudes o bsqueda de errores


En la inmensa mayora de los casos, los riesgos de prdidas relacionadas
con los errores de realizacin o de utilizacin del software son infinitamente
ms importantes que los riesgos de prdidas relacionadas con las operaciones dolosas o fraudulentas. Es, por lo tanto, la bsqueda de errores lo que
ser generalmente privilegiada por el auditor en su enfoque.
Por supuesto, en algunos casos especficos (presuncin de malversacin
de fondos) o en ciertos sectores de la actividad (establecimientos financieros) la bsqueda de operaciones fraudulentas ser parte de los objetivos asignados a la auditora.
Entonces, se realizarn trabajos dedicados a esta bsqueda. As, en un establecimiento financiero se puede programar la ejecucin regular de un software especfico de barrido y anlisis de los movimientos en las cuentas ordinarias, con el propsito de revelar las operaciones sospechosas que sean
susceptibles de encubrir una malversacin de fondos.

14

Tcnicas de la auditora informtica

Control de calidad de los mtodos de desarrollo del software


o control de calidad de los procedimientos de utilizacin
La calidad de los procedimientos de concepcin y de realizacin de las
aplicaciones constituye un supuesto de fiabilidad y de respeto de las especificaciones funcionales.
Sin embargo, pueden aparecer anomalas graves en los ficheros cuando
un programa, aunque sea perfecto, no sea utilizado de manera satisfactoria.
De esta forma, los errores de utilizacin, como la doble ejecucin de un proceso en tiempo diferido o, por el contrario, su no ejecucin, pueden alterar
los datos contenidos en los ficheros.
Los procedimientos errneos de utilizacin pueden de igual modo tener
consecuencias dainas 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 encontrarn
perdidos y sern imposibles de reconstruir en caso de siniestro que destruya
dicho emplazamiento informtico.
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 concepcin, pero no perenne debido a malos procedimientos de utilizacin.
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 auditora de aplicacin


informatizada
Al igual que para la auditora general del entorno informtico, los demandantes potenciales son mltiples.
El responsable informtico, ante una aplicacin sujeta a crticas y preguntndose sobre la posibilidad de volver a redactarla, podr solicitar la auditora. Una misin de este carcter ser adems tanto ms til en un contexto de relaciones conflictivas entre el personal informtico y los usuarios,
en la medida que ella permitir obtener una impresin externa y neutral.
El responsable de un servicio que utilice la informtica estar tambin interesado en pedir que sea controlada la calidad de la aplicacin que le ha sido
suministrada. Ah tambin, la auditora le ser particularmente til cuando
sus colaboradores hagan valer las debilidades del software, que perjudican la calidad de su propio trabajo.
Los objetivos de la auditora informtica

15

Los controladores externos a la empresa desearn, 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 da justificar las cuentas de sus clientes sin interesarse por ciertas aplicaciones tales como: gestin y valoracin de existencias, gestin de inmovilizaciones, contabilidad analtica, etc.

1.3.3 Las dificultades de la auditora de una aplicacin


informatizada
Ya hemos mencionado las dificultades y los lmites de la auditora de una
aplicacin informatizada. Una aplicacin 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 aplicacin por la relectura de los programas que la componen.
Cuando ms que, incluso a travs de una relectura atenta de cada programa,
ser casi imposible detectar la mayora de los errores potenciales.
Y lo que es ms, ya hemos subrayado que la calidad de los programas
slo es uno de los elementos necesarios entre otros para la fiabilidad de una
aplicacin. Una mala utilizacin, los errores de utilizacin, o incluso las intervenciones directas en los ficheros, fraudulentas o simplemente errneas,
son otros tantos factores que perjudican la fiabilidad de la aplicacin y no
son detectables por el simple anlisis de los programas.
Ahora bien, es tan impensable pedir al auditor informtico que analice
uno a uno el conjunto de los registros del conjunto de los ficheros que estn
siendo utilizados como pedirle que analice lnea a lnea los programas.
Una primera conclusin se impone desgraciadamente y es que el auditor
informtico est desarmado ante el control de una aplicacin informatizada
e, independientemente de la duracin de su misin, no contar ms que con
supuestos pero jams con realidades. Esta primera constatacin explica por
qu las conclusiones de este tipo de misin aparecen algunas veces como decepcionantes teniendo en cuenta los costes que comportan.
No obstante, no caigamos en un exceso de pesimismo. Incluso cuando no
aporta la certeza, la auditora de una aplicacin no es intil y, para establecer
sus supuestos, el auditor dispone de diferentes mtodos que pasamos a detallar a continuacin.

16

Tcnicas de la auditora informtica

1.3.4 Los mtodos de auditora de una aplicacin


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 especficos.
Entonces, es posible controlar en este entorno el funcionamiento de los
programas de una manera profunda, dentro del mnimo de casos de test o
comprobacin que han sido suficientemente preparados.
Adems, antes de ser una tcnica de auditora, los juegos de prueba son
ante todo un medio que permite a los usuarios llevar a cabo la receta de
una aplicacin previa a su utilizacin.
Tcnica de una gran eficacia, los juegos de prueba son, sin embargo, raramente utilizados en materia de auditora. Su principal inconveniente reside
de hecho en la torpeza de su aplicacin, que implica a menudo cambios de
trabajo prohibitivos tanto para los informticos, que forman la base del test,
como para los auditores, que tienen que tener un conocimiento perfecto del
conjunto de las prestaciones del programa.
Adems, nombraremos las principales limitaciones de esta tcnica:
Permite comprobar los programas, pero no el contenido de los ficheros
en uso. Ahora bien, hemos visto que los ficheros pueden detectar anomalas sin que los programas estn equivocados.
Difcilmente es posible ser exhaustivo en los casos verificados por el
juego de prueba.
Esta tcnica raras veces permite detectar las operaciones fraudulentas en
la medida en que stas se llevan a cabo, bien por la intervencin directa
en los ficheros, o bien por una modificacin temporal de los programas,
que no aparecen en el momento de la creacin del software de comprobacin.

b) El examen del control del entorno informtico para esta aplicacin


Hemos mencionado (en el apartado a de 1.1) la primera preocupacin de
un buen control interno del entorno informtico de una empresa, que es, en
definitiva, una excelente prueba de la fiabilidad de los programas desarrollados.
En otras palabras, uno de los medios bsicos para controlar una aplicacin consiste en controlar la calidad del entorno informtico para esta aplicacin.
En concreto se estudiarn especficamente para la aplicacin auditada:
Los objetivos de la auditora informtica

17

Los procedimientos de desarrollo y de mantenimiento, o sea, instrumentos, metodologa, normas, documentacin, procedimientos de puesta en
marcha.
Los procedimientos de uso, o sea, proteccin de acceso, copias de seguridad, preparacin, arranque y control de trabajos en tiempo diferido,
procedimientos de recuperacin, seguimiento de incidentes.
Las funciones tcnicas, o sea, gestin de red, soporte microinformtico.
La organizacin general del servicio y del proyecto.
El enfoque dirigido hacia una aplicacin ser incluso ms preciso que un
control del conjunto del emplazamiento.
Recordemos que el estudio detallado de los mtodos de examen del control interno de la funcin informtica ser tratado en la segunda parte de la
obra.
El inters principal de este enfoque, adems 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 metodologa de desarrollo, la debilidad de la documentacin, la falta de un seguimiento de los incidentes, un gran laxismo en las autorizaciones de acceso
y una poltica de copias de seguridad o salvaguarda mal definida son tantos
signos inquietantes que es muy raro que no se materialicen a travs de graves
carencias en la aplicacin.
A la inversa, el principal reproche que se podra hacer a este mtodo es
que slo suministra suposiciones y jams las carencias detectadas.
As, la tcnica de los juegos de prueba pone en evidencia las anomalas
seguras en los programas, o sea, el no cumplimiento de las especificaciones
funcionales. De igual modo, el empleo del programa de auditora (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 funcin informtica por
la aplicacin constituye un primer enfoque relativamente poco costoso, pero
que merece, por lo general, estar complementado por una o varias tcnicas
de auditora.

c) Examen del control interno de la funcin tratada


Ya hemos subrayado que el control exhaustivo de una aplicacin implica
a la vez el control del software desarrollado y el control de la utilizacin que
se hace del mismo. Una aplicacin no puede ser considerada como fiable si,
a pesar de los programas de calidad, se la utiliza sin sentido comn.
18

Tcnicas de la auditora informtica

En otras palabras, la implicacin 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 mayora de los controles tcnicos
internos al servicio informtico. A pesar de ser una idea muy difundida, los
usuarios estn lejos de ser desarmados y tienen en sus manos los medios de
detectar la gran mayora de los fallos de un software, cuyo origen se encuentra en un error de programacin o en una mala utilizacin del sistema. Para
ello, tambin hace falta que no hayan renunciado a asumir toda la responsabilidad en el momento de la aplicacin de los tratamientos automatizados.
Muy a menudo, ya sea por exceso de confianza ante un dios informtico
infalible o bien por negligencia (la informatizacin es un excelente pretexto
para dejar de asumir sus propias responsabilidades), los usuarios tienen la
tendencia a dejar de efectuar el mnimo de controles indispensables de la fiabilidad del conjunto de la aplicacin.
Por consiguiente, el auditor informtico basar una parte importante de
sus investigaciones en la utilizacin y el control por parte de los usuarios de
los tratamientos informticos.
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 auditora de una
aplicacin, entre trabajar ante el servicio informtico y trabajar ante los servicios de usuarios, la segunda solucin sera indudablemente la ms eficaz.
Habiendo hecho esta constatacin, citamos algunos aspectos esenciales
en este mbito.
La realizacin 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 = totalizacin de
los asientos en los diarios contables del mes;
totalizacin de los asientos listados en los diarios contables del mes = totalizacin de los asientos del mes en los libros de mayor;
acumulado de principio de perodo de los asientos del mayor + total de
los movimientos del mes = acumulado de principio de perodo siguiente
(en dbitos y en crditos);
saldo de las cuentas del mayor = saldo de las cuenta del balance;
permitirn detectar la mayora de los errores de diseo, de aplicacin y de
Los objetivos de la auditora informtica

19

utilizacin del software contable. Tambin hace falta que sean utilizados regular y cuidadosamente.
La existencia de controles jerrquicos
La existencia de controles jerrquicos 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 informticos que permitan la corroboracin o el control de los datos registrados, por parte de un superior jerrquico del operador, o sea:
Listas-resumen de registros, detalladas o por exclusin, para control a
posteriori.
Procedimiento de autorizacin en tiempo real de determinados movimientos, previamente a su validacin (control a priori).
La existencia de una buena separacin 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 realizacin del fin social.
Operaciones relativas a la conservacin del patrimonio.
Operaciones relativas al tratamiento contable.
El cuidado de una buena separacin 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 especfico de los sistemas informatizados, el respeto de esta
separacin de funciones ser controlado por la aplicacin de sistemas de autorizacin de acceso a los tratamientos mencionados a continuacin.
La existencia de procedimientos satisfactorios de autorizacin de acceso
Una aplicacin no puede ser considerada como fiable si cualquiera que
pertenezca o, peor an, sea ajeno a la empresa, tiene la posibilidad de conectarse con sta y de consultar o poner al da los datos bsicos.
Ms all de los riesgos de operaciones fraudulentas o dolosas que son fciles de imaginar, existe, de hecho, un riesgo importante de errores cometidos con toda buena fe y cuyo autor ser a menudo difcil de localizar.
20

Tcnicas de la auditora informtica

Volveremos, por supuesto, ampliamente, en el resto de la obra sobre la


problemtica de las autorizaciones de acceso, que pueden ser controladas
por medio de diferentes tcnicas, de las cuales la utilizacin de palabras
clave es, hoy da, la ms difundida.
La capacidad y la integridad del personal
La capacidad y la integridad, tanto de los informticos como de los usuarios, constituye naturalmente un elemento esencial de la fiabilidad de las
aplicaciones.
La continuidad de la va de revisin
La nocin de continuidad de la va de revisin de un sistema de informacin (se habla a menudo de pista de auditora, del trmino anglosajn audit
LA NOCIN DE VA DE REVISIN
Extracto de la subseccin IV del Plan General de Contabilidad Francs
4e Debe ser posible, en cualquier momento, reconstruir a partir de datos
definidos a continuacin, los elementos contables, listados e informaciones sometidos a verificacin 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 identificacin de los datos correspondientes.
Extracto del Reglamento n 90-08 del 25 de julio de 1990
del Comit de Reglamentacin Saneara
En lo concerniente a la informacin incluida en las cuentas publicadas, el
sistema de control interno debe garantizar la existencia de un conjunto de
procedimientos, llamados pista de auditora, que permita:
a) reconstruir en orden cronolgico las operaciones;
b) justificar toda informacin por medio de un dato original a partir del cual
debe ser posible remontar por una va continua al documento de sntesis y
recprocamente;
c) explicar la evolucin de los saldos de un extracto al otro por la conservacin 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 clculo de
las normas de gestin establecidas en aplicacin del artculo 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 auditora. En este caso, se conservan los
elementos constitutivos de la pista de auditora relativos al extracto peridico
ms reciente y al ltimo clculo de algunas de las normas de gestin.

Los objetivos de la auditora informtica

21

trail) corresponde a la necesidad de conectar los datos introducidos en este


sistema y las informaciones obtenidas. En otras palabras, la aplicacin debe
suministrar los elementos necesarios para la validacin 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 va de revisin, o sea, el de la lista mensual de movimientos de existencias en un software de gestin de existencias.
Otro ejemplo ser ilustrado con la ayuda de una cadena de gestin del inmovilizado. Si el importe de la dotacin para amortizaciones del ejercicio se
suministra sin justificacin, es imposible controlar esta dotacin y habr prdida de la va de revisin. Por el contrario, si esta dotacin viene totalizada
en un listado que incluya, lnea a lnea, las amortizaciones del ejercicio se
puede detectar que:
Todas las inmovilizaciones pertenecientes a la empresa, y slo ellas, han
sido tomadas en consideracin.
El clculo de las dotaciones es correcto.
Mencionamos a ttulo de ilustracin que en Francia la nocin de va de
revisin ha sido consagrada sin que el trmino sea explcitamente empleado
por el plan contable 1982, y ms recientemente, bajo el trmino de pista de
auditora, por el comit de reglamentacin bancaria.
La existencia de validaciones regulares del contenido de los ficheros
Los ficheros controlados por una aplicacin informatizada contienen
ciertos datos cuyo contenido es susceptible de ser objeto de una validacin.
De este modo, las existencias son controladas peridicamente durante los inventarios fsicos3 y los saldos de las cuentas de terceros, clientes y proveedores, son implcitamente ratificados por la ausencia de litigios.

d) La utilizacin de los programas de auditora


Hemos vuelto a recuperar voluntariamente el trmino de software de auditora que es empleado corrientemente y, por desgracia, la mayora de las
veces de forma abusiva.
Por lo general, esta tcnica tiene como objetivo desarrollar programas
informticos cuyo objetivo es controlar la fiabilidad de las aplicaciones auditadas.
3. Igual que las inmovilizaciones (a intervalos ms distanciados).

22

Tcnicas de la auditora informtica

Los lenguajes de programacin, particularmente adaptados al desarrollo


rpido de peticiones de anlisis de ficheros, han sido a veces bautizados de
forma abusiva como software de auditora. En realidad, algunos de estos lenguajes tienen otros objetivos bsicos y slo son utilizados como accesorios
en materia de programacin:
lenguajes de infocentro para el anlisis rpido de los ficheros por los
usuarios;
lenguajes de desarrollo rpido de programas de edicin destinados a los
informticos para la obtencin de listados poco complejos.
Los lenguajes de programacin tradicional (COBOL, etc.) permiten adems el desarrollo de programas de auditora. Solamente el tiempo de programacin que implica su utilizacin (el Cobol es el de mayor difusin, pero
tambin de lejos el ms indiscreto de los compiladores) los hacen poco adaptados a este tipo de funcin.
Citemos por ltimo que algunos lenguajes han merecido la denominacin
de software de auditora por la asociacin a sus funciones bsicas de mdulos (rutinas) especficamente destinadas a fines de auditora, tales
como: muestreo, anlisis estadstico, etc.
Concretamente, los objetivos buscados por el diseo y la realizacin de
programas de auditora son variados y pueden ser distribuidos en dos categoras:
Los programas de seleccin para anlisis de ciertos registros
existentes en los ficheros
Los tipos de seleccin son en s mismos diversos.
En algunos casos, se trata de un simple muestreo, o sea, seleccin por
control de una factura entre 1000, seleccin de las compras ms significativas por su importe, etc.
Aun as, algunas veces estos registros detectan informaciones que, aunque no sean necesariamente errneas, justifican una bsqueda complementaria por su carcter excepcional, como por ejemplo, edicin de las ventas en
las que el porcentaje de comisin al cliente sea superior a un determinado lmite, edicin del inmovilizado adquirido con anterioridad a una cierta fecha.
En otros casos, por ltimo, las selecciones corresponden a anomalas, que
son resultado de un error de programacin o de una mala aplicacin de los
procedimientos: estado de existencias negativas, estado de ventas con prdidas, lista de los cdigos de artculos que figuran en el fichero de facturacin
y no aparecen en el fichero de referencias de artculos.
Los objetivos de la auditora informtica

23

Los programas de validacin de informaciones que provienen de la


aplicacin
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 redaccin de un
programa de evaluacin 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 artculo cuyo valor
total era de 106.000 pesetas haba sido valorado slo por 6.000 pesetas.
Ahora bien, en presencia de un fichero muy voluminoso, que representa un
listado en papel de varias decenas de pginas, este error podra muy bien pasar desapercibido en controles manuales.
Por supuesto que la reescritura para el control de ciertos programas no
puede ser ms que una tcnica restringida. Su generalizacin conduce, en
efecto, a redactar nuevamente la aplicacin auditada.
Ventajas e inconvenientes de la gestin
El principal inters de este proceso radica en dar resultados concretos y
en cifras. Adems, cuando los programas de control son bastante numerosos
y variados, la proporcin de anomalas detectadas dar una primera imagen
de la calidad de la aplicacin. Pero, sobre todo, estos programas pueden ser
completamente compilados.
Imaginemos por ejemplo que el objetivo sea controlar el seguimiento por
los vendedores de la poltica comercial. Los programas puestos en prctica
sern entonces del tipo:
Edicin de descuentos especiales acordados para ciertos clientes.
Edicin de descuentos especiales acordados sobre determinados artculos.
Edicin de clientes sobre los cuales el margen es insuficiente.
Edicin de los vendedores que realicen mrgenes insuficientes.
Etctera.
Imaginemos ahora que el objetivo sea controlar el seguimiento del procedimiento de entrega y de facturacin. Los programas puestos en prctica sern entonces por ejemplo:
24

Tcnicas de la auditora informtica

edicin de albaranes de entrega antiguos no facturados;


edicin de facturas en las cuales el precio unitario difiere de forma
notable del que figura en el fichero de lista de precio;
etctera.
El inconveniente del proceso es el contrapeso de su ventaja, o sea, slo
puede suministrar informaciones parcelarias. De hecho, incluso cuando se
utilizan lenguajes de programacin sofisticados (con o sin rutinas de auditora), cada control necesita el desarrollo de un programa especfico. Por lo
tanto, es indispensable definir claramente los objetivos buscados, con el fin
de evitar poner en prctica un alud de tests costosos e intiles.

1.3.5 Los principales grupos de aplicaciones


Exceptuadas deliberadamente las aplicaciones de tipo cientfico o industrial (control de procesos, etc.) debido a su carcter, estudiaremos de una manera ms detallada, en la tercera parte de la obra, las modalidades de control
de las principales aplicaciones de gestin informatizada de la empresa. stas
son:

Contabilidad general, analtica y auxiliar.


Gestin de existencias.
Gestin comercial.
Gestin de compras.
Gestin de inmovilizado.
Remuneracin y gestin del personal.

1.4 UTILIZACIN DEL INSTRUMENTO INFORMTICO


EN EL MARCO DE UNA MISIN DE AUDITORIA
Abusando del lenguaje, designamos a menudo con el trmino de auditora informtica el desarrollo de programas de control en el marco de una
auditora contable o de una auditora operativa.
En realidad, la informtica no es ms que un instrumento puesto al alcance del auditor para llevar a cabo su tarea principal: la auditora contable
tiene como objetivo la comprobacin de la regularidad y correccin de las
cuentas de la empresa y la auditora operativa pronunciarse sobre la fiabilidad y la eficacia de un ciclo de la empresa (aprovisionamientos, ventas, produccin, etc.)
Los objetivos de la auditora informtica

25

Teniendo en consideracin la fuerte automatizacin de la mayora de las


empresas, su control pasa necesariamente cada vez ms por un control de las
aplicaciones informatizadas, y por la utilizacin de instrumentos informticos destinados a reducir la duracin de estos controles mejorando as su eficacia.
Tomemos el ejemplo del auditor de cuentas que audita las inmovilizaciones. Ejecutado manualmente, el control del clculo de las dotaciones es a la
vez pesado y poco convincente, habida cuenta del pequeo tamao de la
muestra, que podr razonablemente validar.
En cambio, el diseo de un software, por lo general poco complejo, que
analice los ficheros del inmovilizado, permitir recalcular y validar la dotacin del ejercicio.
Y adems, los programas complementarios pondrn en evidencia anomalas eventuales para el anlisis:
lista de las inmovilizaciones cuya dotacin acumulada desde el principio
sea inferior al mnimo lineal (siendo las dotaciones en tal caso insuficientes y las dotaciones diferidas irregularmente, ya que no fueron contabilizadas, siendo finalmente no deducibles fiscalmente);
lista de las inmovilizaciones cuya fecha de aplicacin difiere notablemente de la fecha de instalacin;
etctera.
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 bsqueda de crditos antiguos y, si
fuere necesario, de evaluacin del importe de la cobertura a constituir.
Como se ve, la informtica se ha transformado hoy da en la herramienta
indispensable del auditor, sin cuyo dominio ste no podra cumplir su misin
de una forma totalmente eficaz.
Felizmente algunos lenguajes de programacin, llamados tambin lenguajes de infocentro, lenguaje de programacin rpida o software de auditora, estn bien adaptados a estas necesidades.
Sin embargo, la tarea no es fcil. Al llevar a cabo auditoras en empresas
dotadas de configuraciones de todo tipo, recurriendo a diferentes constructores, el auditor debe adaptarse a entornos muy variados, incluso, si es el caso,
por medio del dominio de varios lenguajes de programacin.

26

Tcnicas de la auditora informtica

Segunda parte

AUDITORA
DE LA ACTIVIDAD
INFORMTICA

Cmo estar seguro de la calidad del entorno informtico?


En otras palabras, qu controles hay que poner en prctica 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 bsicos de una organizacin que satisface la
actividad informtica.1
Con el propsito de suministrarle un soporte tcnico en su gestin, esta
segunda parte de la obra presenta, a partir de tales principios bsicos de una
buena organizacin, los principales puntos clave de evaluacin del control
interno de un entorno informtico, o sea, por as decir, la lista de las reas
que conviene estudiar a fin de hacer una apreciacin 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 mximo de preguntas sino dominar y evaluar los aspectos esenciales de la organizacin del
servicio controlado.
1. Estos principios estn especificados en la obra Les techniques de /'organisation informatique, coleccin Dunod Entreprise,1991, del mismo autor.

Auditora de la actividad informtica

27

Hemos mencionado en la advertencia al principio de la obra, los riesgos


inherentes a los cuestionarios voluminosos, donde, en definitiva, un gran nmero de preguntas se asemejan mucho las unas a las otras.
Las preguntas mencionadas han sido agrupadas en cinco partes:

28

La organizacin general del servicio.


Los procedimientos de desarrollo y mantenimiento del software.
El entorno de produccin.
Las funciones tcnicas.
La proteccin y la confidencialidad de los datos.

Tcnicas de la auditora informtica

Captulo 2

La organizacin
general del servicio
informtico

2.1 LA ESTRUCTURA DEL SERVICIO


INFORMTICO
P. Existe un organigrama escrito del departamento de
informtica?
Aunque el organigrama escrito pueda parecer superfluo e incluso acongojante en las estructuras pequeas, se impone desde el momento que el personal supera una decena de personas.
Encontraremos en la figura 1 una estructura tipo de servicio informtico y, en el recuadro que hay a continuacin, una sucinta descripcin de las
principales funciones extrada de la obra Les techniques de l organisation
informatique.
El auditor comprobar, por supuesto, que el organigrama que le es dado
est al da y cubre el conjunto de las funciones necesarias para la buena marcha del servicio.
Adems, las fichas de definicin de funcin son deseables, en particular
para ciertos puestos funcionales como: responsables de mtodos, administradores de datos, responsables de la seguridad, etc. El anlisis de estas fichas permitir algunas veces descubrir que determinadas funciones no estn
cubiertas.
La organizacin general del servicio informtico

29

Figura 1. Modelo de estructura de un servicio de informtica.


30

Tcnicas de la auditora informtica

A. LAS FUNCIONES PRINCIPALES EN EL SENO


DE UN SERVICIO DE INFORMTICA
a) La funcin de estudios
La funcin de estudios representa el conjunto del personal informtico
dedicado al desarrollo de nuevas aplicaciones y al mantenimiento de las mismas.
Estas aplicaciones sern utilizadas a continuacin por el personal de produccin. Para fijar bien las ideas, tomemos por ejemplo la aplicacin de un
nuevo sistema de gestin de pedidos y facturacin, decidida por la Direccin
general. El Director de informtica confa 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 ms evolucionados conocidos como de cuarta
generacin), y posteriormente el usuario valida la aplicacin gracias a un juego de prueba. Solamente despus 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 produccin. El personal de estudios no tendr ya que
intervenir excepto para las operaciones de mantenimiento, es decir, para las
operaciones de modificacin de las funciones de los programas. Volveremos
despus sobre los mtodos 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 funcin de produccin
Hace algunos aos esta funcin era a menudo llamada explotacin. Hoy
da, el trmino de produccin consagra definitivamente el paso de la informtica de la era artesanal a la era industrial.
En efecto, la organizacin de la produccin ha evolucionado profundamente en pocos aos, principalmente gracias al perfeccionamiento de los materiales y del software bsicos. Al mismo tiempo, la cualificacin del personal
de produccin ha subido considerablemente.
Para delimitar mejor lo que hoy da es la produccin en un centro de tratamiento, partimos de la situacin existente hace algunos aos (y que hoy da
algunas veces an existe), para despus entretenernos con las evoluciones ms
recientes.
Los preparadores: son los que han procedido a poner en marcha, y posteriormente en produccin, 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 daLa organizacin general del servicio informtico

31

tos de test. La aplicacin de estos programas necesita, por lo tanto, una modificacin 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 podrn proceder a una verdadera optimizacin del procedimiento. A ttulo de ejemplo, si el jefe de proyecto
hubiese previsto conservar en el disco duro un fichero destinado exclusivamente a fines de salvaguarda, el preparador lo podr copiar en cinta magntica para reducir el espacio de disco consumido por la aplicacin. En otras palabras y para simplificar las cosas, se puede considerar que el preparador hace pasar la aplicacin a tamao real.
Ms tarde, cuando una aplicacin se encuentre en produccin, ser el preparador quien asegurar el conjunto de parmetros y el arranque suministrando todas las consignas necesarias a los operadores y, por consiguiente, al
ordenador.
Los preparadores estn, 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 gestin de produccin, otro se encarga de todos los tratamientos de
tipo contable y el tercero se ocupa slo de las aplicaciones de gestin
comercial.
Los teclistas son las personas que estn en relacin directa con el ordenador por medio de su consola. Ellos ponen en marcha la mquina, la paran, la
vuelven a poner en marcha en caso de avera. Ponen en prctica la ejecucin
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 ms corrientes, tales como la
colocacin y retirada de cintas magnticas en las bobinadoras, colocacin de
papel en las impresoras, etc.
Los teclistas estn organizados en equipos para as asegurar una utilizacin continua de los ordenadores. Algunas veces 24 horas al da. Por lo general estn especializados en una mquina. Los equipos de teclistas estn algunas
veces bajo la responsabilidad de un jefe de sala.
La clula de control tiene como objetivo el control de los resultados de los
tratamientos en tiempo diferido antes de la distribucin a los servicios de
2. Veremos a continuacin un ejemplo simplificado intencionadamente con fines pedaggicos de un JCL de lanzamiento del programa FACT que lee en forma de secuencia el fichero de los pedidos para la emisin de facturas.
II JOB EDIFACT
Nombre de la tarea a ejecutar
II OPTION LOG, PARTDUMP Opciones de ejecucin
II ASSIGNSYS001, DISK,VOL=SYSWK1,SHR Relacin entre los ficheros lgicos descritos en el programa y ficheros fsicos en disco.
II DLBL FILE, FACTURE
II EXEC FACT
Lanzamiento de la ejecucin del programa
0292
Parmetro de ejecucin
32

Tcnicas de la auditora informtica

usuarios de los listados correspondientes. La clula de control debe tener de


este modo los cdigos que permitan detectar eventuales anomalas de uso.
El gestor del archivo de cintas asegura la gestin fsica del parque de cintas magnticas necesarias para las operaciones de salvaguarda.
El crecimiento excepcional de las capacidades de almacenaje en disco
magntico en el curso de los ltimos aos ha conducido algunas veces a bajar
la guardia en la vigilancia del espacio disco. La gestin del espacio disco representa una funcin importante en los grandes centros de proceso. El gestor,
por supuesto, cuenta con la ayuda de sistemas de herramientas cada vez ms
eficaces, que permiten una gran automatizacin de esta funcin.
La gestin de la red representa igualmente una funcin nueva e importante. En efecto, las configuraciones informticas actuales recurren, en gran parte, a las tcnicas de transmisin de datos directamente o a distancia, utilizando, en el segundo caso, conexiones telefnicas especializadas, la red telefnica
conmutada o tambin las redes especializadas. Adems de la necesidad de utilizar el software especializado, cuya implantacin es por lo general confiada al
personal de sistema, esta evolucin contribuy a crear las funciones de gestores de red, que garantizan el seguimiento continuo de la misma, por medio de
contacto telefnico con los usuarios,3 implantacin de nuevos terminales,
diagnstico de las paradas de sistema ms comunes (corte en la red, incidente
en la unidad central, terminal desconectado, etc.).
Slo los trabajos de manutencin (desconexin, guillotinado, encuadernacin, etc.) ocupan a menudo varias personas en los grandes centros informticos.
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 funcin se ha reducido considerablemente en el curso de los ltimos aos por el hecho de la aplicacin progresiva de procedimientos de registro interactivo por los propios usuarios. En algunos casos especficos, sin embargo, el registro masivo encuentra todava su
razn de ser.
Despus de este recuento de las principales funciones propias de la produccin informtica, conviene aportar un cierto nmero de complementos relacionados con la evolucin reciente de esta actividad.
Teniendo en cuenta el desarrollo de los sistemas de explotacin y en
particular del nmero de aplicaciones que pueden ser ejecutadas simultneamente en una misma mquina (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
tcnica del aparato, pero no de la calidad de las emisiones. Adems, la aparicin de los grandes sistemas de programas ha permitido automatizar un nmero importante de rdenes de tecleado y reducir otro tanto la carga de los teclistas, los cuales, la mayora de las veces, slo procesan las intervenciones
ms delicadas. En lo que concierne a la funcin del operador, sta debera
3. Se habla a menudo de hot Une.
La organizacin general del servicio informtico

33

desaparecer progresivamente, slo con la sustitucin de las cintas magnticas


por cuya manipulacin es totalmente automatizada.
Simultneamente, gracias a la evolucin de los sistemas de explotacin,
es posible prever una automatizacin cada vez ms estimulada por las cadenas
de proceso y por los procedimientos de reanudacin en caso de incidente. Partiendo de este hecho, se tiende a sustituir la nocin de preparador por la de
responsable de produccin de aplicacin, teniendo cono funciones:
La puesta en explotacin de las nuevas cadenas de proceso y optimizacin de la utilizacin de los recursos.
Su preparacin y su arranque con periodicidad ad hoc.
El control de su buena ejecucin.
Las relaciones con los usuarios.
El responsable de produccin de aplicaciones (o analista de aplicaciones)
cuenta adems desde ahora con instrumentos informatizados para la preparacin y control de explotacin.
El papel de la clula de control tiene tendencia a reducirse.
En efecto, las anomalas que tiene a su cargo descubrir tienen su origen:
ya sea en errores de explotacin, que pueden ser detectados por el
propio analista de explotacin al recibir los informes de explotacin
producidos por la mquina;
o bien, en anomalas funcionales, las cuales tambin son detectadas
con mucha eficacia por los propios servicios de usuarios.
c) Las funciones de sistemas
El software bsico puesto a disposicin de los informticos es cada vez ms
numeroso. Los sistemas de explotacin, compiladores, monitores de teleproceso, software de proteccin de acceso, sistema de gestin 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 parmetros
y, quizs lo ms delicado, conseguir que cohabiten de forma armoniosa.
d) Las junciones tcnicas
Estas funciones no han aparecido en la mayora de los centros informticos hasta el ltimo decenio.
Citaremos a ttulo de informacin las funciones en este rea:
Responsable de la microinformtica.
Responsable del infocentro (puesta a disposicin de los usuarios de
lenguajes de interrogacin simples).
Responsable de los mtodos.
Responsable de la seguridad.
Responsable de las bases de datos.
Responsable de las redes.
En los centros importantes, estas funciones estn a veces agrupadas en el
seno de una direccin tcnica.

34

Tcnicas de la auditora informtica

2.2 LA PLANJFICACIN DE LA ACTIVIDAD


INFORMTICA
P. Existe un comit informtico, responsable de las principales
decisiones estratgicas?
Con frecuencia, la Direccin general de la empresa delega a la Direccin
de informtica la definicin de la poltica a llevar a cabo. Esta delegacin es
evidentemente peligrosa en la medida de que el personal informtico tiene la
tendencia a favorecer a sus propios criterios en la elaboracin de las orientaciones estratgicas.
De este modo, las elecciones de equipamiento corren el riesgo de ser llevadas a cabo tanto en funcin del inters tcnico de la maquinaria como en
funcin de sus cualidades intrnsecas. Igualmente, las prioridades en materia
de desarrollo de los programas podran estar influenciadas por la calidad de
las relaciones de la informtica con los diferentes Directores de la empresa,
o incluso por el carcter ms o menos innovador de la aplicacin a ser concebida, tanto como por la importancia que sta representa para la empresa.
Incluso con un equipo de personal informtico 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 estratgicas sean llevadas a
cabo por la Direccin general. El comit de informtica, compuesto por representantes de la Direccin general, por responsables de cada Direccin de
la empresa, y por los principales responsables de la Direccin de informtica, es, por lo general, la instancia ms apropiada para asumir esta decisin.
Tendr a su cargo, por ejemplo, la elaboracin o la aprobacin del plan informtico, tanto equipos como software, los presupuestos, la definicin de prioridades a corto plazo, el arbitraje de los conflictos eventuales y el seguimiento de la calidad del servicio producido.
P. Hay un plan informtico?
El plan informtico tiene como objetivo anticipar las principales evoluciones de la actividad informtica, tales como: equipos, programas bsicos,
progamas de aplicaciones, recursos humanos.
La elaboracin del plan informtico es, no obstante, un ejercicio peligroso, teniendo en cuenta la rapidez de la evolucin tecnolgica. As pues,
cmo se pueden prever los equipos que sern implantados en una empresa
en un plazo de 24 meses, cuando los propios fabricantes desconocen lo que
La organizacin general del servicio informtico

35

ser su poltica comercial en este plazo, o por lo menos no la han revelado


todava al pblico?
De forma anloga, las prioridades de desarrollo de aplicaciones pueden
ser cuestionadas por varias razones, como por ejemplo: evolucin de la poltica comercial, situacin de la competencia, modificacin de la legislacin
vigente, etc.
Un plan informtico demasiado detallado est, por lo tanto, desgraciadamente condenado a una rpida 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 planificacin.
Tienen ms 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 Direccin general.

2.3 EL SEGUIMIENTO DE COSTES


P. Hay un presupuesto informtico?
Ms 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 captulo siguientes: equipos, programas bsicos, programas de aplicacin, remuneraciones, telecomunicaciones, materiales consumibles (papeles, etc.).
P. Se justifican sistemticamente los incrementos de costes?
Un crecimiento importante en los presupuestos de informtica no deben
ser criticados a priori. Puede corresponder a necesidades reales, tales como:
introduccin de una aplicacin importante, evolucin hacia un software ms
asequible. Pero, a la inversa, los presupuestos deben estar justificados y, si
fuere necesario, ser objeto de arbitrajes por parte de la Direccin general en
funcin de las prioridades que contenga.
P. Hay un seguimiento de la actividad del personal de informtica?
Cuando, en un centro pequeo, le compete al responsable de informtica
controlar la actividad de sus colaboradores, este seguimiento, sin las herra36

Tcnicas de la auditora informtica

mientas apropiadas, se hace rpidamente 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
distribucin en el seno del servicio entre las actividades de desarrollo y de
mantenimiento, sern mal identificadas.
El argumento frecuentemente evocado por los responsables de informtica 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 constatacin simple
del tipo: Cmo y por qu la informtica se ha transformado en la nica actividad que no se preocupa de sus precios de coste?
P. Se facturan los costes de la informtica a los servicios de
usuarios?
La respuesta a esta pregunta slo puede ser analizada en el contexto ms
general del control de gestin en el seno de la empresa.
La falta de facturacin de costes encuentra a veces su justificacin en la
voluntad de promover la informtica. Esta promocin, no obstante, a
priori ser limitada en el tiempo.
Cuando hay refacturacin, sta incluir habitualmente una separacin
entre:
Los costes de desarrollo.
Los costes de mantenimiento.
Los costes de explotacin.
P. Hay en el seno del servicio de informtica una funcin
de auditor de gestin?
Curiosamente, la Direccin de informtica ha sido una de las ltimas direcciones de la empresa en preocuparse por controlar sus costes. Con frecuencia, la informtica ha vivido en el axioma de que todo crecimiento de su
presupuesto contribua a la automatizacin de sus usuarios y, por lo tanto, a
una reduccin 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 intiles o lujosos,
las dificultades sociales que impiden cualquier reduccin de los efectivos, la
inadaptacin de la organizacin, son algunos de los factores que limitan las
reducciones posibles de gastos generales.
Hoy da, la mayora de las empresas ha comprendido que el control de los
La organizacin general del servicio informtico

37

gastos generales pasa tambin, entre otras cosas, por un control de los gastos
de informtica, justificando as la creacin de una funcin de auditor de gestin en el seno de esta direccin para los grandes centros, o por lo menos el
seguimiento por parte del auditor de gestin de los costes de informtica al
igual que los otros costes.

2.4 LAS PRCTICAS CONTABLES Y FINANCIERAS


P. La eleccin del modo de financiacin de los equipos, es
econmicamente satisfactoria?
La eleccin del modo de financiacin (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 duracin previsible de la utilizacin del equipo.
P. Son coherentes los perodos de amortizacin elegidos para los
equipos y, en su caso, para el software, con su perodo de utilizacin previsible?
Los equipos y programas adquiridos se amortizan en su perodo probable
de utilizacin.
Los perodos de amortizacin demasiado largos son con el tiempo generadores de prdidas excepcionales.
A ttulo de ejemplo, podemos prever un perodo de amortizacin de:
Tres aos para los microordenadores.
Cinco aos para otros equipos.
Cinco aos para los programas, salvo aquellos que estn relacionados
con los equipos, que se amortizan en el mismo tiempo que stos.
Los gastos de desarrollo interno de software especfico son la mayora
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 perodo probable de utilizacin de los
programas.4

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

38

Tcnicas de la auditora informtica

2.5 LAS RELACIONES CON LOS SERVICIOS


DE USUARIOS
P. Hay un seguimiento de la calidad del servicio prestado?
Los instrumentos de medicin simples dan una primera estimacin de
esta calidad de servicio:
Disponibilidad de la unidad central.
Disponibilidad del teleproceso (incluso disponibilidad de las lneas
mismas).
Tiempo de respuesta medio de las transacciones.
Frecuencia de los incidentes por aplicacin.
Por otro lado, las herramientas de seguimiento permiten optimizar la configuracin y, en su caso, anticipar las evoluciones de stas antes de que se registre una degradacin de las actuaciones. Se trata, por ejemplo, de los instrumentos de medida de la carga de la unidad central de la tasa de ocupacin
de los discos.

P. Est previsto en el servicio de usuarios una Juncin de


corresponsal informtico?
El corresponsal informtico es, en cada servicio, la interfaz con los informticos. El inters de esta funcin es innegable. En efecto, el corresponsal
informtico dispone, adems de un buen conocimiento de la actividad de su
servicio, de una buena cultura general informtica 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 funcin, es de temer que no tardarn mucho en llegar
al servicio de informtica peticiones contradictorias.

P. Se tienen en cuenta en el diseo de nuevas aplicaciones los


problemas relacionados con la organizacin de los servicios de
usuarios y con la adecuacin de los procedimientos
administrativos ?
Se pueden considerar varias soluciones para dar respuesta a este objetivo:
Creacin de una estructura de organizadores dependientes del responsable de informtica.
La organizacin general del servicio informtico

39

Creacin de una direccin de la organizacin dependiente de la direccin


general.
Reclutamiento de jefes de proyectos de alto nivel capaces de asumir
igualmente la funcin de organizador (esta ltima solucin es, no obstante, cada vez mas difcil de aplicar teniendo en cuenta la dicotoma entre las competencias tcnicas, cada vez ms elevadas, exigidas a los jefes
de proyecto, y las competencias especficas inherentes a la funcin de organizador).

2.6 LA SEPARACIN DE FUNCIONES


P. Hay en la organizacin del servicio informtico una
separacin entre las funciones de estudios y las de explotacin?
Los principios de un buen control interno conducen a que sean separadas
las funciones:
de los usuarios;
del personal de estudios;
del personal de explotacin.
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
explotacin.
El personal de estudios
Desarrolla y prueba los nuevos programas en un entorno de prueba dedicado a este fin, despus solicita la puesta en explotacin. En cambio, una vez
en explotacin, no tiene acceso por ningn medio a los ficheros.
De este modo:
No conoce la palabra clave de los usuarios de la aplicacin que l mismo
ha desarrollado.
No tiene acceso ni a los ficheros ni a la biblioteca de programas en explotacin.
No pone l mismo en explotacin los programas que ha desarrollado.
40

Tcnicas de la auditora informtica

El personal de explotacin
Es responsable de la puesta en explotacin y de la produccin de los programas desarrollados por el personal de estudios. En cambio, no debe, bajo
ningn concepto, desarrollar o actualizar l mismo tales programas.
* * *
Los medios para conseguir una buena separacin de las funciones son varios y volveremos a hablar de los mismos ms adelante de forma ms detallada.
Citemos a modo de ejemplo:
El control de acceso de los usuarios al entorno informtico (palabras
clave, cartas de memoria, etc.).
La limitacin 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 mayora de las veces, el personal de estudios no tendr acceso a los locales ocupados por el personal de explotacin.

2.7 EL CONTROL DE LA ACTIVIDAD


P. Se efectan regularmente misiones de auditora de la
actividad informtica?
Como hemos aclarado en la primera parte de la obra, un control de la actividad informtica puede cubrir diferentes aspectos, tales como:
Control de seguridad o control de las actuaciones.
Control del entorno informtico o control de una aplicacin particular.
Este control puede, adems, ser llevado a cabo a diferentes niveles. En
efecto, podr ser efectuado dentro del servicio informtico (por ejemplo, por
un responsable de seguridad); o bien fuera del servicio informtico pero dentro de la empresa (generalmente por la Direccin de la auditora); o, por ltimo, fuera de la empresa (contrato de servicio).
Por lo general, el auditor se ocupar de la frecuencia de las auditoras realizadas anteriormente y, por supuesto, de las conclusiones de las mismas.
La organizacin general del servicio informtico

41

2.8 EL ENTORNO SOCIAL


P. Es coherente la tasa de rotacin del personal informtico?
Un primer indicador social es, por supuesto, el turn-over del servicio.
Una rotacin muy importante o una rotacin muy escasa estn encaminadas
a daar la calidad del servicio prestado. Los inconvenientes de la primera
opcin, la cual de alguna forma es la enfermedad crnica de la informtica,
son evidentes: poco dominio de las aplicaciones por parte de los equipos que
no participaron en su diseo, falta de experiencia, falta de motivacin de los
informticos que tienen tendencia a considerarse como de paso.
No se deben menospreciar los inconvenientes de una rotacin demasiado
escasa de efectivos. sta conduce, en efecto, a un envejecimiento de la poblacin con los riesgos que esto comporta: falta de motivacin, disminucin
de la competencia tcnica y de la capacidad innovadora y costes de prestaciones elevados. Es verdad que el problema se parece bastante a la cuadratura del crculo. El informtico, ms que ningn otro, est considerado como
obsoleto a partir del momento que se acerca a los cuarenta, adems por razones, la mayora 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 reduccin de competencia.
Muy concretamente, el auditor estar particularmente vigilante ante tasas
de rotacin inferiores al 15 % o superiores al 25 %. Tambin hace falta especificar la gran propensin que tienen las empresas a cubrir las estadsticas
en este campo. As pues, si todas las ESII5 reconocen el problema general de
un gran turn-over en la profesin, cada uno, individualmente, probar con
base estadstica que es bastante reducida.
En cualquier caso, la tasa de rotacin del personal slo puede ser analizada en relacin con algunas caractersticas de la gestin de los recursos humanos que mencionaremos sucintamente a continuacin.

P. Es satisfactoria la poltica de contratacin de personal?


Un turn-over importante tiene algunas veces su origen en los procedimientos de contratacin de personal. De este modo, la contratacin sistemtica de principiantes implica un riesgo ms grande de rotacin rpida. De la
misma forma, la contratacin de personas super cualificadas conduce a una
rpida puesta en cuestin, por parte de stas, de su estatuto, pues ah tambin
existe una gran probabilidad de salida.
5. Empresas de servicios e ingeniera informtica.

42

Tcnicas de la auditora informtica

Las remuneraciones muy bajas en la contratacin o, por el contrario, demasiado elevadas son igualmente orgenes de dificultades rpidas.
Adems, la validacin de la competencia y de la integridad de las personas contratadas y su adecuacin a los puestos propuestos, constituye un
componente esencial de la calidad del procedimiento. Si bien una validacin
tcnica es a menudo delicada, la empresa no se encuentra totalmente desarmada.
P. La poltica de remuneracin est de acuerdo con las normas
del mercado?
Una poltica de remuneraciones muy bajas conduce en poco tiempo a un
turn-over elevado. La situacin inversa es igualmente peligrosa. Las remuneraciones demasiado altas son fuente de inmovilismo, luego de envejecimiento de una poblacin cuya edad media es, en principio, baja.
Adems, el auditor comprobar que dentro del servicio las remuneraciones sean coherentes entre s.
P. Es coherente la cualificacin del personal con la funcin que
ejerce?
Si el exceso de cualificacin del personal es fuente de rotacin rpida, la
falta de cualificacin es todava ms lastimosa, ya que ella induce a un
riesgo, en muy corto espacio de tiempo, de degradacin 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 tcnica especial y adquirir
progresivamente estas tcnicas.
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 estn totalmente
justificados:
La organizacin general del servicio informtico

43

Los colaboradores no deberan ocupar puestos que les dieran las responsabilidades jerrquicas dentro del servicio (jefes de proyecto, etc.).
El nmero de colaboradores no debera en ningn caso sobrepasar del 20
al 25 % del personal.
P. Ha habido en el pasado hechos significativos en materia de
gestin de personal?
El auditor se interesar, por ejemplo, por:
Un nmero elevado de despidos, y las condiciones de estos despidos.
Los movimientos sociales (huelgas,...).
P. El inters tcnico de la actividad informtica permite una
motivacin satisfactoria del personal?
Est claro que el servicio informtico no debe definir su actividad por
amor al arte. Escoger los equipos y el software bsico ms sofisticados implica no solamente un incremento del coste de los servicios prestados, sino
tambin, en particular, un riesgo de encontrarse con problemas tcnicos, que
los servicios seguramente no sabrn resolver.
De este modo, muchos programadores, aficionados a las bases de datos
interrelacionadas, han tenido que renunciar a esta tcnica, cuando sta estaba
an en sus principios, debido al tiempo de proceso prohibitivo que implicaba. En este caso los propios programadores se han dado cuenta de que no
tenan ninguna necesidad de una base de datos relacionada. Desgraciadamente este descubrimiento ya haba costado tiempo y dinero a su empresa.
Se comprende entonces que la utilizacin de las tcnicas ms sofisticadas,
aunque no estn todava 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, adems son susceptibles de desarrollar aplicaciones experimentales.
En cambio, la implantacin de equipos y de software bsico poco difundidos, o superados tcnicamente, al igual que el desarrollo de aplicaciones
basndose en diseos obsoletos, son un factor de desinters por parte de los
informticos. Qu jefe de proyecto estara interesado actualmente en un diseo de un software totalmente basado en tiempo diferido (batch), cuando
incluso el tiempo real estara efectivamente totalmente injustificado?
Independientemente de las consideraciones de carcter puramente tcnico, que justifican por s solas la evolucin de las configuraciones, la Direccin de la empresa pondr todo su inters en velar por que su informtica no
se torne arcaica.
44

Tcnicas de la auditora informtica

En el caso de configuraciones estereotipadas y pasadas de moda, que algunas veces encuentran su razn de ser (por qu refundir las aplicaciones
en los sectores de actividad con prdida de velocidad y condenarlas a un
abandono progresivo?), deber entonces anticipar el riesgo de una falta de
motivacin progresiva de los equipos de personal informtico.
Y lo que es ms, una configuracin obsoleta conduce a una obsolescencia rpida de los hombres mismos, la cual conviene tambin prevenir.
P. Es suficiente la formacin del personal?
Incluso cuando la formacin permanente en el taller es una caracterstica principal de la actividad de los informticos, las formaciones tericas
ocupan a la par, y con toda razn, una parte importante en el presupuesto de
los recursos humanos de los servicios informticos.
Una poltica de formacin insuficiente es, en efecto, un factor a la vez de
falta de motivacin y de disminucin de capacidad del personal.
P. El contexto general de la empresa es fuente de motivacin?
Un sector de actividad en declive o aun una localizacin geogrfica desfavorable pueden tener consecuencias catastrficas en la contratacin y en la
rotacin de los informticos, los cuales, en un mercado dinmico perdern el
inters por las empresas que tengan algn handicap.
He conocido una empresa con estas caractersticas, cuya informtica era
tcnicamente competitiva y actualizada, pero que no poda retener a sus informticos por la nica razn 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 licitacin o concurso para la eleccin de los suministradores de equipos o de software?
El recurso de proveedores externos para un servicio informtico puede
distribuirse en tres categoras:
6. Facilities management (gestin de servicios) consiste en la subcontratacin total o parcial de la actividad informtica (desarrollo y explotacin) a un suministrador del servicio externo.

La organizacin general del servicio informtico

45

La adecuacin de los equipos frente a los fabricantes (o, segn la forma


de financiacin, ante las sociedades de leasing).
La adquisin de software, comercializado por los fabricantes de hardware o, ms frecuentemente, por las ESII (Empresas de Servicios e Ingeniera Informtica).
El recurso a las ESII para la elaboracin, en administracin o en bajo
contrato, de software especfico para la empresa.
Veremos en los cuadros que siguen una lista de comprobacin relativa a
estas prestaciones externas.

B. CUESTIONARIO RELATIVO A LA ELECCIN DE LOS EQUIPOS


El llamado a licitacin del equipamiento
Se lleva a cabo una licitacin para la eleccin del equipamiento que representa importes significativos (en la medida en que el equipo no va impuesto por una estimacin preexistente)?
Incluye: el pliego de condiciones del equipamiento que sirve de soporte a
la licitacin
La descripcin de las aplicaciones a procesar?
Una estimacin de los volmenes presentes y futuros?
Una lista de las exigencias de explotacin, tales como tiempo de respuesta, duracin de los procesos, procedimientos de reactivacin,
confidencialidad, etc.?
Las fechas de entrega de los equipos a ser respetadas?
La eleccin de las prestaciones se halla formalizada y basada en criterios concretos?
* La negociacin 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
volmenes 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 configuracin?
Las condiciones del mantenimiento, como costes, modalidades, retraso de intervencin, 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 averas?
Rapidez y calidad de las intervenciones de mantenimiento?

46

Tcnicas de la auditora informtica

- Se ha estimado el coste de mantenimiento de los equipos?


El plazo de intervencin 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 ELECCIN DE PROGRAMAS
- Se redacta un pliego de condiciones previamente a la eleccin de los programas (salvo cuando esto es impuesto por una situacin existente con anterioridad, como por ejemplo el caso de cierto paquete de software bsico
del fabricante)?
- Incluye el pliego de condiciones del programa:

la descripcin de las funciones a procesar?


los volmenes a procesar?
los plazos para el arranque?
las obligaciones en materia de seguridad?
los datos bsicos que deben ser controlados en los ficheros?
una descripcin de las funciones cuya entrega podra ser solicitada en
una segunda etapa?
- Se estudian y comparan varios programas antes de la eleccin definitiva?
- Se apoya la eleccin definitiva sobre:
la calidad de las propuestas recibidas?
visitas a compaas que tienen el programa?
consideraciones generales sobre el proveedor, como: envergadura,
notoriedad, calidad de los interlocutores, etc.?
las consideraciones concernientes al programa, como: nmero de referencias, perennidad previsible, etc.?
la calidad de la documentacin 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 volmenes previstos en el
pliego de condiciones?
las penalizaciones, en caso de retraso por parte del colaborador?
la definicin precisa de la asistencia prestada, como: formacin, documentacin, asistencia en el arranque, mantenimiento inicial, etc.?
las condiciones del mantenimiento del programa?
las condiciones de pago del coste de la prestacin?7
- Est previsto que la empresa disponga de los programas fuente?
7. Por lo general, se prev un calendario de pagos en funcin del avance de las prestaciones:
el primer adelanto al efectuar el pedido;
pago contra entrega de software despus de la factura provisoria, o sea, de la validacin por parte del cliente basndose en un juego de prueba; se retiene un saldo de garanta
hasta la factura definitiva.
pago del saldo cuando se emite la factura definitiva, despus de algunos meses de funcionamiento satisfactorio del software.

La organizacin general del servicio informtico

47

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; adems del inters 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 validacin del programa sobre la base de un
juego de prueba en el momento del arranque?
La utilizacin posterior del programa:
Est previsto un seguimiento cualitativo del programa, como: histrico de los bugs,8 rapidez del mantenimiento?
La modificacin 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 ms en condiciones de garantizar el mantenimiento de su producto y, adems, ser difcil implantar las versiones siguientes)?
D. CONVOCATORIA A LAS ESII PARA LA REALIZACIN
DEL SOFTWARE ESPECFICO SOBRE UNA BASE DE PRECIO ALZADO
Siendo el procedimiento relativamente cercano a los de la eleccin de un
programa, las preguntas del apartado C son siempre vlidas. Sin embargo,
pondremos especial inters en algunos aspectos ms sensibles en el caso de
un software especfico:
La calidad del pliego de condiciones que sirve de base a la relacin contractual y el hecho que sta defina con suficiente exactitud las funciones a
desarrollar.
Los medios para asegurar el respeto de los plazos de realizacin por el suministrador del servicio.
Los puntos de validacin intermedios proyectados, como: anlisis funcional (si no vienen ntegramente detallados en el pliego de condiciones), anlisis tcnico detallado, etc.
La calidad de las modalidades de validacin del software antes de su puesta en explotacin (generalmente sobre la base de un juego de prueba que
sirve de soporte a la receta provisoria).
El contenido de la documentacin entregada.
E. CONVOCATORIA A LAS ESII PARA LA REALIZACIN
DEL SOFTWARE ESPECFICO EN ADMINISTRACIN9
En este caso, la ESII tiene por lo general como nica obligacin aportar el
personal de estudio (ingenieros, analistas y programadores) que se integrarn
en los equipos de desarrollo que trabajan con los proyectos conducidos por la
empresa misma.

8. Anomala de programa.
9. El trmino en administracin consiste en que la ESII factura su asistencia en funcin del
tiempo empleado por los colaboradores que ella pone a disposicin de su cliente.
48

Tcnicas de la auditora informtica

El auditor se encargar de algunos aspectos especficos relativos a la participacin de colaboradores externos a la empresa en el proyecto, tales como:
Modalidades de eleccin 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 deontolgicas
en materia de confidencialidad de la informacin.
Seguimiento especfico de la actividad de los colaboradores externos.
Prohibicin de acceso de los colaboradores externos a ciertas funciones
(si fuere necesario).
Coherencia de las tasas diarias de facturacin.

La organizacin general del servicio informtico

49

Captulo 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 oposicin a la fase de explotacin
(o de produccin) posterior al arranque real de la aplicacin.
Sern, por lo tanto, estudiados en este captulo los principales mbitos de
investigacin relativos a la auditora de un servicio de estudio.

3.1 LA METODOLOGA DE DESARROLLO DE LAS


APLICACIONES
P. Se realiza siempre un estudio de oportunidad previo
al lanzamiento del diseo de una nueva aplicacin?
La oportunidad o no de desarrollar una nueva aplicacin no es siempre
evidente. De este modo, el auditor se encuentra algunas veces frente a costosos estudios detallados de sistemas de informacin, 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 satisfac50

Tcnicas de la auditora informtica

torio y que era completamente intil sustituirlo. O an, el diseo de la nueva


aplicacin adquira proporciones considerables y ha parecido ms razonable
interrumpirla antes que alcanzara proporciones desorbitadas.
Estas situaciones muy costosas son generalmente el sntoma del mismo
error: la ausencia, al principio del estudio, de una reflexin previa en cuanto
a la oportunidad del proyecto. Esta reflexin tiene como objetivo, despus
de un anlisis sumario de las necesidades de la arquitectura tcnica futura de
la aplicacin, estimar el coste global del proyecto, para despus pronunciarse sobre la prosecucin de su aplicacin.
Con el fin de facilitar la decisin, el estudio de oportunidad presentar,
adems, las ventajas y los lmites del sistema propuesto, las principales
obligaciones inherentes de su aplicacin, y un primer calendario de realizacin.
La instancia de decisin en cuanto al abandono o la prosecucin del proyecto ser generalmente el Comit informtico o, ms directamente, la Direccin general. Una decisin llevada a cabo por el servicio informtico, 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 eleccin por parte de los susodichos servicios.
Si se da el caso, ms all de la decisin de abandono o de prosecucin del
proyecto, se arbitrar un cierto nmero de decisiones tcnicas fundamentales
al final del estudio de oportunidad, tales como: informtica centralizada o
descentralizada, prioridades de arranque, desarrollo de software especfico o
adquisicin de programas, etc.
Por ltimo, hacemos mencin a que, si se puede admitir una cierta flexibilidad en el nivel de formalizacin del estudio de oportunidad (no es, por
ejemplo, deseable exigir de una PYME documentos voluminosos para el
estudio de proyectos pequeos), la existencia misma de una reflexin
previa al lanzamiento de cada proyecto es, en cuanto a ella, del todo indispensable.
El estudio de oportunidad incluir principalmente:
La presentacin sucinta de las funciones a desarrollar.
Las principales obligaciones de aplicacin.
Si fuere necesario, una presentacin de las diferentes soluciones tcnicas
entre las cuales ser conveniente arbitrar.
Una estimacin de los volmenes a procesar.
Una estimacin de los costes previstos y, si fuere el caso, de los beneficios financieros esperados.
Un calendario preventivo de la aplicacin.
Desarrollo y mantenimiento del software

51

P. Ante todo desarrollo de software o toda adquisicin


de programas, se analizan las ventajas y los inconvenientes
respectivos de la adquisicin de un programa
y de la realizacin de un sistema especfico?
Conviene insistir muy particularmente sobre la utilidad de este anlisis.
Muy a menudo, los servicios informticos desarrollan sistemas de contabilidad general o de nmina muy complejos, por el solo hecho de incluir algunas necesidades complementarias de menor importancia en relacin a las
prestaciones de los programas disponibles en el mercado.
P. Se redacta un pliego de condiciones previo al lanzamiento
de la realizacin de nuevo software?
Evitaremos aqu un debate semntico sobre las diferentes fases de la vida
de un proyecto. Modelos conceptuales y organizativos de los procesamientos y de los datos (vocabulario ligado a la metodologa MERISE), anlisis
funcional (que define las funciones del software a desarrollar por oposicin
al anlisis orgnico que defini las especificaciones tcnicas), pliego de condiciones, etc., son muchos trminos cuyo contenido exacto puede variar ampliamente de una interpretacin a otra.
De todas formas, si el nmero y el contenido exacto de las diferentes fases de un proyecto puede variar en funcin del tamao de la empresa y de la
importancia de los proyectos, existe un punto de paso obligado en todo proyecto: el acuerdo entre los informticos y los usuarios sobre el contenido de
la aplicacin 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 informacin.
De alguna forma, se puede comparar el pliego de condiciones con la recuperacin de los puntos de apoyo antes de la ejecucin de una volea en un
partido de tenis. Si el atacante no se toma su tiempo para la recuperacin de
sus puntos de apoyo, la volea, jugada en desequilibrio, terminar en la red o
fuera de los lmites de la pista.
Ocurre lo mismo con el pliego de condiciones. En su ausencia, es casi seguro que los programas desarrollados no correspondern a las necesidades
de los usuarios. El ahorro de algunos das empleados en la redaccin, sin
duda alguna trabajosa, de un documento de sntesis, parecer irrisorio en
comparacin con los costes extraordinarios y los retrasos en los plazos que
tendrn origen en esta falta de comprensin.
Y adems, esta ausencia de formalizacin ser fuente de conflictos. La
inadecuacin del software es consecuencia de una mala expresin de las ne52

Tcnicas de la auditora informtica

cesidades por parte de los usuarios, o bien de un mal anlisis por parte de los
informticos?
Por tanto, la formalizacin de los anlisis preliminares al desarrollo de un
software es el origen de duros debates entre auditores y auditados. Cuntas
veces he odo a los responsables de pequeas estructuras informticas 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 adems infinita:
para tal mquina, el anlisis funcional es intil!;
en nuestra empresa, los nuevos desarrollos son escasos y siempre de
poca monta (pero mi predecesor, que haba desarrollado varias aplicaciones muy gravosas, no nos ha dejado ningn anlisis, lo que nos plantea
grandes problemas);
tenemos los informticos ms importantes y los usuarios ms inteligentes y, no obstante, los dossieres son intiles;
mi Director general tiene toda mi confianza.
El nico problema de este cuadro idlico es finalmente que, al salir del
contexto de una auditora, estos mismos responsables informticos confesarn 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 slo ocurre a
los dems encuentra del todo su aplicacin en los fracasos de proyectos informticos.
Sin que la lista sea exhaustiva, podemos nombrar como principales documentos contenidos en el pliego de condiciones:

La descripcin de las funciones a desarrollar.


La descripcin 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 aplicacin (a excepcin de los ficheros de trabajo).
La previsin de los volmenes a procesar.
Segn el caso, encontraremos igualmente las modalidades y el calendario de ejecucin y de arranque de la aplicacin.
Para concluir este importante y espinoso tema, citaremos una evolucin
interesante para el anlisis de las aplicaciones. El desarrollo de programas de
maquetacin que, principalmente para las aplicaciones transaccionales,
permite visualizar en la pantalla las propuestas de clave de registro y de conDesarrollo y mantenimiento del software

53

sulta que formarn la aplicacin. Si bien estos modelos no sustituyen en


ningn caso a un pliego de condiciones, ya que slo definen los soportes de
entradas y salidas interactivas pero no los procesos en s, se debera, sin embargo, generalizar de forma progresiva y substituir los diseos demasiado
complejos de la pantalla por soporte en papel.
Las herramientas de preparacin de prototipos son, en s mismas, mucho
ms completas, puesto que permiten presentar el conjunto de una aplicacin
futura antes de una programacin en firme. Su nico inconveniente, pero en
justa medida, reside por ltimo en el tiempo necesario para la elaboracin
del prototipo.
P. Existen normas en materia de desarrollo de aplicaciones?
Evidentemente, es totalmente indispensable que se adopte un mtodo en
materia de desarrollo de aplicacin. En cambio, la cuestin de saber si un
mtodo reconocido en el mercado es preferible a las normas de la casa es
ms delicada.
En un entorno de grandes empresas o de administraciones pblicas, la
eleccin de un mtodo ampliamente difundido se impone indiscutiblemente.
Los mtodos como el MERISE, el estndar por antonomasia, o el AXIAL
(propuesto por IBM) presentan la ventaja, debido a su amplia difusin, de
ser conocidos por gran nmero de informticos y, por lo tanto, de poder ser
impuestos con facilidad en el seno de la empresa. Presentan, adems, la ventaja de un gran rigor, necesario para el desarrollo de proyectos muy importantes (ms concretamente, consideraremos como importantes los proyectos
cuyo coste global alcanza varias decenas de millones de pesetas).
En las empresas pequeas o medianas, o bien para proyectos de menor
envergadura, los mtodos citados anteriormente representan, por lo general,
el inconveniente de una carga demasiado elevada. Por ello, no es extrao encontrar en las empresas mtodos caseros. Se imponen entonces en el desarrollo de un proyecto el respeto de ciertas etapas y la formalizacin de documentos cuyo contenido tipo ser predefinido.
Se impondrn, por ejemplo

El estudio previo.
El pliego de condiciones.
El anlisis tcnico.
Las normas de programacin.

P. Existen normas en materia de programacin?


La existencia de normas de programacin es un principio que tiene por
54

Tcnicas de la auditora informtica

finalidad mejorar la calidad de los programas producidos, en la medida que


stos constituyen una verdadera gua de especial utilidad para los programadores debutantes. Adems, conducen a una mejor homogeneidad del conjunto del software de la empresa.
Distinguiremos con ms exactitud:
Las normas concernientes a la estructura general de los programas
Los mtodos como la programacin estructurada, o tambin WARNIER,
proponen una estructura comn para el conjunto del software desarrollado.
Adems, nos daremos cuenta que ciertos lenguajes de desarrollo (lenguajes
de cuarta generacin, generadores de programas) imponen, de hecho, una
estructura de programacin.
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;
etctera.

Para poder ser respetadas, las normas de programacin sern inscritas en


un documento escrito y difundidas al conjunto del personal de estudios.
P. Se utilizan herramientas del tipo taller de ingeniera de software?
El trmino taller de ingeniera de software (TIS) se utiliza, hoy da,
para designar funciones muy diversas en el desarrollo de aplicaciones. El
producto MAESTRO, de PHILIPS, fue, en los aos setenta, el precursor de
los TIS de hoy da. Sus funciones en aquella poca cubran principalmente la
gestin de las bibliotecas de software de estudios y de explotacin y la automatizacin de procesos de puesta en explotacin.
Las posibilidades de los TIS son hoy da mucho ms amplias puesto que
incluyen a menudo, adems de las funciones mencionadas anteriormente, la
asistencia en el diseo del software, la gestin automatizada de las especificaciones y de la documentacin, la generacin del software a partir de las especificaciones, etc.
Los TIS se relacionan a menudo con un mtodo de desarrollo, principalmente el MERISE. Sin embargo, nos daremos cuenta que, si bien el TIS del
Desarrollo y mantenimiento del software

55

maana ser con certeza una herramienta totalmente integrada que dar una
asistencia al conjunto de las etapas del proceso de desarrollo de la aplicacin, esto todava est muy lejos de ser el caso de la mayora de los TIS disponibles en el mercado, de los cuales las diferentes funciones no estn siempre del todo integradas las unas con las otras.
De todas formas, el auditor no podr, en ningn caso, contentarse con
considerar la presencia de un TIS como un punto fuerte y su ausencia como
un punto dbil. En efecto, un TIS mal utilizado puede ser totalmente ineficaz, cuando algunas herramientas de desarrollo escogidas con acierto pueden ser suficientes para una excelente productividad del servicio.
Despus de enumerar los mtodos y herramientas de produccin de aplicacin, el auditor deber entonces pronunciarse sobre sus efectos en trmino
de seguridad y de eficacia del proceso.
P. Se prevn en el proceso de desarrollo de nuevas aplicaciones
las principales fases de puesta en prctica de un proyecto?
Salvo excepciones, ciertas fases deben imperativamente estar previstas
en el proceso de introduccin de nuevas aplicaciones. Las principales entre
ellas son citadas a continuacin.
La formacin de los usuarios
Una mala formacin de los usuarios tendr como consecuencia una utilizacin anrquica del sistema, con todos los riesgos que esto comporta, o
bien un desinters, incluso un rechazo, frente a ste. En ambos casos, la aplicacin est condenada a una fase de arranque, en el mejor de los casos, ciertamente agitada.
La documentacin de la aplicacin
El contenido y la calidad de la documentacin sern nombrados posteriormente (apartado 3.3).
La recuperacin de los ficheros
El arranque de una aplicacin necesita casi siempre la constitucin y la
entrada exnihilo de los ficheros necesarios para sta, o bien la recuperacin
en el nuevo sistema de los ficheros procedentes del viejo, siendo este caso,
notablemente, el ms frecuente en la actualidad (los nuevos programas sustituyen muy a menudo a una vieja aplicacin que tiene un proceso manual).
56

Tcnicas de la auditora informtica

Estas recuperaciones son con frecuencia delicadas y necesitan una participacin de los usuarios, aunque slo sea con el fin de confirmar el contenido de los ficheros recuperados.
Una mala previsin de los gastos de recuperacin es, as pues, susceptible de comprometer el arranque de la aplicacin.
El impacto del nuevo sistema en la organizacin
y en los procedimientos administrativos
Un nuevo sistema informtico va seguido, en la mayora de los casos, de
una reflexin sobre la organizacin del trabajo, y sobre la aplicacin de nuevos procedimientos.
En ausencia de una reflexin de este tipo, es previsible que los procedimientos administrativos sean mal adaptados al sistema de informacin y no
permitan sacar el mejor partido del mismo.
La implantacin fsica de los equipos
La reflexin sobre el tema permite prever, entre otras cosas:
La implantacin de la o de las unidades centrales (en un sistema bastante
descentralizado, encontraremos una unidad central por emplazamiento).
El nmero y la localizacin geogrfica de los terminales, pantallas e impresoras.
La validacin del software
Dos mtodos complementarios conducen a la validacin del software (se
habla, a menudo, de receta) antes de su puesta en explotacin.
Los juegos de prueba, que permiten simular casos reales. Despus de
los juegos de prueba, diseados y realizados por los informticos, que
permitirn asegurarse de que los programas estn de acuerdo con los
pliegos de condiciones, es indispensable prever los juegos de prueba
para usuarios, los cuales darn validez a la adecuacin de la aplicacin a
las necesidades y sern, en definitiva, el ltimo control antes del arranque.
La explotacin doble, que consiste en hacer funcionar simultneamente
el software nuevo y el viejo con el fin de comparar los resultados.
Esta ltima tcnica es muy eficaz puesto que la aplicacin sustituye los
programas que tienen funciones similares. No obstante, es engorrosa ya que
Desarrollo y mantenimiento del software

57

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 mtodo de validacin del software escogido, el
auditor comprobar que los usuarios hayan sido partcipes y que hayan tenido la posibilidad de probar las aplicaciones puestas en explotacin.
La seguridad
Si bien la seguridad del sistema de informacin es primordial en la fase
de explotacin, un primer acercamiento en ciertos mbitos es deseable a partir del diseo. 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 explotacin, controles de bases de datos, etc;
el respeto por la aplicacin de ciertos principios de control interno: control jerrquico, separacin de funciones, continuidad de la va de revisin, etc.;
los procedimientos de explotacin: recuperacin en caso de incidente,
copias de seguridad, emplazamiento de emergencia, etc.
Volveremos ms 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
ms rpidamente posible los riesgos de desaciertos en trminos de planificacin y de costes.
Varios programas de seguimiento de proyecto se encuentran actualmente
disponibles para grandes sistemas o, con ms 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.
58

Tcnicas de la auditora informtica

P. Son los proyectos objeto de una coordinacin suficiente?


Por lo general, el carisma del o de los responsables del proyecto es un
factor primordial del xito del mismo. Para los proyectos ms importantes,
la coordinacin del mismo debe estar formalizada a travs de reuniones peridicas (por ejemplo: semanales) de los principales responsables.
En realidad, distinguiremos, para cada proyecto cuya envergadura lo justifique:
La coordinacin entre los equipos de diseo, y posteriormente entre
los equipos de realizacin
Si la amplitud del proyecto justifica una distribucin de tareas entre varios equipos, es deseable una coordinacin peridica, por ejemplo, a travs
de una reunin semanal de los grupos de trabajo, a falta de la cual los diferentes subproyectos estaran poco integrados entre s, adems que algunas
funciones habran sido omitidas o tratadas doblemente.
Adems, se deben prevenir las fases regulares de validacin de los documentos producidos.
La coordinacin 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 informtico, tales como: recuperacin, organizacin,
formacin, etc. Una coordinacin general entre estas tareas es indispensable,
aunque sea slo por evitar que algunas de ellas se tornen crticas en trminos de plazo.
La coordinacin entre los informticos y los usuarios
Ya hemos subrayado la importancia de la formacin de los usuarios. Generalmente, es necesario prever una informacin regular de stos, incluso de
los que no participan en el diseo 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
Desarrollo y mantenimiento del software

59

equipo de desarrollo o del servicio informtico), 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 atencin especial?
Esta atencin especial se traducir de diferentes maneras:
Una formacin terica y prctica
Esta formacin ser, naturalmente, ms o menos intensiva segn el nivel
de experiencia del colaborador. Siendo una verdadera iniciacin para un
principiante, se limitar a una formacin en los mtodos de la casa para
un marco definido.
La formacin terica ser completada de forma til por una formacin
ms prctica, bajo formas diversas, a saber: padrinazgo de los recin llegados, 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 mquina. Desgraciadamente, en ausencia de un seguimiento eficaz, slo 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 sistemtico de los primeros programas escritos por
cada nuevo programador permite reducir este riesgo y corregir la puntera
inmediatamente.
P. Es satisfactoria la calidad de los programas producidos por el
estudio?
Por ms formalizados que sean, los mtodos y las normas de desarrollo
y de programacin no pueden constituir una garanta 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 inters en llevar a cabo un control, por sondeo, de la calidad y del respeto a las normas en algunos programas.

60

Tcnicas de la auditora informtica

3.3 LA DOCUMENTACIN
P. Es satisfactoria la calidad de la documentacin producida?
Distinguimos en la documentacin de una aplicacin informtica:
La documentacin de estudio, destinada a los equipos de desarrollo y de
mantenimiento.
La documentacin de explotacin, destinada al personal de produccin.
La documentacin destinada a los usuarios.
La documentacin de estudio contiene entre otras cosas:
La descripcin del contenido de los ficheros.
La descripcin de las cadenas de proceso.
La descripcin detallada de los programas.
El historial de las operaciones de mantenimiento.
La documentacin de explotacin contiene el conjunto de las informaciones y consignas necesarias al personal de produccin:
Descripcin y organigrama de las cadenas de proceso.
Instrucciones para la preparacin.
Descripcin de los controles de la explotacin a ser llevados a cabo en el
momento de cada proceso.
Instrucciones sobre la consola.
La documentacin para usuarios contiene:
La descripcin general de las aplicaciones.
La descripcin de las transacciones.
La descripcin de los listados editados.
La explicacin de los mensajes de anomalas.

Para el auditor, adems de la calidad y de la cantidad de la documentacin, tendr importancia la flexibilidad de utilizacin de la misma. Por
lo tanto, una documentacin controlada por soporte magntico, con la
ayuda de un programa previsto para esta finalidad, facilitar en gran medida la puesta al da y permitir la salvaguarda en un emplazamiento externo.
De un modo general, el auditor igualmente se preocupar de asegurarse
de que la documentacin est al da. Por ms completa que sea, sta se torna,
de hecho, rpidamente inutilizable si no se reflejan en ella de forma inmediata las operaciones de mantenimiento.
Desarrollo y mantenimiento del software

61

La ausencia de la actualizacin regular de los dossieres es tanto ms lamentable cuanto que hace caducar en algunos meses el pesado trabajo inicial
de construccin de los mismos.
Ms 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 documentacin.

3.4 EL MANTENIMIENTO
P. Qu procedimientos de mantenimiento de software se formalizan?
Las peticiones de mantenimiento de los programas deben ser formalizadas y ser objeto de una peticin escrita por parte de los servicios de usuarios,
visada por el correspondiente interesado y pasada al responsable de estudio.
ste, despus 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 explotacin.
En caso de urgencia, y en particular si la operacin tiene por finalidad la
correccin de una anomala de diseo de los programas, podr ser perfectamente derogada la exigencia de una peticin por escrito. De todos modos,
incluso en este caso, el servicio informtico redactar una ficha describiendo
la modificacin aportada a los programas.
Adems, de una forma general, el conjunto de fichas de mantenimiento
relativas a una aplicacin son archivadas en el dossier de sta.

3.5 LOS PROCEDIMIENTOS DE PUESTA EN


EXPLOTACIN DEL SOFTWARE
Este tema, que toca a la vez el entorno de estudio y el de explotacin, se
abordar en el prximo captulo.

62

Tcnicas de la auditora informtica

Captulo 4

El entorno
de produccin

4.1 LOS PROCEDIMIENTOS DE PUESTA


EN EXPLOTACIN
P. Son satisfactorios los procedimientos de puesta en explotacin
del software?
Antes de imaginar un procedimiento ideal de puesta en explotacin de
los programas, conviene definir los principales objetivos de un buen control
interno en este campo.
El procedimiento de puesta en explotacin debe garantizar una
buena separacin entre las funciones de estudio y las de explotacin
Concretamente, el personal de estudio no debe tener acceso a las bibliotecas de programas de explotacin, como tampoco a los ficheros de explotacin. Este objetivo, adems, tiene como propsito ms bien prevenir los riesgos de error de manipulacin que los riesgos de operaciones fraudulentas
por parte del personal de estudio.
El procedimiento de puesta en explotacin debe, en todo momento,
garantizar que estn disponibles en las bibliotecas los programas
fuente correspondientes a los programas objeto en explotacin
Atencin!: el programa fuente es el programa escrito por el informtico en un lenguaje evolucionado y comprensible por el ser humano, el proEl entorno de produccin

63

grama objeto es el lenguaje compilado, o sea, transformado en cdigo binario directamente ejecutable por la mquina. El lenguaje objeto, casi ilegible por el ser humano, se conserva en mquina:
Por un lado, el programa fuente, en una biblioteca de programas fuente,
que ser modificada, despus compilada, en caso de operacin de mantenimiento de aplicacin.
Por otro, el programa objeto, listo para ejecucin, en una biblioteca de
programas objeto; en realidad, y ms precisamente, algunos programas
objeto deben ser conectados los unos a los otros antes de ejecutarlos. Se
trata de la fase de edicin relacionada (linkedit) que transforma los mdulos objeto en mdulos ejecutables (load-modules).
En ausencia de programas fuente, o bien en presencia de programas
fuente no compatibles con los programas objeto en ejecucin, el mantenimiento de la aplicacin ser imposible a corto plazo.
El procedimiento de puesta en explotacin debe permitir conservar el
historial de traslado de programas en el entorno de explotacin
Este historial permitir entre otras cosas:
Elaborar estadsticas tales como: puestas en explotacin por programa,
cantidad de mantenimientos por programa y por aplicacin, etc.
Efectuar bsquedas, 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 penltima
versin de todo programa en explotacin, con el fin de facilitar una vuelta
atrs en caso de anomalas de proceso en la ltima versin.
*

Aclarados estos objetivos, veremos a continuacin, extrados de la obra


Les techniques de l'organisation informatique, las grandes lneas de un procedimiento de puesta en explotacin ideal.
El equipo de desarrollo trabaja en un entorno de prueba y utiliza para este
fin la biblioteca de programas de comprobacin, en particular una biblioteca
de programas fuente (que llamaremos BIB.TEST.FUENTE) y una biblioteca de programas objeto, compilados (que llamaremos BIB.TEST.OBJETO).
64

Tcnicas de la auditora informtica

En el entorno de explotacin 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 explotacin, que llamaremos BIB.EXPL.FUENTE.
El procedimiento de puesta en explotacin de un programa PGM, esquematizado en la figura 2, ser el siguiente:
a) El programa fuente se transfiere del entorno de prueba al de explotacin,
bajo control del personal de explotacin.
b) El programa fuente es recompilado en el entorno de explotacin.

Figura 2. Procedimiento de puesta en explotacin.


El entorno de produccin

65

Eventualmente, el programa fuente y el programa objeto pueden ser destruidos en el entorno de prueba. En el caso de operaciones de mantenimiento
posteriores, el programa de comprobacin ser devuelto del entorno de explotacin al de prueba. Entonces, despus de la realizacin y comprobacin
de las modificaciones del software, el programa fuente corregido ser transferido y recompilado en el entorno de explotacin.
Adems, la versin precedente ser generalmente conservada de manera
que se disponga, para cada programa, de la ltima y de la penltima versin
de los mdulos fuente y objeto.
Tratndose de la aplicacin prctica de este procedimiento, se pueden suponer las modalidades siguientes:
El responsable de la aplicacin prepara su peticin en un fichero de peticiones de traslado.
Peridicamente, el responsable de los traslados revisa el fichero de peticiones y procede a la ejecucin de estos traslados.
Un fichero histrico de traslados se actualiza. Si fuere necesario se podr
saber de este modo el plazo de las puestas en explotacin por programa,
por aplicacin, por peticionario, por orden cronolgico, o segn cualquier otro criterio.

4.2 LOS PROCEDIMIENTOS DE TOMA


DE DATOS
Recordemos a continuacin 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 tambin asegurada por las perforadoras verificadoras en los talleres de toma de datos especializados en esta
funcin; los talleres de entrada de datos estn, hoy da, en vas de desaparicin, pero todava se justifican en algunos casos particulares.
En tiempo real, es decir, con actualizacin inmediata de los ficheros. La
entrada est tambin 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 sern recogidos, segn sea el caso,
por los mismos vendedores, por sus secretarias (por ejemplo, cada da
despus de la centralizacin de los pedidos del da), o tambin por un
servicio de administracin de ventas. De la misma forma, en un establecimiento financiero, las operaciones en el mercado sern registradas,
66

Tcnicas de la auditora informtica

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 introduccin.
La doble introduccin (nicamente en el caso de introducciones masivas
en tiempo diferido).
La existencia de claves de control para los cdigos numricos. Los errores de introduccin del cdigo tambin sern rechazados inmediatamente.
El control por totalizacin de los lotes de introduccin, 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 cdigos introducidos.
Los controles de compatibilidad (ejemplo: control de compatibilidad del
da, del mes y del ao en la introduccin de una fecha); en algunos casos,
la introduccin 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 introduccin comprueba que C = A + B].
La visualizacin para validacin desde la introduccin del texto correspondiente (slo en caso de introduccin interactiva) al cdigo introducido: por ejemplo, en el momento del registro de una factura de proveedor, el nombre del proveedor se fija a partir del cdigo de proveedor
registrado.
La edicin para anlisis eventual de la lista exhaustiva de los datos registrados y, si fuere el caso, de una lista por exclusin de los datos ms significativos.
* * *

El entorno de produccin

67

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

4.3 LA EJECUCIN DE LOS PROCESOS EN TIEMPO


DIFERIDO
P. La ejecucin de trabajos en tiempo diferido es objeto de una
planificacin?
La planificacin de la ejecucin de los procesos es un principio bsico de
una organizacin racional. En su ausencia, el ordenador se puede encontrar
saturado en ciertos perodos (de donde surgen los retrasos en la distribucin
de los resultados) y bloqueado en otros.
Adems, una planificacin sistemtica permite comprobar con facilidad
que slo los procesos planificados y autorizados hayan sido ejecutados.
Los programas de asistencia a la planificacin y al ordenamiento de los
trabajos estn disponibles hoy da en el mercado (principalmente, para
los ms completos, pertenecientes a los grandes sistemas) y gracias a los
cuales:
Todo proceso ejecutado sin planificacin, o bien se rechaza, o bien se
pone en evidencia para ser controlado.
Los inconvenientes del encadenamiento de trabajos son puestos en parmetros, 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
ms frecuencia, a los responsables de aplicacin), poner parmetros durante el da a los trabajos que sern ejecutados por la noche bajo control
nico de los teclistas.
68

Tcnicas de la auditora informtica

P. Se asume de manera satisfactoria la Juncin de preparacin


de los trabajos?
Citemos, como principales caractersticas de una organizacin que cumpla la funcin de preparacin de los trabajos:
La calidad de la documentacin destinada a los responsables de la
preparacin: la calidad de la documentacin es, por supuesto, la condicin
sine qua non de la calidad del trabajo de preparacin por parte de los responsables de la aplicacin.
El carcter de intercambiabilidad de los responsables de aplicacin: si bien no es deseable que cada responsable de aplicacin asuma a
veces la responsabilidad de la preparacin del conjunto de las cadenas de
proceso (lo que conducira a una dispersin muy grande), es necesario por lo
menos, que varios responsables sean capaces de asegurar la preparacin 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 explotacin
eficaces reducen muchsimo los riesgos de errores de explotacin al limitar
al mnimo estricto el nmero de parmetros a ser modificados en el momento de cada explotacin.
Los JCL, por lo general, son modificados por los responsables de aplicacin en el momento de la puesta en explotacin de una nueva cadena de proceso, con la preocupacin de optimizar las actuaciones de explotacin, que
no siempre tienen los equipos de desarrollo.
Adems, las herramientas de automatizacin de la explotacin (generacin automtica de los JCL, gestin de recuperacin, gestin de las generaciones sucesivas de un mismo fichero, gestin de las copias de seguridad,
etc.) participan de forma notable en la reduccin del nmero de los parmetros de explotacin.
P. Las cadenas de proceso son sistemticamente objeto de controles a posteriori?
Podemos distinguir entre los controles de una cadena de proceso:
Los controles sobre la coherencia tcnica de la explotacin.
Los controles sobre la coherencia funcional de la explotacin.

El entorno de produccin

69

Los controles sobre la coherencia tcnica


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 anlisis de los mensajes y los indicadores de fin de proceso).
A la coherencia de los listados editados.
Un buen nmero de estos controles pueden, adems, ser informatizados
en gran medida, ya sea por la creacin de codificadores numricos automticos, o bien por la utilizacin 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 explotacin
Si bien es absolutamente deseable que estos controles sean llevados a
cabo por el servicio informtico, en la prctica, hace varios aos, hay una
tendencia a transferir la responsabilidad a los servicios destinatarios.
La razn principal radica en la imposibilidad ante la cual se encuentran
los servicios informticos para definir y realizar los controles funcionales
pertinentes.
Lo cual no quiere decir que estos controles de coherencia funcional revistan una importancia primordial.
P. Estn claramente definidas las modalidades de recuperacin
de la explotacin de la cadena en caso de incidente?
La principal preocupacin 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 explotacin y donde la definicin de
las modalidades de recuperacin tampoco es de su incumbencia.
En los grandes centros de proceso, los sistemas de explotacin permiten,
por lo general, la total automatizacin de los procedimientos de recuperacin consecutivos en la mayora de los incidentes. Cuando una recuperacin
automtica se hace imposible, es preferible, salvo en casos de urgencia,
abandonar el proceso y esperar la decisin del responsable de la produccin
de la aplicacin (es decir, diferir la decisin hasta la maana siguiente para
los turnos de noche).
Para los sistemas pequeos, a menudo, no se contempla una automatizacin total de las recuperaciones. Para las situaciones de urgencia, y en el
70

Tcnicas de la auditora informtica

caso de ausencia del responsable de aplicacin, estar previsto proporcionar


al teclista un manual de explotacin que describa exactamente el procedimiento de recuperacin a seguir.

4.4 EL CONTROL DE SUPERVISIN DEL ENTORNO


DE PRODUCCIN
* P. Existen herramientas de control y de asistencia destinadas a
los teclistas?
Si bien en los grandes centros los teclistas trabajan sistemticamente en
equipo, no ocurre siempre lo mismo en los pequeos. En algunos casos, los
trabajos no urgentes son iniciados y ejecutados por la noche en ausencia de
cualquier presencia humana (a excepcin, si es posible, de los guardias de
seguridad o bomberos). En caso de incidente, los trabajos se interrumpen y
se vuelven a iniciar la maana siguiente.
Adems, en los grandes centros hay cada vez ms herramientas de control y asistencia al trabajo de los teclistas: prohibicin de transmitir ciertos
pedidos, respuestas automticas al ordenador, etc.
Esta automatizacin permite enfocar la actividad de los teclistas hacia tareas ms delicadas, en particular el tratamiento de algunos tipos de incidentes. Correlativamente, la automatizacin es acompaada siempre en los
grandes centros de una centralizacin de funciones de tecleado, con la creacin de equipos que tengan la responsabilidad simultnea de varias unidades
centrales.

4.5 EL CONTROL DE LA CALIDAD,


DE LA PRODUCCIN INFORMTICA
P. Hay un seguimiento de la calidad de las prestaciones
suministradas ?
Este seguimiento asume formas variadas:
Disponibilidad de la mquina y de la red.
Tiempo de respuesta de las aplicaciones interactivas.
Frecuencia de incidentes por software.
El entorno de produccin

71

Frecuencia de retrasos en la distribucin de los listados, y retraso medio


constatado.
Cantidad de operaciones de mantenimiento por aplicacin.
Etctera.

P. Existe un seguimiento destinado a optimizar las actuaciones


del sistema informtico?
Este seguimiento asume tambin 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 aplicacin.
Seguimiento de la utilizacin de la red.
Etctera.

P. Se edita y archiva sistemticamente el diario de a bordo


del (de los) ordenador(es)?
Recordamos que este diario de a bordo (printlog) describe en una forma
ms o menos detallada (parametrable), el historial de las rdenes dadas al
sistema de explotacin y los mensajes recibidos de ste.
Cada mensaje viene de esta manera a alimentar un fichero, que podr
ser utilizado con fines de bsqueda despus de cualquier incidente de explotacin.
El auditor comprobar en particular:
que el tamao del fichero permita contener el historial de los mensajes
durante un perodo suficientemente largo (que comprenda de uno a varios das);
que el diario de a bordo sea objeto de salidas en papel, archivadas
igualmente durante un perodo que sea suficientemente largo (algunos
meses).
Una recomendacin, 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.

72

Tcnicas de la auditora informtica

4.6 LA GESTIN DEL ESPACIO EN DISCO


P. Se realiza regularmente un anlisis del contenido de los discos
para suprimir ficheros intiles?
La proliferacin en el espacio del disco de ficheros totalmente intiles
constituye un sndrome comn a casi todos los centros de proceso.
Es, por lo tanto, indispensable que se lleven a la prctica procedimientos
que permitan reconocer estos ficheros intiles. Citemos por ejemplo:
El censo peridico con los jefes de proyecto y los responsables de produccin de aplicacin de todos los ficheros operativos.
La eliminacin automtica de los ficheros cuyo nombre no respeta una
estructura definida previamente.
Los programas de gestin automatizada del espacio en disco permiten en
particular luchar contra esta proliferacin de ficheros intiles.
* P. La implantacin de los ficheros en los discos es objeto de una
optimizacin?
En efecto, una optimizacin de la implantacin fsica 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 GESTIN DE LAS BIBLIOTECAS DE PROGRAMAS


Ya hemos mencionado, por medio de los procedimientos de puesta en explotacin (apartado 4.1), la gestin de las bibliotecas de programas. Nos limitaremos a mencionar aqu algunos objetivos de una gestin sana:
Conservar en las bibliotecas slo los programas efectivamente utilizados.
Tener la seguridad de que estn disponibles en las bibliotecas todos los
programas fuentes correspondientes a los programas objetivo utilizados.
Dar al personal de estudio y de produccin un mximo de procedimientos automatizados de gestin de las bibliotecas (puesta en explotacin,
El entorno de produccin

73

traslado de un programa del entorno de produccin al entorno de prueba, etc.).


Prohibir al personal no autorizado la entrada a las bibliotecas.

4.8 LA GESTIN DE LAS COPIAS DE SEGURIDAD


Nota previa: el soporte fsico de la copia de seguridad no tiene ninguna
incidencia particular en la poltica 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 fcilmente comprensible, las modalidades prcticas son a menudo bastante diferentes de un emplazamiento a otro. As, esto se debe a que stas dependen del tamao del
centro, de los volmenes de informacin a salvaguardar y de los sistemas de
explotacin propuestos por el fabricante.
Cualesquiera que sean los procedimientos a aplicar, el auditor se encargar de comprobar que stos satisfagan los objetivos bsicos de una buena
poltica 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
elctrico, o incluso por un fallo de software).
Permitir corregir un fallo en un soporte fsico (ejemplo: un incidente en
un disco lo hace ilegible y obliga a su sustitucin fsica, adems de la recarga de su contenido a partir de una copia de seguridad).
Permitir arrancar de nuevo en un emplazamiento exterior en caso de destruccin total del emplazamiento de produccin.
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 explotacin?
Imperativamente deben ser salvaguardados:
El software bsico.
Los ficheros y software de aplicacin del entorno de explotacin.
Los ficheros y software de aplicacin del entorno de estudio.
La diversidad de los tipos de incidentes que las copias de seguridad de74

Tcnicas de la auditora informtica

ben poder paliar tiene como consecuencia la necesidad de combinar diferentes mtodos de salvaguarda.
De este modo, asociamos, por lo general, las copias de seguridad totales
de los soportes fsicos (copia total de cada volumen de disco), destinadas a
responder ante una destruccin 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 ms localizadas, como por ejemplo: recuperacin de una cadena de
proceso, recarga de una biblioteca, etc.
Adems, tratndose de copias selectivas de los ficheros y de las bibliotecas, los sistemas de explotacin proponen la mayora de las veces, con el fin
de reducir la duracin de esta operacin, una funcin 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 travs de diferentes ejemplos de una mala
poltica de salvaguarda.
Los ficheros y bibliotecas se salvaguardan totalmente una vez por
mes, y, dentro del perodo, todas las modificaciones son incluidas en
el historial
Esta poltica es mala pues, para los ficheros y bibliotecas que se modifican a menudo, la reconstruccin de la situacin en el momento de un fallo
(en particular cuando ste surge justo antes de una salvaguarda total) ser excesivamente larga.
Todas las copias de seguridad se realizan por medio de un soporte fsico y no hay ninguna copia selectiva de los ficheros
En esta hiptesis, en el caso de un incidente en una aplicacin dada, la reconstruccin de uno o varios ficheros ser algunas veces larga, ya que necesita la recarga previa de un disco completo.
Slo hay copias de seguridad selectivas de ficheros y de bibliotecas y
ninguna copia total por medio de soporte fsico
Es aqu donde, en caso de necesidad de reconstruccin de un soporte fEl entorno de produccin

75

sico (despus de la destruccin de ste o despus de la destruccin total del


emplazamiento), la carga de trabajo ser considerable.
P. Cundo el acervo lo justifica, hay un software de gestin de
cintas (o de cartuchos)?
La gestin del acervo de cintas (o de cartuchos) magnticos no supone
ningn problema especial en los pequeos centros de proceso. Las cintas son
poco numerosas, y adems estn marcadas y clasificadas con la finalidad de
salvaguardarlas. Una gestin 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 numrica de las cintas, su naturaleza y su localizacin geogrfica de almacenamiento.
El programa debe asegurar entre otras cosas:
La gestin de los lugares de almacenamiento, segn un parmetro inicial
(por ejemplo, para todo fichero, la versin V se encontrar en el emplazamiento y ser transferida a un emplazamiento externo transformndose en la versin V-l, tornndose la vieja versin V-l sin inters).
La banalizacin de las cintas que contienen los ficheros intiles.
El control de acceso a las cintas que contengan ficheros activos (y la
prohibicin de cualquier modificacin de stas).
El auditor podr en primer lugar comprobar por sondeo:
que toda cinta indicada en el programa est bien colocada en el sitio geogrfico de almacenamiento previsto (y, si fuere el caso, que el nombre y la
versin del fichero contenido en la cinta sean exactamente los indicados);
que toda cinta presente fsicamente est bien marcada en el programa.
P. Responde la gestin de las copias de seguridad a las
obligaciones en materia de archivo?
En el cuadro siguiente, se incluye una copia del artculo 97-1 de la Ley de
Finanzas Francesa para 1982 y del artculo 103 de la Ley de Finanzas para
1990. Estas disposiciones implican para la empresa la obligacin de conservar durante el perodo fiscal no prescrito una copia de las informaciones,
datos o procesos que concurran directa o indirectamente en la formacin
de los resultados contables y fiscales del perodo verificado o en la prepara76

Tcnicas de la auditora informtica

cin de los documentos o declaraciones considerados obligatorios por la


normativa fiscal.
No obstante, dejaremos que cada auditor se preocupe de definir caso por
caso cules podran 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 perodo no prescrito. Por
tanto, el campo es amplio.

ALGUNAS DISPOSICIONES FISCALES EN MATERIA


DE COPIAS DE SEGURIDAD EN FRANCIA
El artculo 97-1 de la Ley de Finanzas para 1982, que completa el artculo 54 del Cdigo General de los Impuestos, es aplicable a las empresas
afectadas por el rgimen de beneficio real.
Cuando la contabilidad est establecida por medio de sistemas informatizados, el control se extiende a la documentacin relativa a los anlisis, a la programacin y a la ejecucin de los procesos. Con el fin de comprobar la fabilidad 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 sern definidas por decreto
El decreto ir 82-1142 del 29 de diciembre de 1982 precisa las condiciones de realizacin de los controles.
Art. 1- Cuando las comprobaciones de control previstas por el artculo
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 intervencin se fijan de forma que sean compatibles con el funcionamiento normal del sistema informtico de la empresa y con el ejercicio del derecho de control de la administracin.
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
informtico suministrado por la empresa y respondiendo a las normas que sern fijadas por decreto.
Art. 2.- Las comprobaciones previstas en el artculo 1Q llevan en las informaciones, datos y procesos automticos de cualquier tipo a partir del momento en que estas informaciones, datos o procesos concurren directa o indirectamente en la formacin de los resultados contables y fiscales del perodo
verificado o en la confeccin de los documentos o de las declaraciones consideradas obligatorias por el Cdigo General de los Impuestos. Estas informaciones estn protegidas por el secreto fiscal.
Art. 3.- Las comprobaciones y los trabajos de copia previstos en el artculo 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
automticos los servicios de un detallista o de un suministrador externo, tenEl entorno de produccin

77

dr la obligacin de permitir a los agentes de hacienda llevar a cabo en el domicilio del detallista o del suministrador externo las comprobaciones que estimen necesarias para el ejercicio del derecho de verificacin. Estas comprobaciones se llevan a cabo en las condiciones definidas en el artculo 1 del presente decreto, incluso en lo que concierne a la posibilidad para los suministradores o detallistas de suministrar copias de las informaciones y del software.
El artculo 103 de la Ley de Finanzas para 1990 modifica el artculo L
13 del libro de los procedimientos fiscales.
Art. 103 - Texto del artculo. - I. El artculo 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
informticos que concurren directa o indirectamente en la formacin de los
resultados contables o fiscales y en la elaboracin de las declaraciones consideradas obligatorias por el CGI as como sobre la documentacin relativa a los
anlisis, a la programacin y a la ejecucin de los procesos.
II. El artculo L 82 del LPF est abolido.
III. Va insertado despus del artculo L 102 A del LPF un artculo 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 comunicacin y de control de la administracin deben ser conservados durante un perodo de seis aos a contar de la fecha de la ltima operacin 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 apoyados o recibidos en soporte informtico, deben ser conservados bajo esta forma durante un perodo por lo menos igual al plazo previsto en el artculo L 169.
Las piezas justificativas de origen relativas a las operaciones que dan derecho a una reduccin en materia de impuestos sobre la cifra de negocio se
conservan durante el plazo previsto en el apartado primero.
Cuando no estn previstos en los apartados precedentes, las informaciones,
datos o procesos sometidos al control previsto en el apartado segundo del artculo L 13 deben ser conservados en soporte informtico hasta el agotamiento
del plazo previsto en el artculo L 169. La documentacin relativa a los anlisis,
a la programacin y a la ejecucin de los procesos debe ser conservada hasta haberse cumplido el tercer ao despus del que corresponde la misma.
IV. Le sigue al artculo L 47 del LPF un artculo L 47 A redactado como
sigue:
Art. L 47 A: cuando la contabilidad se lleva por sistemas informatizados, los agentes de la administracin fiscal pueden efectuar la verificacin sobre el equipo utilizado por el contribuyente.
Este puede solicitar para efectuar l mismo todos o parte de los procesos
informticos necesarios para la verificacin. En este caso, la administracin
aclara por escrito al contribuvente o a un representante designado a este efec78

Tcnicas de la auditora informtica

to, los trabajos a ser realizados y el plazo acordado para llevarlos a cabo.
El contribuyente puede igualmente solicitar que el control no sea efectuado sobre el material de la empresa. Pone entonces a disposicin de la administracin las copias de los documentos, datos y procesos sometidos a un
control.
Estas copias sern hechas en un soporte informtico suministrado por la
empresa, respondiendo a las normas fijadas por decreto.
Al contribuyente se le informa de los nombres y direcciones administrativas 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 administracin no deben
ser reproducidas por esta ltima y deben ser restituidas al contribuyente antes del cobro.
V. Va insertado despus del primer prrafo del artculo L 57 del LPF, un
prrafo redactado as:
En caso de aplicacin de las disposiciones del artculo L 47 A, la administracin aclara al contribuyente la naturaleza de los procesos llevados a cabo.
VI. El artculo L 74 del LPF se completa con el siguiente prrafo:
Estas disposiciones se aplican en caso de oposicin a la aplicacin del control en las condiciones previstas en el artculo L 47 A.
VII. El prrafo tercero del artculo 54 del CGI est abolido.

P. Se llevan a cabo copias de seguridad en emplazamientos


externos?
Un da, durante una auditora, yo mismo insista ante un responsable de
informtica que guardaba el conjunto de sus copias de seguridad en una caja
fuerte ignfuga: Pero, qu hara Vd. en caso de riesgo de destruccin de su
armario, por ejemplo en caso de explosin violenta?. Este responsable informtico, un tcnico 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 mquinas para recuperar todas
las cintas de la caja fuerte!.
Una gran mayora de los responsables informticos reconocern 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 destruccin del
emplazamiento de produccin.
El entorno de produccin

79

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 das, 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 das en el registro
de datos no ser en s ms 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 RECUPERACIN 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 nocin 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 das 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 vaca, equipada con anterioridad para las telecomunicaciones 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 comn de un emplazamiento de urgencia entre varias empresas.
Y por ltimo, la solucin que est en auge, la existencia dentro de la empresa 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 aplicacin de procedimientos deteriorados.
No olvidemos por ltimo que, en nuestros das, un plan de recuperacin
serio implica que haya sido previsto cuidadosamente el back-up de la red de
telecomunicaciones.

80

Tcnicas de la auditora informtica

P. Cuando la recuperacin en un emplazamiento externo implica


la aplicacin de procedimientos deteriorados, han sido
definidos stos?
Es muy extrao 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 prioritarios, es decir, los procedimientos de funcionamiento en modo deteriorado.
P. Los procedimientos de recuperacin en un emplazamiento
externo son comprobados con regularidad?
Slo el test tamao natural de las recuperaciones detectar las imperfecciones del procedimiento terico: memoria central insuficiente, ficheros
no salvaguardados, usuarios no conectados, etc.

4.10 LA SEGURIDAD FSICA


Slo citaremos aqu las caractersticas esenciales del control de la seguridad fsica del centro de proceso, que es objeto de largos desarrollos en la literatura.
P. Est protegido el acceso fsico al entorno informtico?
En los grandes centros de proceso, la sala en la cual estn situadas las
unidades centrales, discos y otros equipamientos sensibles, est libre de toda
presencia humana. Por lo dems, el acceso a los espacios de trabajo de los
equipos de produccin (teclistas, operadores, responsables de produccin de
aplicacin, jefes de salas, etc.) est estrictamente reglamentada.
Incluso en los pequeos centros, el acceso a la sala de mquinas debe estar protegido. Los sistemas de autorizacin ms difundidos en el momento
actual son el cdigo digital y el distintivo (que permite, si se diera el caso,
conservar un fichero histrico de las entradas).
En algunas empresas, la localizacin de la sala de mquinas y su disposicin (planta, ventanas, paredes, etc.) tienen en cuenta los riesgos de motines,
de conflictos sociales, o de cualquier intrusin fraudulenta por medios violentos. Si fuera el caso, la implantacin geogrfica del emplazamiento de urgencia se mantendr en secreto.

El entorno de produccin

81

P. Est controlado el acceso fsico al lugar de almacenamiento


de las cintas (o cartuchos) magnticas?
Es conocido por parte de los auditores que un buen nmero de robos de
informacin han podido tener lugar dentro de los entornos de alta seguridad,
debido a que las cintas magnticas, soportes de ficheros sensibles, estaban
almacenadas sin proteccin.
Por tanto, es deseable que los soportes magnticos de almacenamiento
estn agrupados en un mismo emplazamiento (con excepcin de las copias
de seguridad externas) cuyo acceso ser estrictamente reglamentado.
P. Los locales estn protegidos contra incendio?
Distinguiremos:
Los dispositivos de deteccin, generalmente basados en la deteccin del
humo.
Los dispositivos de extincin; como ejemplos se pueden citar el gas haln, el gas carbnico, el agua (utilizacin 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 ms eficaz que un procedimiento de extincin automtica (hemos
visto algunas veces dispararse inesperadamente aspersores y verter grandes
masas de agua en la sala de las mquinas, daando gravemente los equipos y
las copias de seguridad magnticas!).
P. Los locales estn protegidos contra los daos por agua?
Incluso en el mismo Pars, puede ser peligroso instalar una sala de mquinas en el stano, por ejemplo si ste est situado en los mrgenes del
Sena.
P. Est el centro informtico protegido contra los fallos de fluido
elctrico?
El sistema de alimentacin ininterrumpida (SAI) permite, a un coste razonable, protegerse contra los cortes de alimentacin de corta duracin.
Tambin lo encontramos en la mayora de los centros.
Para los cortes de larga duracin, por ejemplo en caso de huelga, slo el
grupo electrgeno puede suministrar la electricidad necesaria. Igualmente,
teniendo en cuenta su coste, slo ser implantado cuando, ms all de las ne82

Tcnicas de la auditora informtica

cesidades puramente informticas, la prosecucin de la actividad de la empresa lo justifique.

P. Se ha previsto un sistema de deteccin de las intrusiones?


Diferentes sistemas permiten detectar las eventuales intrusiones despus
de la salida del personal informtico. 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 destruccin de los equipos.
La reconstruccin de los ficheros perdidos.
Las prdidas de explotacin a consecuencia de la falta de disponibilidad
de los equipos.
Las prdidas financieras a consecuencia de actos malintencionados o
fraudulentos.
No obstante, tendr el cuidado de no recomendar sistemticamente la suscripcin de las plizas ms completas. La falta de evaluacin de los riesgos
incurridos constituye un error de gestin; en cambio, si los riesgos han sido
evaluados, la decisin de asegurarlos o no constituye una decisin de gestin de la incumbencia de la Direccin 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 informticos pueden ser clasificados en:
Los contratos a todo riesgo informtico (TRI) que cubren, segn la garanta, todos o parte de los riesgos relativos a los sucesos accidentales.
Los contratos de extensin a los riesgos informticos (ERI), que cubren,
segn las garantas, total o parcialmente los daos relacionados con una
utilizacin no autorizada de los sistemas informticos (actos fraudulentos
o mal intencionados).
Los contratos de tipo informtico global que acumulan las coberturas
relacionadas con los dos tipos de riesgos precedentes.
El entorno de produccin

83

4.12 LAS OBLIGACIONES LEGALES DE


DECLARACIN
P. Est la empresa suscrita al conjunto de las declaraciones
obligatorias?
Citemos a ttulo de ilustracin:
Las obligaciones relativas a la ley informtica y libertades que asegura
la proteccin de los datos nominativos (vase recuadro).
Las obligaciones relativas a la transmisin de los datos cifrados en las redes (decreto n 86/250 del 18 de febrero de 1986).
Las obligaciones relativas a la utilizacin de las redes con valor aadido,
o sea, las redes telemticas 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 disposicin del pblico o de categoras de pblico por un procedimiento de telecomunicacin, de signos, de
seales, de escritos, de imgenes, de sonidos o de mensajes de todo tipo
que no tengan el carcter de correspondencia privada (ley ne 86/1067 del
30 de septiembre de 1986 relativa a la libertad de comunicacin, decreto ns
87-277 del 17 de abril de 1987 y circular del 17 de febrero de 1988).

La ley informtica y libertades de Francia del 6 de enero de 1978


Esta ley tiene como objetivo la proteccin del individuo frente a las
informaciones nominativas controladas por cadenas de proceso automatizado.
Con este propsito:
el captulo 2 de la ley instituye la creacin de una Comisin Nacional de la
Informtica y Libertad (CNIL);
el captulo 3 impone que todo proceso automatizado que contenga informaciones nominativas sea objeto de una declaracin previa en la Comisin;
el captulo 4 aclara las condiciones en las cuales las informaciones nominativas pueden ser recogidas y conservadas;
el captulo 5 es relativo al derecho de acceso de cada individuo a los datos
nominativos que le conciernen;
el captulo 6 aclara las sanciones aplicables en caso de falta de respeto a las
disposiciones precedentes.
A continuacin veremos algunos extractos de esta ley.

84

Tcnicas de la auditora informtica

Captulo III
Formalidades previas a la aplicacin de procesos automatizados
Art. 14. - La Comisin Nacional de la Informtica y de las Libertades vela por que los procesos automatizados de informaciones nominativas, pblicos
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 pblico o de una colectividad territorial, o de una persona fsica de derecho privado que dirige un servicio pblico, son decididos por un acto reglamentario llevado a cabo despus del conforme del Consejo de Estado.
Cuando el aviso de la Comisin no es notificado al cabo de un plazo de dos
meses, renovable una sola vez por decisin del presidente, se entiende como
favorable.
Art. 16. - Los procesos de informaciones nominativas automatizados llevados a cabo por cuenta de personas que no estn autorizadas por las disposiciones del artculo 15, deben ser objeto de una declaracin de la Comisin
Nacional de la Informtica y de las Libertades previa a su aplicacin.
Esta declaracin 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 Comisin, el peticionario puede aplicar el proceso. No est exonerado de ninguna de sus responsabilidades.
Art. 17. - Para las categoras ms corrientes de procesos de carcter pblico o privado, que no comporten manifiestamente ningn atentado a la vida
privada o a las libertades, la Comisin Nacional de la Informtica y de las Libertades establece y publica las normas simplificadas inspiradas en las caractersticas mencionadas en el artculo 19.
Para los procesos que respondan a estas normas, slo una declaracin simplificada de conformidad con una de estas normas es depositada ante la Comisin.
Salvo decisin en particular de sta, el comprobante de la declaracin se entrega
inmediatamente. A partir de la recepcin de este comprobante, el peticionario
puede aplicar el proceso. No est exonerado de ninguna de sus responsabilidades.
Captulo 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 pblico en aplicacin del artculo 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 comunicacin.
Art. 35. - El titular del derecho de acceso puede obtener comunicacin de
las informaciones que se refieran a l. La comunicacin, en lenguaje claro, debe ser conforme al contenido de los registros.

El entorno de produccin

85

Las normas y deliberaciones de la CNIL han aportado adems aclaraciones en cuanto a la aplicacin de esta ley. De este modo, estn sujetos a declaracin simplificada los procesos relativos a la remuneracin y a la gestin de
ficheros de clientes y de proveedores. La contabilidad general est exonerada
de cualquier declaracin.
Por ltimo, conviene remarcar que, en la prctica, la Ley Informtica y
Libertad est lejos de ser aplicada de forma universal y que la falta de declaracin casi nunca ha sido sancionada.
Por fortuna, la evolucin hacia las aplicaciones microinformticas no se
hace para facilitar las eventuales investigaciones en estos campos.

A continuacin se incluye la legislacin vigente en Espaa sobre el tratamiento o proceso de datos.


Ley informtica
Regulacin del tratamiento automatizado de los datos de
carcter personal (Espaa)
Ley 5/1992 de 20 de octubre
Esta ley tiene como objeto limitar el uso de la informtica y otras tcnicas
y medios de tratamiento automatizado de los datos de carcter personal para
garantizar el honor, la intimidad personal y familiar de las personas fsicas y
pleno ejercicio de sus derechos.
Se estructura en los siguientes siete ttulos principales:
TITULO I, Disposiciones Generales, en el que se recogen los preceptos delimitadores del mbito de aplicacin de la Ley y las definiciones de datos de carcter personal, fichero automatizado, tratamiento de datos, responsable de
fichero, afectado y procedimiento de asociacin.
TITULO II, Principios de la proteccin de datos, en el cual se desarrollan los
principios generales que definen las pautas a las que debe atenerse la recogida de datos de carcter personal. Estas pautas tienen como finalidad garantizar tanto la veracidad de la informacin contenida en los datos almacenados
como la congruencia y la racionalidad de la utilizacin de los datos.
TTULO III, Derechos de las personas, que configura jurdicamente las garantas de las personas derechos de informacin, de acceso de los datos y de
rectificacin y cancelacin, entre otros como derechos subjetivos encaminados a hacer operativos los principios genricos del Ttulo II. Los derechos
de acceso a los datos y de rectificacin y cancelacin son las piezas centrales
del sistema cautelar o preventivo instaurado por la Ley.

86

Tcnicas de la auditora informtica

TTULO IV, Disposiciones sectoriales, en el que se distingue entre los distintos tipos de ficheros, segn sea su titularidad pblica o privada.
TITULO V, Movimiento internacional de datos, que regula los posibles efectos
perniciosos asociados con la transmisin internacional de datos de carcter
personal.
TTULO VI, Agencia de Proteccin de Datos, por el cual se establece la creacin de un rgano independiente, al que se atribuye el estatuto de Ente pblico, para el control de la aplicacin de Ley con objeto de asegurar la mxima
eficacia de sus aplicaciones.
TTULO VII, Infracciones y sanciones, en el que la Ley se limita a tipificar, de
acuerdo con la prctica usual, unos supuestos genricos de responsabilidad
administrativa, con arreglo a una gradacin de infracciones que sigue la distincin habitual de leves, graves y muy graves.
A continuacin, veremos algunos extractos de esta Ley:
TTULO I. Disposiciones generales
Artculo 1. Objeto
La presente Ley Orgnica, en desarrollo de lo previsto en el apartado 4 del artculo 18 de la Constitucin, tiene por objeto limitar el uso de la informtica y
otras tcnicas y medios de tratamiento automatizado de los datos de carcter
personal para garantizar el honor, la intimidad personal y familiar de las personas fsicas y el pleno ejercicio de sus derechos.
Artculo 2. mbito de aplicacin
1. La presente Ley ser de aplicacin a los datos de carcter personal que figuren en ficheros automatizados de los sectores pblico y privado y a toda
modalidad de uso posterior, incluso no automatizada, de datos de carcter
personal registrados en soporte fsico susceptible de tratamiento automatizado.
TTULO II. Principios de la proteccin de los datos
Artculo 4. Calidad de los datos
1. Slo se podrn recoger datos de carcter personal para su tratamiento automatizado, as como someterlos a dicho tratamiento, cuando tales datos
sean adecuados, pertinentes y no excesivos en relacin con el mbito y las
finalidades legtimas para las que se hayan obtenido.
2. Los datos de carcter personal objeto de tratamiento automatizado no podrn usarse para finalidades distintas de aquellas para las que los datos
hubieran sido recogidos.
5. Los datos de carcter personal sern cancelados cuando hayan dejado de
ser necesarios o pertinentes para la finalidad para la cual hubieran sido recabados y registrados.
6. Sern almacenados de forma que permitan el ejercicio del derecho de acceso por parte del afectado.

El entorno de produccin

87

Artculo 5. Derecho de informacin en la recogida de datos


1. Los afectados a los que se soliciten datos personales debern ser previamente informados de modo expreso, preciso e inequvoco:
a) De la existencia de un fichero automatizado de datos de carcter personal, de la finalidad de la recogida de stos y de los destinatarios de la informacin.
b) Del carcter obligatorio o facultativo de su respuesta a las preguntas
que les sean planteadas.
c) De las consecuencias de la obtencin de los datos o de la negativa a suministrarlos.
d) De la posibilidad de ejercitar los derechos de acceso, rectificacin y
cancelacin.
e) De la identidad y direccin del responsable del fichero.
Artculo 11. Cesin de datos
1. Los datos de carcter personal objeto del tratamiento automatizado slo
podrn ser cedidos para el cumplimiento de fines directamente relacionados con las funciones legtimas del cedente y del cesionario con el previo
consentimiento del afectado.
TITULO III. Derechos de las personas
Artculo 13. Derecho de informacin
Cualquier persona podr conocer, recabando a tal fin la informacin oportuna del Registro General de Proteccin de Datos, la existencia de ficheros automatizados de datos de carcter personal, sus finalidades y la identidad del
responsable del fichero. El Registro General ser de consulta pblica y gratuita.
Artculo 14. Derecho de acceso
1. El afectado tendr derecho a solicitar y obtener informacin de sus datos
de carcter personal incluidos en los ficheros automatizados.
Artculo 15. Derecho de rectificacin y cancelacin
1. Por va reglamentaria se establecer el plazo en que el responsable del fichero tendr la obligacin de hacer efectivo el derecho de rectificacin o
cancelacin del afectado.
2. Los datos de carcter personal que resulten inexactos o incompletos sern
rectificados y cancelados en su caso.
3. Si los datos rectificados o cancelados hubieran sido cedidos previamente,
el responsable del fichero deber notificar la rectificacin o cancelacin
efectuada al cesionario.
TTULO VI. Agencia de Proteccin de Datos
Artculo 34. Naturaleza y rgimen jurdico
1. Se crea la Agencia de Proteccin de Datos.
2. La Agencia de Proteccin de Datos es un Ente de Derecho Pblico, con
personalidad jurdica propia y plena capacidad pblica y privada, que acta con plena independencia de las Administraciones Pblicas en el ejercicio de sus funciones.
88

Tcnicas de la auditora informtica

Artculo 36. Funciones


Son funciones de la Agencia de Proteccin de Datos:
a) Velar por el cumplimiento de la legislacin sobre proteccin de datos y
controlar su aplicacin, en especial en lo relativo a los derechos de informacin, acceso, rectificacin y cancelacin de datos.
b) Emitir las autorizaciones previstas en la Ley o en sus disposiciones reglamentarias.
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 informacin a las personas acerca de sus derechos en materia de tratamiento automatizado de los datos de carcter personal.
f) Ordenar la cesacin de los tratamientos de datos de carcter personal y la
cancelacin de los ficheros, cuando no se ajusten a las disposiciones de la
presente Ley.
g) Ejercer la potestad sancionadora en los trminos previstos por el ttulo
VII de la presente Ley.
h) Informar, con carcter preceptivo, los proyectos de disposiciones generales que desarrollen esta Ley.
i) Recabar de los responsables de los ficheros cuanta ayuda e informacin
estime necesaria para el desempeo de sus funciones.
j) Velar por la publicidad de la existencia de los ficheros automatizados de
datos con carcter personal, a cuyo efecto publicar peridicamente una
relacin de dichos ficheros con la informacin adicional que el Director de
la Agencia determine.

El entorno de produccin

89

Captulo 5

Las funciones
de asistencia tcnica

Cada vez ms se han desarrollado durante la ltima dcada las funciones


de control o de asistencia tcnica:

definicin de normas y mtodos,


gestin de las bases de datos,
infocentro,
microinformtica,
gestin de redes,
gestin de la seguridad.

En los grandes centros de procesado, algunas veces, estas funciones estn


agrupadas en el seno de una direccin tcnica. stos son los puntos clave de la
auditora de estas diferentes funciones que sern estudiados en este captulo.

5.1 LAS BASES DE DATOS


La generalizacin de la utilizacin de los sistemas de gestin de bases de
datos (SGBD) en el desarrollo de aplicaciones ha llevado a la creacin de
funciones y de tareas nuevas.
Veremos, adems, que la mayora de los controles descritos a continuacin se imponen igualmente en el caso de programas diseados en torno a
sistemas de gestin de ficheros tradicionales y que la presencia de SGBD
slo sirve para aumentar su necesidad.
90

Tcnicas de la auditora informtica

P. Hay un administrador de datos?


El administrador de datos tiene como papel la gestin de los datos de la
empresa (en las PYME) o, en el caso de las aplicaciones importantes, la gestin de los datos de la aplicacin.
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 nocin de administrador de datos, responsable de los datos de la empresa, de la de administrador de base de datos, responsable de la implantacin fsica de las bases de
datos, de su optimizacin y de su coherencia tcnica (ver a continuacin). La
administracin de la base de datos es una funcin de sistema, mientras que
la administracin de datos es ms bien una funcin de estudio.
P. Se utiliza un diccionario de datos?
El diccionario de datos es un programa que facilita la gestin de los
datos por parte del administrador y su utilizacin por parte de los equipos de
desarrollo.
P. Se procede a tareas de bsqueda de optimizacin 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. Segn
se optimicen o no los mtodos de acceso, las actuaciones de un mismo programa pueden variar en proporciones bastante considerables. La ausencia total de optimizacin conducir en algunos casos a tiempos de respuesta de las
aplicaciones interactivas, o a tiempos de ejecucin de las tareas en tiempo
diferido, totalmente inaceptables. Esta constatacin, adems, slo sirve para
reforzar el recurso cada vez ms frecuente a los SGBD conocidos como relacinales.
La optimizacin 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 tcnica de las bases de datos,
la coherencia funcional de los datos.
Las funciones de asistencia tcnica

91

Coherencia tcnica
La tcnica de las bases de datos, en cualquier tipo de arquitectura (jerrquica, en red o relacional) implica la presencia de apuntadores y de un ndice, que aseguren la relacin 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 tcnica del contenido de la base,
conduciendo a la prdida de algunos datos.
Coherencia funcional
Si bien es posible controlar la coherencia de los datos en el momento de
su introduccin, este control no excluye una degradacin posterior de stos,
por razones diversas (error en un programa a tiempo diferido, modificacin
de los datos no controlados, incidente mquina, etc.).
Es, por lo tanto, deseable que las normas de integridad y de coherencia de
los datos puedan ser incluidas en la definicin 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 GESTIN DE REDES


P. Existe una clula tcnica de gestin de redes?
En los entornos gran sistema, la aplicacin de una red necesita la eleccin de programas coherentes los unos con los otros, para luego proceder a
su implantacin y su parametraje.
La eleccin de las redes (TRANSPAC, TRANSCOM, TRANSFIX, etc.)
necesita estudios tcnicos y econmicos.
Por lo general, esta funcin es atribuida a una clula tcnica agregada al
equipo de sistema.
Adems de la existencia misma del equipo de red, el auditor controlar
su actividad:
justificacin tcnica y econmica de las elecciones,
comprobacin de las nuevas configuraciones,
back-up entre los ingenieros de sistemas, etc.

92

Tcnicas de la auditora informtica

P. Existe una clula de asistencia de red?


Contrariamente a la clula tcnica precedente, sta tiene esencialmente
un papel de asistencia a los usuarios:

instalacin de nuevos puestos de trabajo,


primeros auxilios por telfono en caso de problema,
mantenimiento, si ste no est confiado a empresas especializadas,
gestin de algunas mesas.

En verdad se trata de una funcin de tipo SVP, que debe estar disponible a toda hora para dar respuesta a las necesidades de los usuarios.
P. Estn controlados los accesos a la red?
La existencia de una red implica riesgos adicionales de acceso no autorizado, por diferentes razones:
El nmero de terminales conectados al ordenador central aumenta constantemente y stos pueden encontrarse en posiciones geogrficas muy
alejadas.
Si bien en la mayora de las aplicaciones la lista de terminales fsicamente autorizados a estar conectados al sistema central se establece de
forma limitativa, es cada vez ms frecuente que por razones de flexibilidad de utilizacin los terminales no identificados fsicamente sean autorizados a acceder a la red: esto se da, sobre todo, cuando se aplican los
procedimientos de mantenimiento a distancia.
La gestin de redes combina, la mayora de las veces, la utilizacin de lneas privadas (lneas alquiladas) y de redes pblicas (red telefnica conmutada, TRANSPAC), donde los datos que circulan se mezclan con los
de las dems empresas.
Por ltimo, algunas aplicaciones informticas estn destinadas, por naturaleza, a un acceso pblico: 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 mtodos de control de acceso sern estudiados en el captulo 6.
P. Se han previsto tcnicas de salvaguarda y recuperacin
especiales para la utilizacin de la aplicacin
en procesamiento a distancia?
Las tcnicas de salvaguarda diaria de los ficheros (por lo general, durante
Las funciones de asistencia tcnica

93

el proceso nocturno) se encuentran con una gran limitacin en el caso de las


aplicaciones interactivas: la actualizacin permanente de los ficheros o una
copia de seguridad en la vspera o durante la noche, implica introducir otra
vez todos los movimientos del da, en el caso de un incidente y de necesidad
de recuperar a partir de la copia de seguridad.
Adems, esta molestia es aceptable en algunos casos a condicin de que,
por lo menos, los usuarios obren en consecuencia. En el caso contrario, se
deben aplicar tcnicas especficas.
La ms frecuente y la ms vieja consiste en el registro peridico (logging) de las transacciones. Cada puesta al da de ficheros da lugar a la creacin de movimientos en un fichero-diario, descargado regularmente en cinta
o cartucho. En caso de fallo, la nueva aplicacin de los movimientos del da
en la copia de seguridad en la vspera o por la noche permitir reconstruir la
situacin de los ficheros en el momento del incidente.
Ms exactamente, el contenido del fichero diario podr variar de un entorno al otro. En algunos casos, contendr las propias transacciones de actualizacin, en otros contendr la imagen de los registros de fichero modificados antes y despus de la puesta al da.
Una tcnica ms reciente consiste en crear para los ficheros puestos al da
en tiempo real ficheros imagen en un disco distinto de aquel que contiene
los ficheros originales, y puesto al da al mismo tiempo que stos. De este
modo, en caso de fallo en el disco que contenga el fichero original, ser posible proseguir la aplicacin, casi de inmediato, partiendo del disco imagen.
El principal inconveniente de estas tcnicas de registro peridico y disco
imagen, que explica adems que no sean utilizadas en ciertos emplazamientos (esencialmente las PYME), reside en el coste. La creacin del fichero diario multiplica las operaciones de entradas-salidas (I/O) y requiere tambin configuraciones de equipamiento ms importantes. La
tcnica de los ficheros imagen es an ms onerosa, debido a que necesita
una duplicacin de los volmenes en disco, que hacen los soportes magnticos costosos.
Veremos, por ltimo, que la tcnica del registro peridico se podra extender en los prximos aos 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 captulo anterior, hemos enfocado esencialmente los procesos de
recuperacin a consecuencia de una indisponibilidad de la unidad central.
94

Tcnicas de la auditora informtica

Pero existe otro riesgo propio de las redes, que es: la indisponibilidad de un
soporte de transmisin de datos. Es el caso bien conocido, por ejemplo, de la
lnea alquilada no disponible durante algunos das debido a que se encuentra
fsicamente 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:
Duplicacin de una lnea especializada por medio de un abono a TRANSPAC, 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 conexin entre los usuarios y el emplazamiento
central.
La utilizacin de conexiones TRANSFIX, que permiten sus propias soluciones de urgencia.

5.3 LA MICROINFORMATICA
P. Estn coordinadas la adquisicin y la utilizacin de
microordenadores ?
Las propuestas de los auditores no deben acabar en una centralizacin
abusiva de la poltica microinformtica, que sera mal entendida y marchara
en sentido contrario a la historia.
Una poltica de eleccin y de compra descentralizada en los servicios es
aceptable a condicin de ser eficazmente enmarcada.
Por tanto, el auditor se asegurar de que estn coordinadas al nivel de la
Direccin informtica:
La eleccin de los equipos aceptados en la empresa, con vistas a ofrecer una diversidad de material suficientemente difundida.
La eleccin de las aplicaciones de ofimtica aceptadas: proceso de
texto, hojas de clculo, software grfico, software integrado, gestores de
ficheros, etc.
La eleccin de proveedores y la negociacin de las condiciones comerciales.
1. Nos acordaremos igualmente de la parada durante varios das del nudo TRANSPAC de Lyon, en los
primeros aos de funcionamiento de esta red.

Las funciones de asistencia tcnica

95

Las modalidades del mantenimiento de los equipos y de los programas.


La definicin de la poltica en materia de infocentro, y las modalidades
de transferencia de datos entre unidad central y microordenadores.
Es evidente que la falta total de coordinacin, que encontramos en algunas empresas, no debe darse en ningn caso ya que la misma conduce de
forma rpida a una situacin completamente anrquica. Esta falta de coordinacin es, por lo general, el resultado de un abandono de la Direccin Informtica ante las fuertes presiones "autonomistas" de los servicios en materia
de ofimtica. Adems, a menudo, son tambin la consecuencia de las fuertes
reticencias que se manifestaban en este mbito en el seno de los servicios informticos hace algunos aos.
P. Se pone cuidado para que la microinformtica no se
transforme en el soporte de un desarrollo anrquico
de aplicaciones autnomas y heterogneas?
Si bien la microinformtica actualmente es un soporte fiable y eficaz
para procesar el conjunto de las necesidades de la empresa en materia de ofimtica, su utilizacin en calidad de soporte del desarrollo de aplicaciones de
gestin, cuando no est sistemticamente prohibida, debe, por lo menos, ser
estudiada cuidadosamente.
Cantidad de programas de gestin presupuestaria, de gestin del inmovilizado, de gestin de existencias, de contabilidad general, desarrollados por principiantes con simples hojas de clculo o gestores de ficheros,
son verdaderos peligros para el director de empresa. Redactados en pocos
das, puestos en explotacin sin verdaderas comprobaciones, estos programas raramente ofrecen los controles suficientes en el momento de la
entrada de los datos (que, adems, a menudo debe ser realizada doblemente, teniendo en cuenta la falta de coordinacin 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 satisfaccin a los usuarios, descargando los servicios informticos atascados.
En definitiva, el auditor comprobar:
que la utilizacin de la microinformtica con la finalidad de desarrollo
de aplicaciones sea conocida por el servicio informtico y controlada por
ste (los programas sern, si es posible, desarrollados por el servicio informtico);
96

Tcnicas de la auditora informtica

que las aplicaciones desarrolladas en estas condiciones estn documentadas correctamente y presenten las mismas garantas en materia de seguridad que las aplicaciones desarrolladas en gran sistema:
control de datos introducidos,
procedimientos de copia de seguridad y de recuperacin,
control de entrada,
etctera.
P. Est controlado el acceso a las aplicaciones o a los datos
sensibles gestionados por microordenador?
Las tcnicas habituales de proteccin de acceso a los ficheros, a las bibliotecas de programas y a las aplicaciones pueden llegar a ser aplicadas en
un entorno microinformtico.
Conviene, no obstante, reconocer que stas estn todava demasiado
poco difundidas incluso cuando se procesan aplicaciones sensibles en microordenadores.
Cul es la proporcin de puestos de trabajo en los cuales las posibilidades de control de acceso por contrasea han sido efectivamente utilizadas?
Si bien hace algunos aos los microordenadores eran particularmente permeables, la negligencia es an ms palpable cuando, algunos de ellos ofrecen actualmente posibilidades de control de acceso anlogas a las de los
grandes sistemas.
Adems, y excepto cuando los microordenadores estn conectados en redes, las mejores protecciones son en la actualidad las protecciones fsicas tales como el bloqueo por medio de llave o tarjeta magntica, o simplemente
cierre a llave de los despachos y armarios.
P. Se toman las medidas especficas 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 ms importante que el propio microordenador. Algunos componentes anexos son susceptibles de ser robados,
tales como: el software, varias tarjetas de extensin, etc.
Entre las medidas preventivas, podemos citar:
El control de las entradas y salidas de la empresa.
La identificacin precisa de las inmovilizaciones y del inventario fsico
regular del conjunto del parque.
Las funciones de asistencia tcnica

97

P. La empresa no incurre en ninguna sancin penal por la


implantacin de programas sin licencia de utilizacin?
Muchas grandes empresas han tenido, hasta nuestros das, una actitud
poco ejemplar en este campo ya sea por una poltica 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 implantacin en algunos
micros de este organismo de software desprecintado, mas all de la ancdota, es del todo significativo.
Ahora bien, el no respeto a la reglamentacin 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 artstica (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 ilcito en los microordenadores deben estar previstos.

Ley del 3 de julio de 1985 relativa a la proteccin


intelectual y artstica (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 artstica. Encontraremos
a continuacin las disposiciones del ttulo V, relativas al software.
Ttulo V
De los programas informticos
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 aplicacin del presente artculo est sometido al
tribunal supremo del lugar de residencia del empleador.
Las disposiciones del primer prrafo del presente artculo son igualmente
aplicables a los agentes del estado, de las colectividades pblicas y de los establecimientos pblicos de carcter administrativo.
Art. 46 - Salvo cuando se estipule lo contrario, el autor no puede oponerse a la adaptacin del software dentro de los lmites de los derechos que ha cedido, ni tampoco de ejercer su derecho de arrepentimiento o de retractarse.
Art. 47 - Por derogacin del 2B del artculo 41 de la ley n 57-298 del 11 de
marzo de 1957 anteriormente citada, toda reproduccin aparte del estableci2. Instituto Nacional de la Propiedad Industrial.
98

Tcnicas de la auditora informtica

miento de una copia de seguridad por parte del usuario y toda utilizacin 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 ttulo se extinguen al vencimiento de un perodo de veinticinco aos contados a partir de la fecha de la
creacin del software.
Art. 49 - El precio de cesin de los derechos de utilizacin 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 polica puede ser asistido
por un experto designado por el demandante.
A falta de designacin o de citacin en la quincena del embargo, el embargo incorrecto es nulo.
Adems, los comisarios de polica tienen la obligacin 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 ttulo, con la condicin 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 proteccin 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 falsificacin puede estar penada por una prisin de
tres meses a dos aos y/o una multa de 6.000 a 120.000 F.
Pero aqu tambin, el nmero de registros fraudulentos es irrisorio en
comparacin con el nmero de copias ilcitas de programas en circulacin, incluso en las empresas ms grandes.

A continuacin en el siguiente recuadro aparece un extracto de la legislacin vigente actual en Espaa sobre derechos de autor en los programas.
Ley de propiedad intelectual. Normas Reguladoras (Espaa)
LEY 22/1987 de 11 de noviembre
Entre sus disposiciones reguladoras para la proteccin de los derechos de
propiedad intelectual, esta Ley recoge tambin, en su Ttulo VII, la proteccin
de los derechos de autor derivados de la creacin de los programas de ordenador.
Las funciones de asistencia tcnica

99

TTULO VII. De los programas de ordenador


Artculo 95
El derecho de autor sobre los programas de ordenador se regir por los
preceptos del presente ttulo y, en lo que no est especficamente previsto en el
mismo, por las disposiciones que resulten aplicables de la presente Ley.
Artculo 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 informtico para realizar una funcin o una tarea o para obtener un resultado determinado, cualquiera que
fuere su forma de expresin y fijacin.
2. La documentacin tcnica y los manuales de uso de un programa gozarn de
la misma proteccin que este ttulo dispensa a los programas de ordenador.
3. Los programas de ordenador que formen parte de una patente o un modelo de utilidad gozarn, sin perjuicio de lo dispuesto en la presente Ley, de
la proteccin que pudiera corresponderles por aplicacin del rgimen jurdico de la propiedad industrial.
4. La proteccin establecida en la presente Ley se extiende a cualesquiera
versiones sucesivas del programa, as como a los programas derivados.
Artculo 97
La duracin de los derechos de explotacin de un programa ser de cincuenta aos, contados desde el 1 de enero del ao siguiente al de su publicacin, o al de su creacin si no se hubiera publicado.
Artculo 98
El autor, salvo pacto en contrario, no podr oponerse a que el cesionario
titular de derechos de explotacin realice o autorice la realizacin de versiones sucesivas de su programa ni de programas derivados del mismo.
Artculo 99
1. Se entiende por cesin del derecho de uso aquel acto en virtud del cual el titular del derecho de explotacin 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 cesin del derecho de uso
es de carcter no exclusivo e intransferible, presumindose asimismo que
lo es para satisfacer nicamente las necesidades del usuario.
2. La reproduccin del programa, incluso para uso personal, exigir la autorizacin del titular del derecho de explotacin, con excepcin de la copia
de seguridad.
3. No constituye reproduccin, a los efectos previstos en el artculo 18 de esta Ley, la introduccin del programa en memoria interna a los solos efectos
de su utilizacin por el usuario, sin perjuicio de su necesaria comunicacin
al titular del derecho de explotacin cuando as se hubiere pactado.
4. No constituye transformacin, a los efectos previstos en el artculo 21, la
adaptacin de un programa realizada por el usuario para la utilizacin exclusiva por el mismo.

100

Tcnicas de la auditora informtica

Artculo 100
Los derechos sobre los programas de ordenador, as como sobre sus sucesivas versiones y los programas derivados, podrn ser objeto de inscripcin en
el Registro de la Propiedad Intelectual.
Reglamentariamente se determinarn aquellos elementos de los programas registrados que sern susceptibles de consulta pblica.

P. Se ejecutan regularmente programas de deteccin 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 daos.

5.4 LOS MTODOS


P. Hay en la empresa una funcin de responsable de
mtodos?
El responsable de mtodos, si es posible, tendr a su cargo la definicin
del conjunto de las normas propias de la actividad informtica, ya sean relacionadas con los procedimientos de desarrollo y de programacin o con los
procedimientos de puesta en explotacin y de produccin.
P. Las normas son objeto de una difusin sistemtica al conjunto
de los colaboradores involucrados?
Por supuesto, los procedimientos de actualizacin peridicos deben estar
previstos.
P. Efecta regularmente el responsable de mtodos los controles
con vistas a la aplicacin efectiva de las normas?
En ausencia de cualquier control, las normas, teniendo en cuenta su
carcter obligatorio, corren el gran riesgo de caer progresivamente en el
olvido.

Las funciones de asistencia tcnica

101

5.5 EL INFOCENTRO
La idea de infocentro, o de infoservicio, corresponde a la puesta a disposicin de los usuarios de lenguajes de programacin de fcil manipulacin,
destinados a preguntas sobre las bases de datos y que permiten descargar
otro tanto a los equipos de desarrollo del servicio informtico.
P. Las herramientas de infocentro estn bien adaptadas para la
utilizacin por parte de los no informticos?
Muy a menudo, los lenguajes de programacin rpida totalmente inadaptados a una utilizacin por los no informticos por ser demasiado complejos,
son denominados abusivamente lenguajes de infocentro.
En la mejor de las hiptesis, son olvidados totalmente, o peor an engendrarn numerosos resultados errneos.
En caso de necesidad, en los centros ms grandes, se pondrn varias herramientas a disposicin de los usuarios, tales como:
lenguajes simples destinados a peticiones elementales para la mayora de
ellos,
verdaderos lenguajes de desarrollo rpido para los ms prevenidos.
P. Est controlado el acceso a las herramientas de infocentro?
El acceso a las herramientas de infocentro debe estar limitado tan slo a
los usuarios habilitados. Adems, lo que ms se autoriza es la consulta de datos, no su actualizacin.
P. No se desvan las herramientas de infocentro de su objetivo
original en provecho del desarrollo de aplicaciones pirata?
La asistencia dada por el servicio de informtica para la utilizacin del
infocentro debe servir para comprobar que ste no es desviado de su funcin
original.
De hecho, ya hemos mencionado, cuando hablamos de los microordenadores, el riesgo relacionado con una proliferacin no controlada de aplicaciones paralelas desarrolladas por los usuarios mismos.
P. Se vigilan las cargas-mquinas imputables al infocentro?
Las herramientas de infocentro son por lo general grandes consumidoras
de recursos, tanto de espacio-disco como de tiempo-mquina.
102

Tcnicas de la auditora informtica

Tambin es importante realizar seguimientos del consumo por aplicacin, por usuario y por servicio, a fin de detectar abusos eventuales.
Este problema debera desaparecer progresivamente en los prximos
aos, gracias a la utilizacin de nuevas tcnicas como:
Equipos dedicados al infocentro.
Utilizacin de microordenadores, descargando en primer lugar los datos
del emplazamiento central hacia el microordenador, y despus procesndolos otra vez en ste con la ayuda de herramientas apropiadas.

5.6 LA FUNCIN SISTEMA


P. Se ha creado en los grandes centros un entorno especfico
para los ingenieros de sistemas?
En los grandes centros de proceso, los ingenieros de sistemas tienen poderes muy amplios, por el hecho de que ellos cuentan con los programas o
software de base.
A ttulo de ancdota, los medios para eludir el RACF, software de control
de acceso en los entornos de gran sistema de IBM, son conocidos por la mayora de los ingenieros de sistemas.
El objetivo de la creacin de un entorno especfico ser permitir a los
hombres-sistema comprobar con toda serenidad las nuevas versiones de
los programas de base.
P. Si se ha elegido desarrollar algn software de base
internamente, se ha justificado debidamente esta eleccin?
Algunos grandes centros informticos, en particular en los aos setenta
y comienzos de los aos ochenta, han elegido desarrollar internamente algunos programas de base como: sistema de gestin de ficheros, sistema de
explotacin, monitor de procesamiento a distancia, etc. Esta eleccin, que
implica a veces cargas de trabajo considerables, estaba justificada por la
necesidad de procesar volmenes de informacin muy importantes con
actuaciones que no ofrecan 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 ms
complejo, incitando a los responsables de estos centros a volver a las herramientas estndares, que mientras tanto se hicieron ms tiles. No obstante,
Las funciones de asistencia tcnica

103

en este caso tambin, la conversin 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 ningn software
de base sea desarrollado en la empresa sin haber sido estudiados los programas que ofrecen funciones similares. Hoy da, el desarrollo de software especfico importante debera ser muy excepcional.
Adems, podemos preguntarnos si los mismos errores del pasado no se
pueden cometer otra vez, cuando omos hablar a los grandes grupos, por
ejemplo, que desarrollan su propio software de gestin de redes locales.

5.7 LA FUNCIN SEGURIDAD


P. Hay en la empresa una funcin de gestin de riesgos?
La seguridad informtica es de hecho un aspecto importante de las atribuciones del risk-manager.
No obstante, esta funcin slo existe por lo general en las empresas de tamao importante.
P. Hay un responsable de la seguridad en el departamento
de informtica?
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 fsica de los locales y de los equipos,


la gestin de los contratos de seguro,
los procedimientos de salvaguarda,
los procedimientos de recuperacin,
la definicin de los procedimientos de autorizacin de acceso al entorno,
la proteccin de los datos confidenciales.

Algunos aspectos metodolgicos podrn igualmente estar subordinados


a este cargo, por ejemplo, la definicin de los procedimientos de puesta en
explotacin y de control de bibliotecas, o tambin la definicin 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
104

Tcnicas de la auditora informtica

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 organizacin del servicio de informtica.
P. Hay un plan de seguridad informtica?
Este plan, actualizado regularmente, define las medidas a aplicar con el
fin de mejorar la seguridad informtica. Constituye a menudo la ltima etapa
de una auditora, o incluso de un taller de prueba del riesgo informtico del
tipo MARIN (apartado 13.4.1).

Las funciones de asistencia tcnica

105

Captulo 6

La proteccin y la
confidencialidad
de los datos

La proteccin y el control de la confidencialidad de los datos de la empresa implica la previsin 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 magntico de seguridad.
La conexin fsica con las lneas de telecomunicacin 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 tambin de modificarlos con las consecuencias catastrficas que pueden tener las manipulaciones, como: malversacin de fondos y destruccin del entorno.
106

Tcnicas de la auditora informtica

Distinguiremos en las medidas de prevencin las siguientes:


Medidas de prevencin de acceso por la identificacin del individuo recurrente.
Medidas de prevencin de acceso por la identificacin del terminal recurrente.
Medidas de prevencin de acceso a la forma de los datos y su soporte de
almacenamiento.
6.1.1 Medidas de prevencin por la identificacin
del individuo recurrente
Estudiaremos primeramente los modos de identificacin del individuo
recurrente, despus examinaremos las tcnicas de software de proteccin.
6.1.1.1 El modo de identificacin del individuo recurrente
Distinguiremos de nuevo:
la identificacin lgica por contrasea;
la identificacin por cualquier medio fsico.
a) La identificacin lgica por contrasea
La eficacia de una proteccin de acceso al entorno informtico por atribucin de cdigos de usuarios y de contraseas supone respetar algunas reglas bsicas.
P. Las contraseas se atribuyen individualmente a cada
usuario?
Las contraseas colectivas, por ejemplo por servicio o por aplicacin, raramente mantienen su confidencialidad por mucho tiempo.
P. Las contraseas deben ser modificadas regularmente?
Algunos programas dedicados al control de las protecciones de acceso
imponen que la contrasea sea modificada con regularidad por su propietario, condicin indispensable para una confidencialidad real (la obligacin de una modificacin cada trimestre parece ser una periodicidad razonable).
La proteccin y la confidencialidad de los datos

107

P. Las contraseas son suficientemente sofisticadas?


Algunas contraseas 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 creacin de la contrasea, etc. El auditor, por sondeo, proceder al control de la verdadera confidencialidad de algunas de ellas.
P. Se protege el cuadro de contraseas?
Adems de la proteccin del acceso al fichero de contraseas, el auditor
se asegurar de que ste no sea objeto de ediciones regulares.
P. Es posible detectar las tentativas de acceso no autorizadas?
La identificacin, en tiempo real o en tiempo diferido, de las tentativas de
acceso no autorizado permite detectar a tiempo operaciones fraudulentas
eventuales.
No obstante, esta identificacin no debe llevar a sospechar sistemticamente de todos los usuarios sin razn.
P. Despus de varias tentativas de acceso infructuosas,
son desconectados los usuarios?
Por lo general, se prev una desactivacin de un cdigo de usuario despus de tres tentativas de acceso con contraseas equivocadas. En caso contrario, sera fcil, con las tcnicas disponibles hoy da, programar en un microordenador un algoritmo de bsqueda de la contrasea.
* P. Se ha sensibilizado a los usuarios de los riesgos que puede
originar el prstamo de sus contraseas?
Esta pregunta vale a fortiori para las ventas de contrasea.
b) La identificacin fsica del individuo que opera
Estas tcnicas sustituyen generalmente el uso de contraseas, y no se
acumulan a ella, salvo aplicaciones de altsima seguridad.

108

Tcnicas de la auditora informtica

P. Existen sistemas de autorizacin de acceso por medio


de tarjeta magntica?
La tarjeta magntica tambin se refiere al individuo. Esta tcnica, tambin costosa, est llamada a desarrollarse en los prximos aos.
P. Existen otros sistemas de identificacin?
A ttulo de ilustracin citemos el reconocimiento vocal, la identificacin
de las huellas dactilares, del fondo de ojo. Estas tcnicas estn hoy da en
fase experimental y, por supuesto, reservadas a campos especficos de altsima seguridad (militares, etc.)

6.1.1.2 Las tcnicas de software de proteccin


a) Los principales modos de acceso a los datos
Una proteccin eficaz representa que se tiene que conocer perfectamente
el conjunto de los modos de acceso al entorno informtico. Estos modos de
acceso pueden ser clasificados en varias categoras.
El acceso a travs de una aplicacin transaccional
Para cada una de las aplicaciones procesadas en una empresa (gestin comercial, gestin de compras, contabilidad, produccin, etc.) las transacciones son puestas a disposicin de los usuarios, el acceso inicial se hace, por lo
general, a travs de mens. Segn sea el caso, las transacciones autorizan la
toma de datos, o la consulta sobre la puesta al da de los datos.
El acceso a travs del arranque de programas en tiempo diferido
Este modo de acceso est, en principio, reservado al personal informtico. Implica la posibilidad de conformar trabajos en el entorno de produccin por medio del editor. Los JCL y los programas a ejecutar son, por lo general, almacenados en las bibliotecas previamente a su ejecucin, 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 travs de herramientas de sistemas
Siempre por medio del editor, existe software bsico que permite consultar y poner al da los ficheros sin pasar por un programa o una transaccin.
La proteccin y la confidencialidad de los datos

109

Este software bsico no deja ninguna pista de las modificaciones llevadas a


cabo.
El acceso a travs de herramientas de infocentro

El infocentro pone a disposicin de los usuarios todos o parte de los ficheros de explotacin 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 auditora de las tcnicas de software de proteccin
A continuacin encontraremos un conjunto de preguntas cuya nica finalidad es responder a un objetivo ms general: el acceso al entorno informtico est limitado slo a las personas autorizadas? Las respuestas a las
preguntas siguientes, ya sean positivas o negativas, deben ser tambin interpretadas en su conjunto.
P. El acceso a las aplicaciones transaccionales est protegido
por contrasea?
El acceso a las transacciones, en principio, est prohibido al personal informtico. Cada usuario est autorizado a acceder a algunas transacciones,
definidas de forma limitada en funcin de su perfil.
P. Est prohibido a los usuarios el acceso al editor?
Una limitacin de acceso eficaz se obtiene orientando a cada usuario, a
partir de su conexin, hacia un men que contenga slo las funciones que le
estn autorizadas.
En algunos casos, la disponibilidad del infocentro implica que los usuarios tengan acceso al editor. En tal caso, se tendr en cuenta una limitacin a
las nicas funciones tiles de ste.
P. Est protegido con contrasea el arranque de programas en
tiempo diferido?
No obstante, un control de este estilo representa que la contrasea figure
claramente en el JCL. Por esta razn se puede preferir el control de acceso en
el editor. Por lo menos, el acceso a las bibliotecas que contengan el JCL deber estar protegido.
110

Tcnicas de la auditora informtica

P. Est estrictamente reglamentado el acceso al software


de sistema de actualizacin de los ficheros?
En trminos de auditora, los programas bsicos son temibles por su facilidad de utilizacin y por la falta de huellas tras cualquier manipulacin llevada a cabo.
Si bien no deben estar prohibidos totalmente (se revelan extremadamente
tiles en algunos casos), su uso debe estar reservado a un nmero extremadamente limitado de personas, y ser objeto de una formalizacin muy estricta (cualquier intervencin ser referenciada, y se indicarn los objetivos
y la naturaleza de las operaciones llevadas a cabo).
P. La utilizacin de las herramientas de infocentro impide toda
modificacin de los ficheros de produccin?
El infocentro debe excluir cualquier posibilidad de actualizacin de los
ficheros de produccin. En cambio, es del todo previsible entregar a los
usuarios una copia de todo o parte de estos ficheros para el anlisis 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 especficos en el interior de un fichero, a ciertos tipos de datos. A ttulo de ejemplo, en un fichero de personal, distinguiremos tres niveles de autorizacin: el ms amplio, para los datos administrativos, un segundo ms limitado, para el acceso a las remuneraciones, y
un tercero, todava ms reducido, para el acceso a los ficheros de cuadros
superiores y dirigentes; los sistemas de autorizacin especficos estn
previstos en algunos sistemas de gestin de base de datos.

P. Estn previstos los controles de acceso a las bibliotecas?


Las bibliotecas de programas en explotacin, fuente u objeto, sern tratados con una atencin especial.

La proteccin y la confidencialidad de los datos

111

P. Estn previstos los controles de acceso por volumen-disco fsico?


De no ser as, sera imposible reconstruir el contenido de un fichero, analizando los datos que figuran en el disco fsico en el que est implantado.
P. Los controles de contraseas estn controlados en las tablas y
no estn 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 contraseas estn incluidas en las tablas y fcilmente modificables, y no directamente incluidas
en los programas, en cuyo caso el sistema sera demasiado rgido para ser
eficaz (en efecto, en la segunda hiptesis, es muy posible que las contraseas
no seran jams modificadas).
P. El software de control de autorizacin de acceso permite
discernir entre la autorizacin de consulta de los datos
y la autorizacin de actualizacin de los mismos?
Las autorizaciones de consulta pueden estar ms ampliamente distribuidas que las de actualizacin.
Ejemplo: slo 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 nmero de programas dedicados al control de la seguridad. Estos programas tienen en comn la ventaja de controlar la proteccin del entorno independientemente
del modo de acceso.
Ilustramos esta afirmacin por medio de la figura 3. Desde un terminal,
se puede acceder a los ficheros y a las bibliotecas de programas de aplicacin a travs de diferentes programas bsicos, del sistema de explotacin
(MVS), del monitor de teleproceso (CICS), del editor (TSO) o de cualquier
programa a tiempo diferido introducido en la lista de espera.
Un primer mtodo de control de acceso consiste en integrar en algunos
de estos programas bsicos un proceso de autorizacin. De este modo, el
monitor de teleproceso CICS posee sus propias tablas de contrasea.
El inconveniente de este mtodo reside en el hecho de que cada programa
bsico slo controla los accesos que utilizan sus propios procedimientos. Por
112

Tcnicas de la auditora informtica

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 informtico no autorizado


la utilizacin 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 permitirn proteger los recursos (ficheros, bibliotecas, volmenes discos fsicos, bases de datos, transacciones, programas), independientemente del modo de acceso
utilizado. En la figura 4 se muestra una ilustracin de este mtodo.
Citemos como ejemplos de estos programas los tres ms difundidos actualmente en el gran sistema IBM:
RACF del BM;
TOP SECRET de COMPUTER ASSOCIATES
ACF2, tambin de COMPUTER ASSOCIATES, que est avocado a ser
abandonado progresivamente.
c) Los principios funcionales del control de las autorizaciones de acceso
A continuacin, volveremos sobre algunos principios fundamentales del
control de las autorizaciones de acceso.
La proteccin y la confidencialidad de los datos

113

P. Hay un responsable de autorizaciones de acceso?


Este responsable podr crear los perfiles de cada director o jefe de servicio, y les proporcionar el conjunto de las habilitaciones necesarias para el
ejercicio de sus funciones. A continuacin, 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 estn acordes con el principio de un buen


control interno?
El auditor se interesar en particular por:
El principio de separacin de las funciones.
El principio de control jerrquico.

114

Tcnicas de la auditora informtica

6.1.2 Las medidas de prevencin de acceso


por identificacin del terminal recurrente
Cada vez ms, las aplicaciones informticas 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 telemantenimiento, o sea, el mantenimiento a distancia.
La aplicacin administracin de ventas prev una conexin de los
vendedores durante sus viajes desde un microordenador porttil.
Los clientes se conectan desde puestos miniterminal para obtener informaciones comerciales.
Estos tipos de accesos son extremadamente peligrosos, pues la sola proteccin contra intrusiones externas reside en la confidencialidad de las contraseas.
En algunos casos, las tcnicas de identificacin del terminal que se conecta permite reducir notablemente el riesgo de intrusin.
P. Est previsto un procedimiento de identificacin fsica
del terminal que se conecta?
Cuando los terminales susceptibles de conectarse a la unidad central son
conocidos, es posible memorizar sus seas fsicas en una tabla. La tentativa
de acceso de cualquier otro terminal ser rechazada.
P. En la utilizacin de redes pblicas, se prevn, si esto
es posible, procedimientos de recuperacin automtica
del comunicante?
En algunas aplicaciones, se prevn procedimientos de conexin entre la
unidad central y los terminales o microordenadores a distancia a travs de
una red pblica (red conmutada, TRANSPAC, etc.). Citemos por ejemplo:
Las tiendas que se conectan cada tarde con sus centrales para teletransmitir 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.
La proteccin y la confidencialidad de los datos

115

Estos dos ejemplos tienen en comn:


El hecho de que la lista de llamadas posibles (tienda o direccin regional) est identificada.
Un riesgo de intrusin si un defraudador potencial conociera el nmero
del comunicado y simulara una llamada desde una tienda o de una direccin regional.
El procedimiento que permite prevenir este riesgo es, por tanto, el siguiente:
La lista de nmeros (telefnicos o TRANSPAC) de los comunicantes potenciales se encuentra identificada en la unidad central.
En el momento de cada llamada, el comunicante se identifica.
Despus del control, la unidad central vuelve a llamar al comunicante al
nmero de abonado conocido registrado en sus propios ficheros.
P. En el caso de la utilizacin de una red TRANSPAC, se prev,
si esto fuere posible, la utilizacin de un grupo cerrado
de abonados (GCA)?
El grupo cerrado de abonados es un servicio prestado por FRANCE TELECOM en las redes TRANSPAC que permite identificar, para una aplicacin 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 prevencin de acceso a las formas de
datos y su soporte de almacenamiento
P. Los datos ms sensibles son objeto de una codificacin?
La codificacin consiste en la transformacin, con la ayuda de un software apropiado, de los datos en un formato que les hace totalmente incomprensibles para una persona que no disponga del software.
La operacin inversa consiste en remitir los datos en su formato inicial
antes de su utilizacin para las aplicaciones.
Veremos que la tcnica de la codificacin slo puede ser totalmente eficaz cuando el acceso a los datos o, por lo menos, al software de codificacin,
est tambin reglamentado.
116

Tcnicas de la auditora informtica

P. Est previsto para algunos ficheros o programas


extremadamente sensibles que slo sean cargados
en el momento de su ejecucin?
Esta solucin, debido a lo trabajoso de su puesta en prctica, slo debe
ser considerada en casos muy excepcionales. Encontraremos a continuacin
una ilustracin concreta.
Imaginemos que una empresa desea imperativamente mantener confidenciales las remuneraciones de sus cuadros superiores, pero que, por razones prcticas, desea que sus fichas de nminas estn establecidas por los
mismos programas y en los mismos equipos que las de los dems empleados.
El acceso al fichero de personal ser, por supuesto, estrictamente reglamentado. Por precaucin complementaria, podemos imaginar que los registros que contengan los cuadros superiores sean objeto de una codificacin.
Pero una codificacin slo es eficaz cuando el software de las codificaciones
est tambin protegido.
Por ello, una solucin eficaz consiste en que el software, en vez de estar
almacenado permanentemente en los discos, sea conservado en cinta magntica (guardada en sitio seguro) y cargado en el momento de la ejecucin del
programa de nminas.
El procedimiento del proceso de la nmina ser, en este caso, el siguiente:
El responsable carga el programa de codificacin y despus ejecuta la
aplicacin.
Recupera tambin los listados de salida.
Tras la terminacin 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
MAGNTICO
Por soporte magntico, se entiende esencialmente las cintas o cartuchos
magnticos que sirven para las copias de seguridad o para las transmisiones
de datos.

La proteccin y la confidencialidad de los datos

117

P. El acceso al parque de cintas y de cartuchos magnticos est


reglamentado ?
Recordemos que gran nmero de robos de ficheros estn relacionados
con una insuficiente proteccin del acceso a los archivos de cintas.
P. Para los ficheros sensibles se evitan los procedimientos de
envos de cintas o cartuchos por mensajero ?
La mayora de los responsables informticos 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 jams 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 utilizacin no autorizada. Se incluir, por ejemplo, en el fichero el nombre y la direccin de
uno de los directores, voluntariamente mal ortografiados.
P. Estn previstos, si fuere necesario, procedimientos de
validacin de los datos contenidos en los ficheros sensibles?
El caso ms conocido es el de ficheros de remesa de nminas enviados
por las empresas a sus bancos, los cuales deben tener un registro en cabeza
de totalizacin que permita validar el contenido de la cinta enviada.
Recordaremos, a ttulo ilustrativo, que aunque este procedimiento sea,
por lo general, conocido por la poblacin informtica, ha permitido ya desenmascarar a defraudadores que haban modificado el importe de su propio
salario en el fichero de remesas, sin pensar en modificar el registro de totalizacin.
P. Existe un software que permita controlar la lectura
y la reescritura de las cintas o cartuchos magnticos?
Es de desear que estn 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,
118

Tcnicas de la auditora informtica

la lectura de ficheros almacenados en cintas por personas no autorizadas


a acceder a estos ficheros.
P. Se ha previsto un procedimiento de control especfico en el
momento de la edicin de listados sensibles?
Para evitar el riesgo de difusin de informaciones confidenciales, se prever, por ejemplo, que algunos listados sensibles sean editados en presencia
del usuario responsable de la aplicacin.
P. Se ha previsto la destruccin sistemtica despus
de la utilizacin de los listados que contengan
informaciones sensibles?
Hace algunos aos, una ESII se hizo involuntariamente bastante clebre
cuando copias de listados confidenciales destinados a uno de sus clientes
fueron substradas de sus papeleras y difundidas en el exterior.

6.3 LA CONEXIN FSICA CON LAS LINEAS EN LAS


CUALES CIRCULAN LOS DATOS
P. Se ha previsto la codificacin de las informaciones
confidenciales que circulan en las redes pblicas o privadas?
En la medida que es casi imposible controlar la ausencia de conexin no
autorizada en el conjunto de la lnea fsica (incluso en el caso de la utilizacin de la red TRANSPAC, la unin entre la empresa y el punto de entrada
ms prximo es propia de sta), la tcnica de la codificacin es el medio ms
eficaz de evitar el robo de los datos que circulan por las lneas.

La proteccin y la confidencialidad de los datos

119

Tercera parte

EL CONTROL DE LAS
APLICACIONES
INFORMATIZADAS

Hemos presentado en la primera parte de la obra los objetivos y mtodos


de control de una aplicacin informatizada.
La fiabilidad de una aplicacin pasa siempre por la fiabilidad del control
interno de la funcin informtica propia de sta. En otras palabras y ms
concretamente, el auditor podr aplicar, al entorno de desarrollo y de explotacin propios de esta aplicacin, el conjunto de los controles mencionados
en la segunda parte de la obra.
Controlar de esta forma por este sistema:
Al nivel de la organizacin 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 separacin de funciones estudio-explotacin-usuarios.
La evolucin de los procedimientos administrativos.
La calidad y la perennidad de los equipos de desarrollo, de mantenimiento y de explotacin (analistas de aplicaciones).
Las modalidades de recurso a la subcontratacin.
La eleccin de los equipos fsicos.
La existencia de auditoras recientes.

El control de las aplicaciones informatizadas

121

Al nivel de los procedimientos de desarrollo y de mantenimiento:

La metodologa aplicada.
La calidad del software.
El contenido de la documentacin.
Los procedimientos de mantenimiento.
La toma de conciencia, en el momento del desarrollo, de los problemas
de seguridad tales como: control de introduccin de datos, integridad de
los datos, continuidad de la va de revisin, etc.
Los juegos de pruebas previos a cualquier puesta en explotacin.
Al nivel de la produccin:

Los procedimientos de puesta en explotacin.


La introduccin de datos en masa.
La planificacin y el arranque de los trabajos en tiempo diferido.
Los controles de explotacin.
Los mtodos de recuperacin en caso de incidente.
Las copias de seguridad.
Las modalidades de recuperacin en unidad externa.
El control de las bibliotecas.
El respeto a las obligaciones declaratorias.
La seguridad fsica de la unidad y de los materiales dedicados a la aplica
cin.

Al nivel de la direccin tcnica:

El control de la red.
La administracin de las bases de datos.
El control de los microordenadores utilizados en la aplicacin.
El infocentro.
La toma en consideracin de las obligaciones relacionadas con la seguridad y con la proteccin de acceso a los datos.

Adems, ya hemos presentado en la primera parte de la obra (apartado


1.3.4), los principios generales de control interno relativos al diseo y a la
utilizacin de una aplicacin informatizada:
Los controles de usuarios relativos a la coherencia de los datos y procesos de la aplicacin.
Los controles jerrquicos.
La separacin de funciones.
122

Tcnicas de la auditora informtica

La continuidad de la va de revisin.
La existencia de procedimientos de autorizacin 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
explotacin.
La capacidad y la integridad del personal.
Habamos igualmente mencionado en la primera parte los diferentes enfoques prcticos de auditora de una aplicacin, por otra parte complementarios y que son:
El examen del control interno.
Los juegos de prueba.
La utilizacin de programas de auditora, que tengan por objetivo ya sea
la validacin de algunas cadenas de proceso, o bien la deteccin de anomalas en los ficheros.
El objetivo de esta tercera parte ser presentar, para cada uno de los principales programas de gestin utilizados en una empresa:
Una descripcin resumida de las modalidades habituales de funcionamiento de ste.
La presentacin de los principales puntos clave de control durante una
auditora de la aplicacin, aclarando para cada punto el tipo de riesgos
as como las modalidades prcticas del control.
Las posibilidades de utilizacin de los programas de auditora con fines
de control.
En cambio, no se han tratado, o bien son simplemente citadas a ttulo
ilustrativo, las condiciones generales propias de la existencia de un buen
control interno (confidencialidad, fiabilidad de la explotacin, documentacin, etc.) ya especificadas en la segunda parte de la obra.
Por ltimo, veremos en la cuarta y ltima parte una presentacin ms
concreta de los problemas inherentes de la implementacin de la misin:
planificacin de la intervencin, definicin de los medios de investigacin
ms apropiados, eleccin de un programa de auditora.

El control de las aplicaciones informatizadas

123

Captulo 7

La contabilidad general,
analtica y auxiliar

7.1 PRESENTACIN GENERAL DE LA APLICACIN


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 cdigo que indica si la cuenta lleva una letra1 o no (es o no marcable).
Eventualmente, el hecho de que los asientos slo puedan ser de dbito o
de crdito.
El ttulo 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 trmino letraje surgi por el hecho de que en sus orgenes los contables confrontaban los asientos con ayuda de letras.

124

Tcnicas de la auditora informtica

b) El fichero de clientes
Cuando se ha previsto una contabilidad auxiliar de clientes, el fichero
permanente de clientes suministra para cada cliente su direccin, su nombre,
una palabra gua abreviada, su forma de pago, un cdigo de relanzamiento,
etc. Adems, cuando el fichero de clientes es utilizado igualmente por una
aplicacin de gestin comercial y de facturacin, las informaciones complementarias estarn integradas: comisin acordada, importe pendiente mximo autorizado, etc.
c) El fichero de proveedores
El fichero permanente de proveedores especifica para cada uno de ellos
su nombre, su direccin, una palabra gua 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 (dbito o crdito), su
importe, su texto, su fecha de introduccin, su fecha contable.
Mencionamos, igualmente, que entre los programas:
Los ficheros de asientos de contabilidad general y auxiliar no estn de
ningn modo relacionados.
La contabilidad auxiliar da lugar a la transformacin automtica de
asientos de centralizacin en contabilidad general.
Slo 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 fsicos que contengan asientos de centralizacin. stos son reconstruidos, si fuere necesario, en el momento
de cada edicin 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
estn 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 iniLa contabilidad general, analtica y auxiliar

125

cial a principio del perodo, 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 estn pendientes de validacin definitiva.

7.1.2 Los procesos


a) La recogida y validacin de los asientos
Los asientos se recogen de forma interactiva.2 Desde su recogida, son
controlados (existencia del nmero de cuenta, igualdad debe-haber, etc.).
Despus del control de los asientos, segn los programas:
puede ocurrir que stos sean directamente incluidos en el fichero de los
asientos contables;
o bien integrados en un fichero tampn, que contiene un conjunto de tomas de datos, cuyos asientos slo sern traspasados a las cuentas despus
de una validacin definitiva del conjunto.
La segunda solucin, que presenta el inconveniente de un proceso semidiferido, es preferida a veces, en la medida en que permite modificar y suprimir asientos mientras no hayan sido validados definitivamente.
Vemos tambin que las modalidades de recogida y de controles especficos pueden estar previstas por tipo de diario, o sea:
Generacin automtica del asiento de contrapartida para las compras y
las ventas.
Limitacin 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 nmeros de los asientos marcados por este sistema.
2.0 sea, en tiempo real, desde una pantalla conectada a la unidad central.

126

Tcnicas de la auditora informtica

El mareaje automtico que proviene de un algoritmo de cotejo informatizado de los asientos.


El mareaje automtico con una letra, si bien constituye un confort para
los usuarios, no obstante, se debe manejar con precaucin teniendo en
cuenta el riesgo de mareaje abusivo.
b) Las consultas en tiempo real
stas son, por lo general, de tipo estndar:
Plan contable.
Saldo de cuentas.
Detalle de los asientos de una cuenta durante un perodo determinado.
Para las cuentas auxiliares, el sistema ofrece generalmente la eleccin
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 cdigo 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 validacin por parte de los usuarios de las operaciones recogidas por stos, o tambin el control por un superior jerrquico.
A veces, podr servir para la recuperacin de un fichero destruido por la grabacin de la ltima copia de seguridad y la recuperacin de los asientos a
partir del borrador.
Los diarios (obligatorios)
Para cada diario, tendremos cada mes el detalle por orden cronolgico de
los asientos recogidos.
La eleccin del nmero 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:
La contabilidad general, analtica y auxiliar

127

Un diario de compras.
Un diario de ventas.
Un diario de tesorera.
Un diario de imovilizaciones.
Un diario de pagos o remuneraciones.
Un diario de operaciones diversas, en el cual estn 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 cronolgico
de los asientos recogidos en la cuenta.
Es algunas veces til prever a final del ao una edicin del conjunto de
los asientos del ao.
El balance (facultativo)
A pesar de que no est incluido en los listados exigidos por el cdigo de
comercio, todos los programas contables prevn la edicin 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 especficos de la contabilidad auxiliar de clientes
Adems de los diarios, libros del mayor y balances auxiliares, se prever
por lo general la edicin:
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 incluya por cliente el detalle de los asientos no marcados;
de cartas de reclamacin para las facturas no liquidadas, con varios niveles de reclamacin;
de un balance antiguo, distribuyendo por anterioridad el saldo de los
clientes. El balance antiguo constituye un instrumento de auditora
contable indispensable;
128

Tcnicas de la auditora informtica

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 administracin.
Los listados especficos de la contabilidad auxiliar de proveedores
Adems de los diarios, los libros de mayor y balances auxiliares de proveedores, tambin, por lo general, se prev la edicin:

de efectos-cheque y pagars emitidos, segn 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 especficos del control de efectos
Para los efectos a cobrar, se tratar por ejemplo de la edicin:
de efectos en cartera, distribuidos por su vencimiento,
de listas de remesas a descuento, eventualmente despus 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 edicin de los efectos por su vencimiento,
la edicin de avisos de domiciliacin.
d) La contabilidad analtica
Slo nombraremos de forma sucinta los procesos y listados propios de la
contabilidad analtica en la medida en que este trmino cubre a veces especificaciones muy diversas de una empresa a la otra.
La contabilidad general, analtica y auxiliar

129

Por lo general, se prev la imputacin de un cdigo de contabilidad analtica en la recogida de los asientos de cargo y de producto en contabilidad general. Para algunos tipos de asientos, es adems posible generarlo automticamente. De igual forma es necesario prever la recogida de asientos
puramente analticos, o sea, que no tengan ninguna incidencia en la contabilidad general.
Segn sea el caso, habr o no creacin de un fichero especfico de asientos de contabilidad analtica.
Al final del mes, volveremos a encontrar por la cuenta analtica los listados anlogos a los de la contabilidad general, o sea:
Diarios analticos.
Mayores analticos.
Pueden ser necesarias prestaciones ms sofisticadas, como:
Afectacin con fines de control presupuestario, presupuestos de las
cuentas analticas y comparacin mensual de los presupuestos y de los
gastos.
La contabilidad conocida como de obra, siendo los resultados analticos 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 reinicializadas cada ao.

7.2 LA AUDITORIA DE LA APLICACIN


7.2.1 La auditora de las posibilidades funcionales
Auditar las funciones de un programa significa comprobar que el mismo
responde a las necesidades especficas 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.
Adems, es preferible que algunas funciones estn previstas en el diseo
del software con el nico fin de garantizar la fiabilidad.
De un modo general, aclaramos a continuacin un cierto nmero de puntos que el auditor tendr todo el inters en controlar.
a) Los ficheros permanentes
Si bien la mayora de los programas prevn un fichero de plan contable,
130

Tcnicas de la auditora informtica

algunos crean automticamente 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 atribucin a cada usuario slo de aquellas
autorizaciones que necesite.
Un control de capacidad eficaz se consigue:
Atribuyendo a cada usuario una contrasea y limitndola a algunas tareas y a algunas cuentas.
Desarrollando, si fuere el caso, transacciones especficas.
De este modo, el contable encargado de los proveedores slo 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 ttulo de ilustracin algunos controles tradicionales:
Existencia de los nmeros de cuenta en el plan contable, o sea, el ttulo
de la cuenta se agrega automticamente para el control visual.
Igualdad de los dbitos y crditos.
Sentido del asiento (cuando la cuenta ha sido marcada para recibir slo
asientos deudores o acreedores).
Cabe citar tambin, aunque sea lento, el control por totalizacin 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
totalizacin. Una diferencia revela, bien un error en el registro de un importe, o bien la omisin de registro de algunos asientos.
Este procedimiento, que haba estado ampliamente desarrollado por los
operadores en la poca de los registros masivos, no est desprovisto de inteLa contabilidad general, analtica y auxiliar

131

res en el caso de una toma inteligente por parte de los contables, por poco
que stos adopten un mtodo de registro por lotes, agrupando as todos sus
trabajos informticos en un mismo momento de la jornada.
La fecha contable
La problemtica 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 intil.
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 operacin. Por ejemplo, a principio del ao, 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 imputacin 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. Imaginemos adems que, debido al diseo de los programas de edicin, estos asientos no figuran en el diario ni en el mayor de marzo en el momento de su edicin. Resulta, por tanto, que los saldos de las cuentas han sido modificados
por asientos que no aparecern jams 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 constatacin
puede acarrear, en particular cuando este tipo de anomala se produce en repetidas ocasiones.
Cmo prevenirse contra este riesgo? La solucin elegida habitualmente
consiste en introducir en el sistema un parmetro que corresponda al mes
contable en curso. El software rechaza entonces cualquier asiento cuya fecha contable sea anterior a esta fecha parmetro. Cuando los listados contables del mes en curso son editados, la fecha parmetro se pone al da, ya sea
automticamente, o bien manualmente por los usuarios.
En el momento de estos controles, el auditor se preocupar no solamente
de la comprobacin de la existencia de esta fecha parmetro, sino tambin de
asegurarse que sta se encuentra correctamente introducida. En efecto, y por
ms sorprendente que esto pueda parecer, la cantidad de programas mal diseados o mal utilizados en la materia est lejos de ser despreciable.

132

Tcnicas de la auditora informtica

La simetra de los asientos


Es deseable conservar en los ficheros de asientos contables la firma de
stos, o sea, la identificacin del usuario que haya introducido el asiento.
Esta firma facilitar las bsquedas en caso de litigio en una operacin.
Por supuesto, sta slo ser eficaz cuando las identificaciones que permitan el acceso al sistema sean individualizadas y cuando las contraseas correspondientes sean realmente confidenciales.
c) La modificacin de los asientos contables
Por deseo de seguridad, despus de que un asiento es validado, cualquier
modificacin debe estar prohibida. En caso de error, la correccin se har
por contrapartida del asiento errneo e introduccin del asiento correcto.
A ttulo de ancdota, una vez audit un software que no slo aceptaba
modificaciones de asientos antiguos, incluso en los ejercicios anteriores cerrados, sino que adems no llevaba a cabo ningn control en los asientos modificados. Los ficheros de archivos de los ejercicios anteriores no correspondan ya a las cuentas publicadas, y lo que es ms,...los dbitos no eran
iguales a los crditos!
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:
tratndose de las cuentas no marcables, un asiento de suma anterior se
calcula automticamente y ser el primer asiento del ejercicio siguiente,
tratndose de las cuentas marcables, el detalle de las cuentas no marcadas se toma en el ejercicio siguiente en la contabilidad auxiliar.
e) La generacin automtica de asientos
Los sistemas contables a menudo tienen que aceptar asientos que han
sido generados automticamente:
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, facturacin,
gestin de imovilizaciones, etc.
La contabilidad general, analtica y auxiliar

133

Estos asientos deben estar claramente individualizados y ser objeto de


una edicin en los diarios correspondientes, a fin de facilitar el control.
f) Las disposiciones legales y fiscales
Las disposiciones del plan general de contabilidad francs
Recordemos las disposiciones del plan general de contabilidad francs
relativas a la utilizacin de los procesos informatizados.*
Estas disposiciones figuran en la seccin IV del plan contable de 1982,
hecha obligatoria por un decreto del 27 de abril de 1982.
1. La organizacin 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 garanta y de conservacin
definidas en lo referente a prueba, los listados peridicos numerados y fechados recapitulando en orden cronolgico todos los datos introducidos en
l, bajo una forma que impida cualquier insercin intercalada o bien cualquier supresin ulterior.
3. El origen, el contenido y la imputacin de cada dato deben estar indicados claramente. Adems, 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 dejara ninguna pista, deben estar igualmente contrastados por un documento escrito fcilmente inteligible.
4. Debe ser posible, en todo momento, reconstruir a partir de los datos
definidos a continuacin los elementos de cuentas, listados e informaciones
sujetos a la verificacin 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 identificacin de los datos correspondientes.
5. El ejercicio de cualquier control debe comportar un derecho de acceso
a la documentacin relativa a los anlisis, a la programacin y a la ejecucin
de los procesos con el fin de proceder, entre otras cosas, a los tests necesarios.

(*) El PGC espaol no contempla este tipo de disposiciones.

134

Tcnicas de la auditora informtica

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 artculo 4 consagra la
nocin de continuidad de la va de revisin en los procesos contables. Los
artculos 1, 5 y 6, relativos a las posibilidades de un control externo, sern
comentados en el apartado 13.1.1.
El artculo 2 aclara las modalidades de edicin del diario, o sea: ediciones peridicas numeradas y fechadas, respecto del orden cronolgico de los
asientos introducidos, imposibilidad de modificaciones posteriores.
Por ltimo, el artculo 3 es relativo a la necesidad de conservar los justificantes para cada asiento contable.
Las disposiciones del cdigo de comercio
El artculo 16 del cdigo de comercio francs prescribe que los libros
contables obligatorios deben ser conservados en su formato original durante
diez aos a contar desde la fecha de la ltima inscripcin en el libro.*
Los justificantes de la contabilidad deben igualmente ser conservados
durante diez aos. Si bien las facturas de compra deben ser archivadas en su
forma original, es cada vez ms 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 informtica.
Las disposiciones fiscales en materia de salvaguarda
Sobre este punto nos remitiremos al apartado 4.8, donde se mencionan
las posibilidades de control informtico por parte de la administracin fiscal.
Las disposiciones fiscales en materia de intercambio de datos informatizados (IDI)
El artculo 47 de la Ley de Finanzas corregida para 1990 introdujo, por
primera vez, la nocin de intercambio de datos informatizados en lo referente a facturacin y justificacin de facturas emitidas.

(*) Equivale al Artculo 30 del Cdigo de Comercio espaol.

La contabilidad general, analtica y auxiliar

135

De este texto, entre otras cosas, recordaremos que:


Bajo reserva de ser aprobadas por la administracin fiscal, las facturas
transmitidas por va informtica son consideradas como originales.
Las empresas emisoras y receptoras deben conservar las facturas, por un
primer perodo de tres aos (perodo de prescripcin) en un soporte magntico, despus por un perodo adicional de tres aos (durante el cual la
administracin slo tiene un derecho de comunicacin) 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 administracin dispone de un derecho de control de la aplicacin del
procedimiento.
g) La contabilidad auxiliar de clientes
El auditor se interesar por la existencia y por la fiabilidad de algunos listados descritos anteriormente (apartado 7.1.2c), entre otras cosas:

Las cartas de reclamacin de pagos.


El balance atrasado.
El seguimiento del riesgo cliente.
La justificacin del saldo de la cuenta de cliente.

Con relacin 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 gestin (seguimiento de impagados), se edita a peticin y la fecha de tirada tiene poca importancia. Pero, tambin 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 justificacin de las cuentas de clientes al 31 de
diciembre, si lo queremos cotejar con el balance, slo puede ser editado al final de la introduccin, 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, simultneamente, se edita el extracto de los asientos no marcados el 31 de diciembre.
136

Tcnicas de la auditora informtica

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 tcnico, 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 imputacin 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 gestin 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 domiciliacin, etc.) y la posibilidad de justificar las cuentas generales de
centralizacin.

7.2.2 La auditora de la utilizacin de la aplicacin


a) La validacin de los datos introducidos
Los borradores de registro, o sea, los extractos recuperables del registro servirn:
para la validacin de los datos introducidos por los usuarios, comparando con los justificantes o facturas,
para un control por parte de un superior jerrquico.
b) La validacin 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 contabilidad general, analtica y auxiliar

137

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.

138

Tcnicas de la auditora informtica

Captulo 8

El ciclo de las ventas

A lo largo de este captulo y de los dos siguientes trataremos de aplicaciones muy relacionadas entre s, son las siguientes:
la gestin comercial y la facturacin, o sea, el ciclo de ventas;
la gestin de aprovisionamientos, o sea, el ciclo de compras;
la gestin de existencias propiamente dicha, que constituye de alguna
forma el nudo central del conjunto.
Las cadenas de proceso propias de la gestin de produccin, por lo general especficas a cada tipo de actividad, incluso a cada empresa, no sern estudiadas en esta obra.

8.1 PRESENTACIN GENERAL DE LA APLICACIN


8.1.1 Los principales ficheros
a) Los ficheros de existencias
Contienen, para cada artculo, adems de sus referencias (cdigo, denominacin) y la cantidad en existencia, informaciones que varan mucho segn el diseo de la aplicacin, 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, regularizacin, etc.), el detalle de los movimientos
que hayan podido afectar las cantidades en los ficheros de existencias.
c) El fichero de precios
Comn 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 funcin de las cantidades vendidas, etc.
d) El fichero de cliente
Contiene para cada cliente los datos comerciales que le conciernen, tales
como: razn social, direccin, nombre de los interlocutores, categora de
cliente, descuentos acordados, importe pendiente mximo 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: intencin, pedido en firme, pedido servido (el albarn de entrega ha
sido editado), pedido facturado.
Para cada pedido encontraremos:
Un encabezamiento con el nombre del cliente, la direccin de facturacin, las condiciones de facturacin (las condiciones derogatorias respecto a las condiciones estndar del fichero de clientes pueden igualmente ser acordadas a nivel de cada pedido), el importe sin impuesto, el
importe con impuestos incluidos, etc.
Las lneas de pedidos por artculo, o sea, cdigo del artculo, cantidad,
descuento, etc.
De forma general, la gran mayora de los datos que figuran en el fichero
de los pedidos son automticamente extradas de los ficheros bsicos (artcu140

Tcnicas de la auditora informtica

los y clientes), con posibilidad de activacin del proceso de informacin derogatoria en el momento de la introduccin de los datos.
Adems, en algunos casos, el fichero de facturas emitidas es un fichero
distinto del de pedidos, pero con una estructura casi idntica.

8.1.2 Los procesos


Las modalidades de introduccin de datos estn en funcin de la organizacin de la empresa: toma de datos interactiva por los propios vendedores,
por las secretarias comerciales, o bien una introduccin de datos en microordenadores porttiles con transmisin regular de los pedidos al ordenador
central (el caso de los comerciales itinerantes, etc.).
La aplicacin controla la presencia de existencias disponibles en los ficheros y, en caso de necesidad (segn el plazo de entrega) procede a hacer
reservas de existencia.1 A menudo los albaranes de preparacin destinados a
los empleados del almacn son editados. Si se da el caso, las devoluciones
se preparan durante el proceso nocturno. Los empleados del almacn preparan los pedidos y despus registran las cantidades preparadas. Tras la introduccin de los datos, editan el albarn de entrega que acompaar el envo.
Las existencias se actualizan automticamente a partir de la salida de las
mercancas.
Desde el momento en que un pedido ha sido servido, es posible pedir su
facturacin. Segn la organizacin que se elija, la factura ser editada en
tiempo real, o bien en tiempo diferido. Adems, a menudo ambas posibilidades son posibles, o sea: facturacin inmediata para las ventas en el mostrador
y diferida para las dems.
La facturacin implica, en principio, la actualizacin de las cuentas de
clientes, as como, mensualmente, la edicin de los diarios de ventas.

8.2 LA AUDITORIA DE LA APLICACIN


8.2.1 La adecuacin de las prestaciones a las necesidades
de los usuarios
Las prestaciones detalladas del software de gestin comercial son, por lo
1. En algunos casos, en particular cuando el ciclo de fabricacin es corto, no hay existencias y son los pedidos los que determinan la produccin de las mercancas pedidas. ste ser, entre otros, el caso de
pedidos de mercancas perecederas.

El ciclo de las ventas

141

general, especficas a cada empresa. Nos limitaremos a mencionar a ttulo de


ilustracin 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 separacin de funciones


En el caso particular del ciclo de ventas, los principios de separacin de
funciones conducen a distinguir:
La actividad comercial.
La administracin de ventas, o sea, el seguimiento administrativo de las
operaciones.
La expedicin de las mercancas.
El seguimiento del riesgo-cliente.
Por lo general, la facturacin est automatizada, es puesta en marcha peridicamente por la administracin de ventas y pone en marcha la actualizacin 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 prctica, el respeto del principio de separacin de las funciones se manifiesta a travs de la limitacin de acceso a cada transaccin
solamente a personas autorizadas. De este modo:
el nico que est autorizado a modificar los importes pendientes mximos por cliente ser el responsable del crdito-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 jerrquico
a) El control jerrquico a priori
Por lo general, consistir en pedir que los pedidos para los cuales se hayan concedido condiciones especiales a los clientes, comerciales (comisiones) o financieras (descuentos, pago aplazado), sean objeto de una autorizacin por parte del superior jerrquico del vendedor (jefe de seccin, director
142

Tcnicas de la auditora informtica

comercial, etc.). Del mismo modo, los pedidos que sobrepasaran el importe pendiente autorizado para el cliente podran necesitar una autorizacin jerrquica.
b) El control jerrquico 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 excepcin facilitarn el control
por parte del responsable jerrquico, o sea:
Lista de los abonos superiores a un cierto importe.
Lista de las entregas que estn amparadas por las condiciones derogatorias de facturacin.
Lista de clientes cuyos valores pendientes de pago sea superior a un importe determinado autorizado, o bien que supere el importe pendiente
mximo autorizado para este cliente.

8.2.4 El seguimiento del riesgo-cliente


El riesgo mayor consistira 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 situacin difcil,
o bien porque su importe pendiente de pago ya sea bastante importante. Un
procedimiento apropiado podra ser el siguiente:
El servicio de crdito define para cada cliente un importe pendiente de
pago mximo autorizado, en funcin de los datos financieros y comerciales conocidos y lo introduce en fichero.
Los pedidos que hacen sobrepasar el importe pendiente mximo son rechazados, salvo cuando estn autorizados por un responsable capacitado.
Se editan con regularidad los listados de importes pendientes de pago
para su anlisis.

8.2.5 El seguimiento de la cifra de negocios


y de los mrgenes
Ya hemos mencionado la utilidad de instrumentos de control jerrquico,
por ejemplo, para el director comercial, en lo relativo a las condiciones concedidas por los comerciales a sus clientes.
El ciclo de las ventas

143

Muy a menudo, es de esperar que la empresa disponga de estadsticas


mensuales de las cifras de negocio y de los mrgenes realizados:

por cliente,
por vendedor,
por zona geogrfica,
por producto o por familia de producto.

Las informaciones resumidas deben ser, de hecho, transmitidas a la Direccin General por el auditor de gestin. Estas estadsticas, por supuesto,
interesarn tambin al Director Comercial, para quien supondrn un instrumento privilegiado de direccin de la poltica comercial.
Los listados especficos se destinarn eventualmente al clculo de las comisiones de los vendedores.
Tratndose del conjunto de estos listados estadsticos, adems de su inters 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 (captulo 7), vale la pena recordar el caso especfico del registro de pagos. La organizacin elegida debe garantizar a la vez
la fiabilidad del procedimiento, con el fin de evitar cualquier riesgo de prdida o de robo de un pago y la rapidez de registro, a fin de evitar cualquier
prdida de tesorera en los plazos de remesa a bancos.
El software, por lo general, permitir una introduccin de datos interactiva de los pagos, con mareaje de las facturas correspondientes, y edicin
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 imputacin.
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 auditora de una aplicacin informatizada. Solamente la definicin de los procedimientos administrativos apropiados, y la
realizacin de inventarios fsicos regulares permitirn estar seguro de que
toda mercanca que ha salido de las existencias ha implicado la emisin de
un albarn de entrega y de una factura. No obstante, los programas o los con144

Tcnicas de la auditora informtica

troles apropiados facilitarn la aplicacin de estos procedimientos. Distinguiremos dos tipos de organizacin.
Cuando los albaranes de entrega se efectan manualmente en talonarios matriz y son, despus, introducidos para la edicin de facturas informatizadas
No se deber autorizar ninguna salida de mercanca sin que se haya hecho un albarn de entrega. Estando los talonarios matriz numerados de antemano, se introducirn los nmeros de albarn de entrega en el sistema, el
cual editar mensualmente la lista de los que faltan en la secuencia de los nmeros de albaranes utilizados.
Cuando los albaranes de entrega son procesados deforma informatizada
No se deber autorizar ninguna salida de mercanca sin que vaya acompaada de un albarn de entrega. Un procedimiento manual sustitutorio, con
la confeccin del albarn a partir de un talonario matriz, podr ser autorizado
para anticipar los casos de indisponibilidad del equipo.
Cualquiera que sea el procedimiento de la confeccin del albarn de entrega, cada entrega deber dar lugar rpidamente a la facturacin y registro
en contabilidad, salvo en un caso especial, estrictamente individualizado y
justificado.
De este modo:
Los albaranes de entrega slo podrn ser utilizados por un responsable
jerrquico debidamente autorizado; los albaranes de entrega anulados
aparecern en un listado resumen mensual para ser controlados.
La emisin de facturas a partir de las entregas estar automatizada; slo
un responsable jerrquico autorizado podr pedir el saldo de la facturacin.
La emisin de la factura implica simultneamente la actualizacin de la
cuenta del cliente, sin posibilidad de derogacin.
8.2.8 La separacin de los ejercicios contables
Con el fin de respetar el principio de separacin de los ejercicios contables, los servicios financieros necesitan generalmente de listados que les
permitan pasar los asientos de cierre tales como:
El ciclo de las ventas

145

Lista de las mercancas servidas al 31 de diciembre y que estn pendientes de facturacin.


Lista de las facturas emitidas al 31 de diciembre cuya mercanca todava
no haya sido servida (cuando el procedimiento autoriza este tipo de caso).
Lista de mercancas devueltas por los clientes antes del 31 de diciembre
y para las cuales no se haya emitido an una nota de abono.
Cuando se emiten estados mensuales, stos sern necesarios cada fin
de mes.

8.3 LA UTILIZACIN DE LOS PROGRAMAS


DE AUDITORIA
Citaremos a continuacin algunos ejemplos de programas que podrn ser
aplicados por el auditor, para anlisis complementarios durante sus controles.
a) Bsqueda 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 facturacin 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 estn de
acuerdo con la poltica comercial.
Se confrontarn las facturas emitidas durante un cierto perodo con el fichero de clientes, a fin de verificar que las condiciones pactadas (que se encontrarn en el encabezamiento de la factura) son idnticas 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 perodo
importante, es posible que las condiciones generales que figuran en el fichero de clientes hayan sido modificadas durante el perodo.
b) Bsqueda de las lneas de facturas emitidas para las cuales el
precio unitario de los artculos sea diferente del que figura en el
fichero de precios
El objetivo ser aqu verificar que los precios unitarios facturados estn
de acuerdo con las listas de precios. Las diferencias podran tener su origen
146

Tcnicas de la auditora informtica

en errores de software, o en condiciones ms favorables acordadas por los


comerciales.
Con este fin, se confrontarn las lneas de artculos de las facturas emitidas durante un perodo dado con el fichero de listas de precios.
Cabe mencionar que cuando las facturas son analizadas en un perodo
largo, es posible que los precios unitarios del fichero de lista de precios hayan sido modificados durante el perodo.
A ttulo de ancdota, y para ilustrar el inters de este test, tomemos el
ejemplo de un software en el cual la zona precio unitario de la lnea de factura tenga, debido a un error, una extensin inferior a la zona precio unitario del fichero de listas de precios: los precios facturados de los artculos
superiores a 10.000 pesetas se encuentran truncados. De este modo, un artculo de 11.500 pesetas ser facturado por 1.500 pesetas! Esta anomala de
diseo ser detectada inmediatamente por el test.
c) Bsqueda de clientes que dispongan permanentemente
de condiciones especialmente ventajosas
El objetivo esta vez es asegurarse de que, debido a un error en la introduccin 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 slo basta una lectura secuencial del fichero de clientes, donde se encuentran las condiciones normales
practicadas.
d) Bsqueda 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 facturacin
haya sido aplazada de forma anormal.
Por lo general es fcil, con un barrido del fichero, detectar todos los
pedidos servidos anteriormente a una fecha determinada y no facturados todava.
e) Bsqueda de los abonos ms importantes
A travs de un balance secuencial del fichero de los abonos emitidos,
comprobaremos que stos estn justificados, ya sea por las devoluciones de
mercancas o bien por los descuentos financieros o comerciales.

El ciclo de las ventas

147

f) Bsqueda de los clientes cuyos importes pendientes sobrepasen


los valores mximos autorizados por el servicio de crdito
Buscaremos aqu los clientes a los cuales aceptaramos servir incluso
cuando su importe pendiente sea demasiado alto.
De hecho, el servicio de seguimiento del riesgo-cliente determina, por lo
general, un saldo mximo pendiente de pago autorizado en funcin 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 aplicacin, a menudo
est controlado en una zona especfica de este fichero.
El importe pendiente mximo autorizado aparece en el fichero de cliente.
Si bien la aplicacin de este test parece demasiado compleja, una variante
simple consiste en listar todos los clientes cuyo importe pendiente mximo
autorizado sobrepase un lmite determinado.
Por ltimo, cuando no existe un importe pendiente mximo en el fichero,
una segunda variante consistir en seleccionar los clientes cuyos importes
pendientes sobrepasan un cierto lmite.
De todos modos, despus de la seleccin, el auditor intentar analizar el
riesgo real en estos clientes.

148

Tcnicas de la auditora informtica

Captulo 9

El ciclo de las compras

9.1 PRESENTACIN GENERAL DE LA APLICACIN


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 artculo 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 sern revendidos en estas condiciones, en el marco de una actividad
puramente comercial, y los aprovisionamientos en materias primas, que entrarn en el ciclo de produccin de la empresa, esta vez en el marco de una
actividad industrial.
En el primer caso, el fichero de existencias es comn 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 produccin, de donde saldrn 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 mercancas 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 bsicos relativos a cada proveedor, tales como: razn social, direccin, nombre de los
corresponsales, descuentos obtenidos, forma de pago, etc.
d) El fichero de las cuentas de proveedores
Extrado de la contabilidad auxiliar de proveedores, contiene el detalle
de los asientos en las cuentas de proveedores.
e) El fichero de listas de precios
Segn las empresas, ser til (y posible) o no conocer en los ficheros
informticos las listas de precios de los principales proveedores de cada artculo.
Las ventajas son evidentes: eleccin automtica del mejor proveedor
para cada artculo, control de las facturas recibidas, etc.
Pero, en contrapartida, esta gestin de las listas de precios es, a menudo,
demasiado ardua por diferentes razones, entre las cuales estn:
Las referencias de los artculos muy raras veces son las mismas en una
empresa y en su proveedor.
En espera de obtener del proveedor la transmisin de las listas de precios
en soporte magntico, las tareas del registro cuando ocurre cualquier
modificacin 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 aos en materia de normalizacin de los
cdigos 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 anloga al fichero de los pedidos de clientes, encontramos para cada pedido:
150

Tcnicas de la auditora informtica

Un encabezamiento que llevar los datos bsicos del pedido, tales como:
nombre y direccin del proveedor, condiciones de pago, importe sin y
con IVA incluido de la factura, etc.
Las lneas por artculo: referencia, precio unitario, descuento obtenido,
tipo de IVA, etc.
Muchos de los datos que aparecen en este fichero son extrados automticamente de los ficheros de proveedores, de artculos y de lista de precios,
con posibilidad de activacin del proceso del desarrollo de informaciones
sustitutorias en el momento de la toma.
Segn sea el caso, las facturas sern controladas en un fichero especfico,
o bien sern integradas en el fichero de pedidos, con un cdigo particular denominado situacin del pedido.
9.1.2 Los procesos
Los pedidos de aprovisionamiento son introducidos manualmente, o preparados automticamente con arreglo a las reglas establecidas previamente
(existencia inferior a un lmite fijo, existencia inferior al consumo de x meses anteriores, etc.). De todas formas, los pedidos son susceptibles de modificaciones antes de la autorizacin definitiva para emisin y envo al proveedor.
Igualmente, segn sea el caso, y por las razones anteriormente citadas, el
precio unitario de los artculos ser conocido o no en los ficheros en el momento de efectuarse el pedido.
Las cantidades pedidas, artculo por artculo, sern conocidas en todo
momento.
En el momento de la recepcin de la mercanca, las cantidades recibidas
son registradas, bien directamente en el momento del control de las cantidades, o bien a partir de un albarn de recepcin rellenado despus de contada
la mercanca. Las cantidades recibidas deben, en principio, corresponder al
albarn 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 recepcin puede corresponder a varios pedidos.
Por el contrario, una recepcin puede ser slo parcial, ya sea debido a
que algunos artculos 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
El ciclo de las compras

151

diseo del software para el registro de las facturas de proveedor. stas


son, de hecho, emitidas con cada entrega y es difcil cotejar las lneas de
la factura y los pedidos, ya que una factura puede haber salido de varios
pedidos y que una misma lnea de pedidos ha podido dar lugar a varias
entregas y, por consiguiente, a varias facturas.
Por este motivo, y para evitar hacer ms difcil el diseo de los programas, se imponen muy a menudo procedimientos manuales a los usuarios,
como por ejemplo:
Las lneas de pedido se completan con los precios unitarios facturados,
para servir de base a la valorizacin de las existencias, y el importe total
de la factura es imputado en la contabilidad del cliente, si fuere el caso a
travs de un segundo registro totalmente independiente.
En caso de entrega parcial por parte de un proveedor, una lnea del pedido para el resto del pedido a ser servido, si se diera el caso, ser registrado nuevamente, o bien creado de forma automtica.
Por supuesto, los precios unitarios facturados por el proveedor sern o no
controlados automticamente segn hayan estado o no cargadas en mquina
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 mercanca.
Adems, algunas veces, se devuelve la mercanca al proveedor cuando la
entrega no est de acuerdo con el pedido o cuando existe algn problema con
relacin 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 slo son liquidadas despus de la toma de una
seal informtica, correspondiente al conforme para pago colocado sobre la factura. El pago se genera automticamente en la contabilidad de proveedores, segn la forma de pago que figure en el fichero (taln, pagar, etctera).
Nota:
El procedimiento que acabamos de describir se refiere a la compra de
mercancas. En realidad, los programas permiten igualmente, a menudo, el
control de pedidos de prestaciones inmateriales, o sea, que no generan ningn tipo de entrada fsica. Un indicador, colocado en la parte superior del pedido, especificar que ste no dar lugar a ningn tipo de actualizacin de
existencias.
152

Tcnicas de la auditora informtica

9.2 LA AUDITORA DE LA APLICACIN


9.2.1 La adecuacin de las prestaciones a las necesidades
de los usuarios
Entre las funciones cuya adecuacin a las necesidades es especialmente
til controlar, podemos citar:

La gestin automtica de los aprovisionamientos.


La gestin 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 permetro de aplicacin del procedimiento (la no existencia de procedimientos 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 separacin de funciones
Los imperativos de una buena separacin 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 autorizar el pago.
El servicio de compras, que pasa los pedidos y coordina las relaciones
con los proveedores.
El almacn, que es responsable de la conservacin de los activos, y asegura el control, tanto cualitativo como cuantitativo, de las mercancas entradas.
La contabilidad, que registra las facturas de proveedores.
La tesorera, que est en el origen del pago al proveedor.
9.2.3_Los controles jerrquicos
Enfocaremos aqu, muy en particular, el control jerrquico de la actividad de los compradores. Este control se ejerce ya sea a priori, debido a la necesidad que tienen stos de contar con autorizacin para algunos pedidos
El control de las compras

153

(excepcionales por su importe o sus condiciones) por parte de un superior jerrquico, o bien a posteriori por la emisin de listados que suministren peridicamente el resumen de los pedidos pasados, con el detalle de las condiciones negociadas.
Estos listados estadsticos pueden responder a diferentes criterios de anlisis, o sea:
Volumen de negocios y descuentos obtenidos por proveedor.
Volumen de negocios y descuentos obtenidos por comprador.
9.2.4 La separacin 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 mercancas entregadas para las cuales no se haya recibido an la factura del proveedor.
Las facturas recibidas de las cuales no hayan sido an entregadas las
mercancas.
Los abonos a recibir.
Veremos, adems, que un buen control de la separacin 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 recepcin 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 podran 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 recepcin al trmino de la prestacin. Por esta
misma razn, es adems 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 slo
se paguen a los proveedores las prestaciones realmente debidas.
Con esta ptica:
154

Tcnicas de la auditora informtica

Los originales de las facturas se registran en contabilidad.


Las facturas registradas son numeradas en secuencias, o sea, con el nmero colocado manualmente e introducido en el ordenador con la factura,
o bien el nmero es colocado por el ordenador y puesto en la factura.
Los originales de las facturas se transmiten a los servicios de autorizacin de pago para la colocacin del conforme para pago, despus de la
comparacin de la factura con el albarn de recepcin hecho por el almacn, cuando la factura corresponde a una entrega de mercanca.
Los conforme para pago son registrados en el sistema informtico y
ponen en marcha los pagos automatizados.
Se registra eventualmente un comentario en los pedidos con algn tipo
de problema.
Este procedimiento permite, a la vez, conocer todas las facturas recibidas
y pagar slo las facturas autorizadas. En particular, la utilizacin de los originales de factura y su numeracin evita cualquier doble registro o doble
pago de una de ellas, y la comparacin de la factura con el albarn de recepcin evita pagar prestaciones incompletas o no satisfactorias.

El ciclo de las compras

155

Captulo 10

La gestin de existencias

Evidentemente, la gestin de existencias est estrechamente relacionada


con las cadenas ascendentes:
La gestin 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 gestin de produccin 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 captulo los procesos propios de la gestin y de la valorizacin de existencias.

10.1 PRESENTACIN GENERAL DE LA APLICACIN


10.1.1 Los principales ficheros
a) El fichero de artculo
Contiene los datos permanentes relativos a cada artculo, como:
Referencia, denominacin, localizacin habitual en almacn, proveedores) habitual(es), precio de compra, precio de venta, descuento por
cantidad acordado, nomeclatura de produccin, etc.
156

Tcnicas de la auditora informtica

En algunos casos, se distingue el fichero de artculo y el fichero de lista


de precio.
Adems, el contenido exacto de este fichero depende, por supuesto, del
tipo de artculo referenciado, por ejemplo: una materia prima tendr las informaciones relativas a su tipo de aprovisionamiento y a su utilizacin en el
ciclo de produccin, un producto acabado tendr los datos de gestin comercial, etc. En las empresas industriales, adems, se distinguirn a menudo varios ficheros segn la posicin de los productos en el ciclo de produccin.
b) El fichero de las existencias
Los datos cuantitativos de las existencias son, segn sea el caso, incluidos o no en el fichero de artculo.
Citemos a ttulo de ilustracin estos datos:
La cantidad en existencias, con una gestin eventualmente individualizada segn 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 ejecucin del inventario fsico da lugar a la creacin
de un fichero especfico. En otros casos, los datos de inventario estn incluidos directamente en el fichero de existencias.
d) El fichero de los movimientos de existencias
Habamos mencionado en el captulo primero (apartado 1.3.1) la necesidad de crear en toda cadena de gestin de existencias un fichero de los movimientos de las mismas, que permita justificar las cantidades y la valoracin
de los artculos que figuran en el inventario permanente.
10.1.2 Los procesos
Citemos entre los principales procesos propios de la gestin de los ficheros de existencias:
La gestin de existencias

157

La valoracin de las existencias.


El proceso del inventario fsico.
El registro de los movimientos de existencias que no tengan origen en las
cadenas ascendentes.
La preparacin automtica de reaprovisionamientos en funcin a lmites
de alerta.
Diversas emisiones: listado de los movimientos, listado de las anomalas, listado de las existencias valorizadas, etc.

10.2 LA AUDITORIA DE LA APLICACIN


Volvemos a hablar aqu de la auditora de las principales funciones de la
aplicacin.
10.2.1 La valoracin de las existencias
Una gestin informatizada de la valoracin de las existencias implica la
realizacin 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 sern valoradas a precio de adquisicin, para
los bienes adquiridos fuera de la empresa y a coste de produccin, para los
artculos fabricados en la empresa.
No detallaremos aqu las modalidades de clculo del coste de produccin
ni el detalle de los cargos incorporados a este coste. El lector se informar,
para mejor precisin sobre este tema, en las obras de contabilidad.
Tratndose de modalidades de valoracin de existencia contable y fiscalmente admisibles, conviene distinguir entre los artculos identificables y
los artculos intercambiables.
Los artculos identificables de una manera individual se valorizan a su
coste real de entrada.
Los artculos intercambiables, en los cuales centraremos nuestra atencin, sern valorizados a un coste estimado de entrada. Se admiten dos mtodos para evaluar este coste estimado:
El mtodo del primero en entrar, primero en salir, llamado tambin el
mtodo del FIFO (first in, first out).
El mtodo del coste medio ponderado.
158

Tcnicas de la auditora informtica

El mtodo FIFO
Cada salida se valoriza al coste ms antiguo del producto en existencia,
de donde viene la expresin de primero en entrar, primero en salir.
En el plan informtico este mtodo implica conservar, para cada producto, el detalle de los movimientos de entrada correspondiente a las existencias presentes en la empresa. A continuacin veremos un ejemplo de valoracin en FIFO.

Ejemplo de valoracin en FIFO


Fecha

Tipo de
Cantidad
movimiento

Precio
unitario
de entrada

Valor

Valor

dlas

dlas

entradas

salidas

12/1

Compra

10

100

1000

18/1
20/1
22/1
24/1

Compra
Venta
Compra
Venta

10
5
10
10

110
120
-

1100
1200

5001
1O5O2

Valor

Cantidad
restante
existencia

existencia

10

1000

20
15
25
15

2100
1600
2800
17503

dla

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. Despus de la venta del 24/1, los ficheros informticos deben saber que el valor de la existencia se justifica por las 10 entradas del 22/1 (a 1.200 PTA) y 5 de las entradas del 18/1 (a 550 PTA).

Se comprender fcilmente, a vista de este ejemplo, que de una parte la


gestin de un sistema de este tipo es relativamente trabajosa, y que, por otro
lado, los volmenes de los ficheros pueden tornarse considerables cuando
las existencias de cada artculo se justifican por medio de un nmero importante de movimientos de entrada.
Cuando se emplea este mtodo de valoracin, el auditor se preocupar de
comprobar que se trata de un verdadero FIFO. Algunas veces, de hecho,
mtodos ms o menos prximos son calificados errneamente de FIFO.
El mtodo del coste medio ponderado
Segn este mtodo, el coste medio ponderado se recalcula:
ya sea en el momento de cada entrada;
o bien en un perodo que no sobrepase el coste medio de almacenaje.
La gestin de existencias

159

He aqu un ejemplo de valoracin al coste medio ponderado recalculado


en el momento de cada entrada, que es notablemente el mtodo ms empleado en Francia y que presenta adems la ventaja de la simplicidad.
Ejemplo de valoracin de la existencia a coste medio ponderado
Fecha

Tipo de
movimiento

Cantidad

Precio
Valor
unitario
dlas
de entrada entradas

12/1
18/1
20/1
22/1

Compra
Compra
Venta
Compra

10
10
5
10

100
110
_
120

1000
1100
_
1200

24/1

Venta

10

Valor
dlas
salidas

Cantidad Precio
Valor
restante
medio
dla
existencia existencia existencia

525
-

10
20
15
25

100
105
105
111

1000
2100
1575
2775

1110

15

111

1665

_
-

En Francia no se admite ni contable ni fiscalmente ningn otro mtodo


de valoracin de las existencias. No obstante, podemos citar otros mtodos
aplicados algunas veces:
La valoracin a coste de sustitucin.
La valoracin por el ltimo precio conocido.
La valoracin a coste estndar.

10.2.2 El inventario fsico


Independientemente de las obligaciones legales y fiscales en la materia,
el inventario fsico de las existencias constituye una medida de control interna indispensable, que suministra informacin valiosa sobre la fiabilidad
del inventario permanente.
El desarrollo de software especfico es, por lo general, necesario para facilitar el buen funcionamiento de las operaciones de inventario.
La preparacin del inventario fsico
La documentacin del inventario, que ser revisada por los equipos encargados de la operacin, es generalmente impresa con anterioridad, por medio de un listado informtico de los artculos por localizacin de almacenaje.
El inventario ser ms fiable si se realiza a ciegas. Las cantidades tericas en existencia, resultantes del inventario permanente informtico, no
constarn en la documentacin de inventario.
160

Tcnicas de la auditora informtica

La toma de la documentacin de inventario


Recordemos en primer lugar que un inventario fsico fiable necesita en
principio un recuento doble llevado a cabo por dos equipos de personal diferentes. Los resultados de cada recuento figuran en la documentacin de inventario.
En cambio, no es necesario prever en la aplicacin informtica la introduccin para cada artculo de los resultados de cada uno de los dos recuentos. Slo la cantidad definitiva en existencia ser tomada.
El proceso del inventario
Al trmino de la introduccin de los datos del inventario, es deseable que
se impriman para el anlisis las diferencias significativas entre el inventario
permanente y el inventario fsico. El inventario fsico ser, si es necesario,
corregido despus del anlisis.
Una vez que se hayan efectuado estas ltimas correcciones, por lo general se prever la sustitucin automtica en los ficheros del inventario permanente por el inventario fsico, o bien la introduccin de los movimientos de
correccin de inventario.
Cuando el inventario fsico ha sido realizado al cierre del ejercicio contable, los procesos informticos se concluirn con la emisin de las existencias
valoradas, que servir de base para la introduccin de los asientos contables
de valoracin de las existencias.
10.2.3 La introduccin de las regularizaciones
de existencias
Si bien la gran mayora 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 regularizacin. Segn sea el caso, estas regularizaciones sern valorizadas (ejemplo: devoluciones de mercancas) o no (ejemplo: correcciones de inventario).
Los movimientos de regularizacin que afecten el valor de las existencias (sin movimiento de cantidad) deben igualmente poder ser introducidos.
Por supuesto, el acceso a la pantalla de introduccin de datos de las regularizaciones debe estar estrictamente limitado. En particular y por razones de
separacin de funciones, estar prohibido a las personas responsables de la
conservacin de las existencias (personal de almacn).

La gestin de existencias

161

10.2.4 La gestin de reaprovisionamientos


Es muy raro que la gestin de reaprovisionamientos sea totalmente automatizada. En cambio, se prev que la aplicacin proponga los pedidos a proveedores con arreglo a criterios definidos con anterioridad, tales como:
existencias inferiores a un lmite de alerta, fijo o variable (x meses de
ventas, etc.).
10.2.5 Las ediciones peridicas
Citaremos algunas de ellas, que son necesarias para fines de gestin, y
control o bien para fines puramente contables.
El listado de valoracin de las existencias
Tendr la cantidad y el precio unitario de cada artculo, 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 clculo 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 gestin (el conocimiento
de las existencias paradas) y a un objetivo contable (el aprovisionamiento de
todo o parte de tales existencias).
El criterio de seleccin de las rotaciones lentas ser, por ejemplo, el siguiente:
Una cantidad en existencias superior a x meses de salidas futuras previsibles.
Una cantidad en existencias superior a x meses de salidas pasadas.
Siendo este el criterio empleado con ms frecuencia.
Tratndose 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 %.
162

Tcnicas de la auditora informtica

Las cantidades en existencia que representen entre 6 meses y un ao de


almacenaje se deprecian en un 50 %.
Las cantidades en existencia que representen ms de un ao de almacenaje se deprecian en su totalidad.
El clculo de la provisin por alza de los precios
Sin entrar en el detalle del clculo de esta provisin, nos limitaremos a
recordar que se trata de una provisin de tipo fiscal, destinada a cubrir los
efectos de la inflacin en el coste de recuperacin de las existencias en perodo de alza de los precios.
Su clculo, basado en la comparacin de los costes unitarios de los artculos en existencia durante tres ejercicios sucesivos, necesita, por lo general, el desarrollo de un software especfico.
Para ms precisin sobre este tema el lector debe recurrir a las obras sobre contabilidad.

10.3 LA UTILIZACIN 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 validacin, o tambin a conseguir este resultado para paliar su falta en la empresa:

Clculo de la valoracin de las existencias.


Deteccin de rotaciones lentas y clculo de la provisin contable.
Clculo de la provisin por alza de precio.
etctera.

Los programas destinados a seleccionar, para un anlisis complementario, los artculos que presenten las siguientes caractersticas particulares:
Lista de artculos cuyo precio unitario haya subido ms de X % de un
ejercicio al otro. Nos aseguraremos de que este aumento est justificado
y que no esconda un error en el clculo del precio unitario que resulte en
una supervaloracin del valor de las existencias.
La gestin de existencias

163

Lista de los artculos cuya cantidad en existencia del inventario permanente sea negativa. Esta lista revela eventuales puntos dbiles en el
inventario permanente, debidos a errores de software, a una mala aplicacin del procedimiento (por ejemplo, de entradas de mercancas registradas con retraso).
Lista de las diferencias ms significativas entre inventario fsico 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 fsico!); a menudo, las diferencias ms importantes se deben a anomalas 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 anomalas.

164

Tcnicas de la auditora informtica

Captulo 11

La nmina y la gestin
del personal

11.1 PRESENTACIN DE LA APLICACIN


Si bien es cierto que, hoy da, la nmina tan slo representa un subconjunto de una funcin mucho ms amplia (la gestin de los recursos humanos), no es menos verdad que, tratndose de procesos informticos, la nmina constituye evidentemente la aplicacin ms sensible, que justifica un
inters particular por parte de los auditores por el contenido de esta funcin.
El presente captulo se centrar, por tanto, principalmente en la gestin del
fichero de personal y el proceso de la nmina.

11.1.1 Los ficheros principales


a) El fichero de personal
Constituye, por supuesto, el fichero bsico de la gestin de los recursos
humanos.
Para cada asalariado contendr: el nombre, los apellidos, la direccin, el
cargo, la funcin, la remuneracin, las primas, la fecha de nacimiento, los diplomas, el seguimiento del absentismo, seguimiento de las vacaciones, situacin familiar, etc.
La mayora de las veces, contendr igualmente los acumulados anuales
necesarios para la elaboracin de los listados fiscales y sociales obligatorios.
La nmina y la gestin del personal

165

El fichero de personal se actualiza constantemente por un procedimiento


interactivo.
b) Los ficheros propios del proceso de la nmina
El fichero de los movimientos de la nmina (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 trabajadas, horas extra, absentismo, vacaciones, primas extraordinarias, etc.
El fichero preparatorio de la nmina
En la gran mayora de los casos, la preparacin de la nmina a final de
mes se lleva a cabo en dos fases, con algunos das de intervalo, conservndose entre ambas un fichero preparatorio para la confeccin de las hojas de
salarios.
Los ficheros de los parmetros de nmina
Contienen todos los parmetros necesarios para la preparacin de la nmina, como: tasa de cotizacin, lmites, etc.
Los ficheros de las transferencias de nminas
Se transmite cada mes al banco de la empresa para efectuar las transferencias correspondientes a la remuneracin neta de los salarios.

11.1.2 Los principales procesos


a) Los procesos relacionados directamente con la fijacin de la
nmina
Cada mes, despus de terminadas las actualizaciones del fichero de personal
con la introduccin de los hechos susceptibles de variar la nmina del mes, se
ejecuta el proceso de la nmina. Este proceso en tiempo diferido (figura 5) se
desarrolla por costumbre en dos etapas, que son:
Una primera etapa que conduce a la ejecucin de un listado preparatorio para
ser aprobado por parte del servicio de personal y, si fuere el caso,
166

Tcnicas de la auditora informtica

Figura 5. Presentacin sinttica de la preparacin mensual


de la nmina.

La nmina y la gestin del personal

167

para efectuar correcciones en los ficheros y, la mayora de las veces, para


la edicin de un fichero intermedio que servir para la edicin de las hojas de salarios.1
Una segunda etapa, algunos das despus de la primera, que conduce a la
emisin de las hojas de salario definitivas, a la emisin del libro de salarios y del diario de salarios contable, a la actualizacin en el fichero de
personal de los acumulados necesarios para la edicin a final de ao de
los listados obligatorios y tambin a la emisin de los listados necesarios
para el pago de las cotizaciones patronales y de todos los listados estadsticos.
Al final del ao se estudian los listados de declaracin anual de remuneraciones (DADS1 en Francia) destinados a la Seguridad Social y a la administracin fiscal.
b) Los procesos propios de la gestin de recursos
humanos
Sin pretender que la lista sea exhaustiva, a continuacin citaremos de
forma abreviada algunas prestaciones propias de la gestin de recursos
humanos:
Seguimiento individual del historial de evolucin de las funciones ocupadas, de las posiciones jerrquicas, de las remuneraciones, de las formaciones seguidas, etc.
Simulacin relativa a la evolucin de las remuneraciones.
Gestin de los mandos superiores y dirigentes, por medio de un fichero
especfico.
Gestin previsional del empleo.
Control de la movilidad (gestin de un fichero de las ofertas de empleo,
seguimiento de los colaboradores que buscan cambio de categora laboral).
Control de la formacin (catlogo de formacin, seguimiento individual,
etctera).
Seguimiento de vacaciones y absentismo.
Gestin de la contratacin.

1. Si tras del control no hace falta ninguna correccin, el proceso definitivo consistir en ejecutar la segunda fase a partir del fichero intermedio, mientras que, en el caso contrario, las dos fases se ejecutarn
sucesivamente despus de la modificacin de los ficheros bsicos.

168

Tcnicas de la auditora informtica

11.2 LA AUDITORIA DE LA APLICACIN


Presentaremos en forma de un cuestionario algunos puntos importantes
de control de la aplicacin de gestin del personal y, ms en particular, del
proceso de la hoja de salarios.
P. Estn los parmetros necesarios para la confeccin de la hoja
de salarios incluidos en las tablas y actualizados por el
departamento de personal?
Algunas veces se encuentran todava (felizmente muy raramente) programas especficos desarrollados internamente, en los cuales los parmetros 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 ms rpido posible.
Ms frecuente es el caso en el que estos parmetros se incluyen en las
tablas, pero, teniendo en cuenta la complejidad de la aplicacin, son actualizados por el departamento de informtica a peticin del de personal.
Esta forma de actuar, si bien es admisible de forma transitoria en el momento de la aplicacin del programa, no es aconsejable a largo plazo. El
departamento de personal debe ser responsable de la utilizacin del programa de clculo de la nmina y, por lo tanto, en particular, de su parametraje.
Diremos de paso que la gestin 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 utilizacin de un lenguaje de programacin2), y que, adems, es indispensable,
por razones de seguridad, que por lo menos dos personas estn capacitadas
para llevar a cabo esta funcin.
P. Se conserva en un fichero especfico el historial de
actualizacin realizado sobre la base de los parmetros de la
hoja de salarios?
Este historial es indispensable para llevar a cabo bsquedas 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 fijacin de la nmina, los conceptos de nmina y las modalidades de clculo de la remuneracin correspondiente a cada concepto, las
modalidades de creacin de los asientos contables, etc. Esto explica que cuantas ms posibilidades funcionales ofrezca el sistema de parametraje, ms compleja ser su utilizacin.

La nmina y la gestin del personal

169

pondiente al mes anterior. Puede ser tanto informatizada, por medio de un fichero de las modificaciones de parmetros, o bien manualmente; en este
caso los parmetros se editarn en archivos en el momento de cada puesta al
da.
P. Es correcto el clculo de las remuneraciones
y de las cotizaciones de trabajadores y patrones?
Si bien esta cuestin parece bsica en el marco de la auditora de la hoja
de salarios, desgraciadamente no es fcil detectar anomalas que slo se manifestaran en casos especficos y muy infrecuentes.
Un indicador de fiabilidad de la aplicacin reside en el anlisis de las
reclamaciones que llegan al departamento de personal durante un perodo
de tiempo determinado. La utilizacin de software de auditora puede de la
misma forma permitir detectar, si fuera el caso, las incoherencias importantes.
P. Las hojas de salario estn de acuerdo con la
reglamentacin?
Sealemos, entre otras cosas, las obligaciones legales de 1988 concernientes a la mencin en las hojas de salario de las informaciones relativas a
las cotizaciones patronales y a las vacaciones remuneradas.
P. Permite el software la edicin del libro de salarios?
Este listado obligatorio reproduce, en orden cronolgico, algunas informaciones que aparecen en las hojas de salarios.
P. Permite el software la creacin de las cintas de transferencia
de salarios a los bancos?
ste es el caso de la gran mayora de los programas.
P. Se ha previsto una actualizacin automtica de los
acumulados necesarios para establecer la Declaracin Anual
de Remuneraciones destinada a la Seguridad Social (DADS1
en Francia)?
ste es igualmente el caso de la gran mayora de los programas.

170

Tcnicas de la auditora informtica

P. Si hay un procedimiento de actualizacin 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 anomalas eventuales, se comprender fcilmente que debe estar completamente asegurada, en la medida en
que es susceptible de crear heterogeneidades entre las remuneraciones remitidas y las declaraciones a la Seguridad Social y a la administracin fiscal
y, por tanto, de tener defraudadores eventuales entre el personal de la empresa.
La utilizacin del procedimiento ser, por lo tanto, cuidadosamente controlada; cualquier modificacin de los parmetros, reservada a un nmero
muy limitado de operadores, debe, por ejemplo, ser precedida de la aprobacin del jefe de personal.
P. El procedimiento de preparacin de la nmina garantiza la
coherencia del fichero de personal, hoja de salarios, libro de
salarios, asientos contables, ficheros de acumulados anuales
para la Declaracin Anual de Remuneraciones (DADS1) y
listados estadsticos?
El diseo mismo del procedimiento debe garantizar la coherencia entre el
conjunto de estos elementos.
Ilustraremos mejor este tema por medio de un ejemplo de contraste. Imaginemos dos procedimientos anlogos al descrito en la figura 5, pero en los
cuales los acumulados anuales estn actualizados en el fichero de personal
desde la primera etapa, permitiendo el procedimiento, adems, la posibilidad
de modificar el fichero preparatorio de la nmina, sin modificacin previa de
los ficheros bsicos (fichero de personal, fichero de los cambios de nmina,
fichero de parmetros).
Este procedimiento no ser, en ningn 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 intervencin manual, de donde resulta un caso flagrante de discontinuidad de la va de revisin.
La terminacin del proceso implica que las zonas de acumulados anuales
sean corregidas manualmente en el fichero de personal posteriormente
a la emisin de la hoja de salarios, por lo que existe un riesgo importante
de error en la aplicacin del procedimiento.
La nmina y la gestin del personal

171

P. Hay una fase de autorizacin previa para la preparacin de la


nmina antes de editar las hojas de salarios definitivas?
Esta fase, de la cual hemos hablado en la descripcin del proceso, permite detectar eventuales anomalas previamente al envo de las hojas de salarios y de las rdenes de transferencia.
P. Se procede a la comprobacin manual entre el libro
de salarios, los asientos contables y los diversos listados
estadsticos despus del proceso de la nmina?
Estas confrontaciones, en caso de incoherencia, revelaran anomalas en
el software, o bien maniobras fraudulentas.
P. Se llevan a cabo comprobaciones de cuentas bancarias con
regularidad?
Una tcnica de fraude en materia de nmina, y cuya divulgacin ha sido
muy extendida, consiste en modificar la cinta de transferencias entre su preparacin y su envo al banco.
La tcnica de comprobacin bancada que permite, en este caso en concreto, cotejar los crditos de la cuenta banco en la empresa, tal y como han
sido creados a partir de la preparacin de la nmina, con los dbitos en los
extractos enviados por el banco, permite poner en evidencia este tipo de manipulacin.
P. Permite el software la creacin de la declaracin anual de los
salarios (DADS1)3?
sta debe ser enviada antes del 1 de febrero a la Seguridad Social y a la
administracin fiscal.
En lo sucesivo, ser enviada en un soporte magntico.
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 contraseas elegidas, etc.
3. DADS1 es el resumen de remuneraciones que se presenta anualmente en la Seguridad Social Francesa.
Equivale al TC2 utilizado en Espaa con periodicidad mensual.

172

Tcnicas de la auditora informtica

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 gestin del personal?
Citemos, por ejemplo:

Historial de remuneraciones.
Historial de las funciones ocupadas.
Historial de las posiciones jerrquicas.
Historial de bajas.

P. Est prevista una separacin de Junciones entre las personas


responsables del registro de los hechos que modifican la
nmina y las responsables de la preparacin y del control de la
misma?
P. Han sido satisfechas las necesidades expresadas por la
Direccin de Recursos Humanos en trminos de la gestin de
los recursos humanos (exceptundose el proceso de la
nmina)?

11.3 LA UTILIZACIN DEL SOFTWARE


DE AUDITORIA
Se podra pensar en la posibilidad de controlar la presencia de operaciones fraudulentas, por medio de la utilizacin de programas de auditora en el
campo de la nmina y de la gestin de personal. En realidad, el simple hecho
de analizar el contenido de los ficheros que conforman esta aplicacin slo
permitira detectar malversaciones groseras, pero no las operaciones ms sofisticadas.
Tomemos, por ejemplo, un caso frecuente de fraude, la creacin en el fichero de personal de asalariados ficticios. Si el que concibe la operacin es
alguien un poco ingenuo, es posible que haya domiciliado la transferencia
del sueldo del empleado ficticio en su propia cuenta. Un anlisis sistemtico
apropiado del fichero de personal (o de la cinta de remesa) detectar sin dificultad la manipulacin. Pero si nuestro defraudador ha tomado la precaucin
de domiciliar este salario en la cuenta de un cmplice que no pertenezca a la
empresa, ningn anlisis informtico podr revelar el fraude. Slo los anlisis de dossieres del personal y de las autorizaciones, complementados, si
La nmina y la gestin del personal

173

fuere el caso, por visitas al lugar de empleo, permitirn al auditor poner en


evidencia la operacin. Muy a menudo, adems, el auditor preferir comprobar la correcta aplicacin de los procedimientos de contratacin y de despido, con el fin de limitar los riesgos, ms que buscar las operaciones fraudulentas.
Hecho este prembulo, veremos, a continuacin, algunos ejemplos de
tests de auditora de la nmina y del fichero de personal, dejando claro que el
objetivo que se pretende es ms el control de la coherencia del software y de
la correcta aplicacin de los procedimientos que la bsqueda de malversaciones:
Control de la coherencia de las remuneraciones en funcin del fichero de
personal.
Bsqueda de los incrementos salariales ms significativos para asegurarse de que stos hayan sido aprobados con normalidad.
Control de coherencia de las primas pagadas en funcin del contenido
del fichero de personal.
No desarrollaremos ms estos pocos ejemplos, ya que la experiencia nos
ensea que, por lo general, su aportacin es relativamente limitada.
Citemos, por ltimo, el inters de algunos controles de uso puramente
contable, por ejemplo:
Validacin de la provisin para vacaciones pagadas. Nos preocuparemos
al 31 de diciembre, a la vez, de las vacaciones devengadas relativas al
perodo en curso, que terminar el 31 de mayo prximo, y de las vacaciones restantes a ser disfrutadas por los empleados relativas al ao anterior.
Validacin del importe de los compromisos preventivos de jubilacin
para los empleados todava activos (contablemente estos compromisos
estn en forma de provisin, o bien constan en compromisos fuera del
balance).
Validacin del importe de las primas adeudadas al personal en 31 de diciembre y no liquidadas todava.

174

Tcnicas de la auditora informtica

Captulo 12

La gestin
de las inmovilizaciones

12.1 DESCRIPCIN DE LA APLICACIN


12.1.1 Los ficheros principales
El principal fichero que constituye la aplicacin es, por supuesto, el fichero de las inmovilizaciones que contiene, si fuere el caso, algunas subdivisiones (adquisiciones del ejercicio, detalle de las amortizaciones llevadas a
cabo, etc.).
Citemos algunos de los principales elementos incluidos en este fichero:

El ttulo de la inmovilizacin.
Nmero de referencia.
Tipo de la inmovilizacin.1
Importe bruto.
Perodo de amortizacin.
Tipo de amortizacin (lineal o decreciente).
Tipo de amortizacin considerado como econmicamente justificado
(para el clculo de amortizaciones eventuales sustitutorias).
Fecha de entrega.
Fecha de puesta en marcha.
1. El tipo de la inmovilizacin permitir, entre otras cosas, un reagrupamiento de acuerdo con el plan contable.

La gestin de las inmovilizaciones

175

Fecha de inicio de amortizacin.2


Acumulado de dotaciones constatadas a partir de la adquisicin del inmueble.
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
inmovilizacin, tabla de las tasas de amortizacin, etc.
12.1.2 Los procesos principales
Las funciones principales de un software de gestin son las siguientes:
El registro interactivo de las adquisiciones y de las salidas de inmovilizaciones y la actualizacin de las fichas de inmovilizaciones existentes.
Los procesos mensuales y anuales de clculo de amortizacin en tiempo
diferido.
12.1.3 Los listados principales
Los listados resultantes de la gestin de inmovilizaciones tienen, para la
gran mayora, un inters esencialmente contable y financiero.
Los planes de amortizacin
El plan contable prev que se defina, en el momento de la adquisicin de
cualquier nueva inmovilizacin, su plan de amortizacin, o sea, en funcin
del modo y del perodo preventivo de amortizacin del bien.
Es, por lo tanto, indispensable que se prevea en cada software la edicin
de una ficha por inmovilizacin que contenga su plan de amortizacin.
La lista de adquisiciones y cesiones del perodo (mes o ejercicio)
Este listado es necesario para hacer los asientos contables apropiados.
2. En caso de amortizacin lineal, la fecha del inicio de la amortizacin es la fecha de la entrada en servicio y la primera anualidad se calcula por prorrata del nmero de das; en caso de amortizacin decreciente, la fecha de inicio de la amortizacin es la fecha de adquisicin y la primera anualidad se calcula
por prorrata a contar desde el primer da del mes de la adquisicin.

176

Tcnicas de la auditora informtica

Tratndose de las cesiones, se debe especificar el valor neto contable de


las inmovilizaciones cedidas, al igual que la plusvala o minusvala resultante.
El clculo de las dotaciones para amortizaciones del perodo
Las inmovilizaciones sern clasificadas contablemente con el objeto de
efectuar los asientos apropiados.
La periodicidad de clculo de las dotaciones ser, segn 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
inmovilizacin y por inmovilizacin, permite justificar las cuentas del inmovilizado en el balance.

12.2 LA AUDITORIA DE LA APLICACIN


Citaremos en forma de cuestionario los aspectos principales de la auditora del software.
P. Permite el software la emisin de los planes de amortizacin?
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 clculo de
la amortizacin decreciente y de la amortizacin lineal, que encontraremos
en las obras sobre contabilidad. Recordamos a ttulo ilustrativo que la amortizacin lineal corresponde a una amortizacin constante del bien durante su
perodo de vida, mientras que la amortizacin decreciente permite, para al-

3. Las nociones de revalorizacin y de amortizacin sustitutoria se aclaran en la continuacin del captulo.

La gestin de las inmovilizaciones

177

gunas inmovilizaciones, una amortizacin acelerada durante los primeros


aos.
La casi totalidad del software existente permite procesar estos dos tipos
de amortizaciones.
P. Permite el software procesar las amortizaciones sustitutorias?
La amortizacin sustitutoria, que forma parte de los activos propios de la
empresa, constituye el excedente de la amortizacin autorizada por el fisco
sobre amortizaciones econmicamente justificadas. Ms concretamente, si
se amortizan las inmovilizaciones de forma decreciente cuando la amortizacin econmicamente 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 cdigo de comercio autoriza, bajo ciertas condiciones, la revalorizacin del inmovilizado. El proceso contable de esta revalorizacin implica
que se siga la diferencia de revalorizacin resultante de esta operacin, de
donde surgen los procesos informticos apropiados.
P. Permite el software separar las adquisiciones y las cesiones,
as como las plusvalas y las minusvalas obtenidas?
Ya hemos indicado la utilidad de estas informaciones para fines contables y financieros.
P. Se ha previsto conservar para cada inmovilizacin el historial
de las amortizaciones practicadas?
Me he encontrado en varias ocasiones con software concebido para inmovilizaciones amortizadas de forma lineal, que no prevean la conservacin en el fichero del valor neto contable de los bienes. ste era recalculado
cada ao desde el valor bruto y la fecha de inicio de la amortizacin.
Esta prctica resulta bastante peligrosa en la medida en que no deja ninguna pista de las modificaciones que se producen posteriormente a la primera anualidad de amortizacin en cuanto a las modalidades de la misma
(perodo, tasa, importe bruto o modo). De este modo, conduce a una prdida
de la va de revisin, pues las dotaciones del ejercicio que incluyen una recuperacin o un complemento de las dotaciones relativas a los ejercicios anteriores, de los cuales no conserva ningn rastro, ya no se justifican.
178

Tcnicas de la auditora informtica

Es de desear, por tanto, que se conserve al final de cada ejercicio el valor


neto contable de cada inmovilizacin y, en la medida de lo posible, el detalle
de las amortizaciones anteriores.
P. Se llevan a cabo regularmente inventarios fsicos
de las inmovilizaciones?
Recordemos a ttulo de informacin, al margen de las cuestiones relativas a la auditora de la aplicacin en sentido estricto, la importancia de un inventario fsico regular de las inmovilizaciones.
Teniendo en cuenta la dificultad de una operacin de esta ndole, no obstante, es razonable que se lleve a cabo durante un perodo comprendido entre
dos y cuatro aos.
Si fuera el caso, se deben prever los listados informticos especficos
preparatorios de este inventario.

12.3 LA UTILIZACIN DEL SOFTWARE DE AUDITORIA


El desarrollo del software de auditora para los ficheros del inmovilizado
es particularmente til en el caso de una revisin de la contabilidad. De hecho, permite una validacin eficaz y exhaustiva de los clculos en aquellos
puntos en los cuales el revisor contable slo habra podido controlar de
forma manual un nmero muy limitado de fichas. Permiten, adems, dar validez a la coherencia de algunos datos existentes en las fichas.
Citaremos, a ttulo de ejemplo, los tests a tener en cuenta:
El reclculo de las dotaciones del ejercicio.
La comprobacin para cada inmovilizacin del respeto de una dotacin
acumulada por lo menos igual a la amortizacin lineal (cuando la dotacin acumulada es inferior al mnimo 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 amortizacin de
las inmovilizaciones (un error simple en la introduccin de datos puede,
en este caso, tener consecuencias financieras temibles).
El control de la coherencia de la duracin de la amortizacin.
El control de la coherencia entre la fecha de adquisicin, la puesta en explotacin y la fecha del principio de la amortizacin.
La validacin de las plusvalas y minusvalas registradas.
La gestin de las inmovilizaciones

179

Cuarta parte

LA GESTIN
DE LA AUDITORA
INFORMTICA

Hemos estudiado a lo largo de la segunda y la tercera parte de la obra los


aspectos tcnicos de la auditora de un entorno informtico y de la auditora
de una aplicacin.
Sin embargo, la capacidad tcnica del auditor, si bien es una condicin
necesaria para la calidad y para el buen fin de la misin, no es en s misma
suficiente. El xito de la misin exige, de hecho, por parte del auditor tanto
cualidades humanas y de relacin como cualidades de gestor y de organizador.
Las cualidades humanas y de relacin
Slo citaremos a ttulo de informacin estas cualidades indispensables en
todo auditor, y, en particular en el auditor de informtica, debido al carcter
tcnico de la misin.
ste deber ser, en efecto:
Un buen comercial, capaz de vender su misin. Si bien esta observacin pueda parecer una perogrullada en cuanto a los auditores externos,
en la realidad, es tambin aplicable a los auditores internos, los cuales
deben convencer a sus interlocutores de la legitimidad de la misin propuesta.
La gestin de la auditora informtica

181

Un buen diplomtico, capaz de conducir su misin en entornos algunas


veces difciles, incluso hostiles. Debe, en efecto, lograr que su presencia
sea aceptada por los informticos que se encuentran, gran parte del
tiempo, sobrecargados de trabajo y presiones por los retrasos y que, adems, dudan de la utilidad y la oportunidad de la intervencin.
Un buen pedagogo, capaz de explicar el contenido o las conclusiones de
misiones muy tcnicas a pblicos muy variados, desde el nefito ms
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 misin consiste en que su responsable haya sabido elegir
las herramientas y mtodos mejor adaptados al objetivo deseado, y que haya
planificado el conjunto de las tareas en el tiempo deseado. La gestin de la
misin no est, de hecho, exenta de dificultades y de trampas, ante las
cuales el auditor inexperto caer en falta.
stos son los principales aspectos tericos y prcticos de la gestin y de
la organizacin de la misin que mencionaremos en esta cuarta parte. Encontraremos de forma sucesiva:
Una presentacin general de la diligencia del auditor informtico.
Un enfoque de la conduccin de la misin de auditora de la funcin informtica.
Un enfoque de la conduccin de la misin de auditora de una aplicacin
informatizada.
Un estudio del perfil del auditor informtico y de los problemas relacionados con su contratacin y con su evolucin.

182

Tcnicas de la auditora informtica

Captulo 13

Presentacin general
de la gestin

A lo largo de este captulo volveremos sobre la misin general de la auditora informtica, 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 misin de
auditora informtica, 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 verificacin de que las
cuentas presentadas estn regularizadas, sean verdaderas y que proporcionen una imagen fiel de la situacin de la empresa. Su presencia es obligatoria en la gran mayora de las empresas comerciales (sociedades annimas,
sociedades en comandita por acciones, as como, ms all de unos lmites
determinados, las sociedades de responsabilidad limitada, las sociedades en
comandita simples y las sociedades colectivas) y en algunas sociedades, emPresentacin general de la gestin

183

presas o agrupaciones (GIE, sociedades civiles inmobiliarias, asociaciones,


etc.) ms all de determinados niveles.
b) El enfoque de la auditora
La gestin del auditor contable se puede resumir muy brevemente por
medio del esquema de la figura 6.

Figura 6. Presentacin simplificada de la gestin 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 dbiles y tambin
aislar los principales factores de riesgo concernientes a la fiabilidad de las
cuentas.
Los ciclos cuyo control interno sea considerado insuficiente sern objeto
de controles contables generales, mientras que los ciclos cuyo control in-

1. Los principales ciclos de la empresa son: la produccin, las compras, las ventas, la gestin del personal, la gestin de existencia, la contabilidad, la gestin de tesorera, la gestin de las inmovilizaciones.

184

Tcnicas de la auditora informtica

temo sea considerado satisfactorio pueden ser objeto tan slo de controles
contables limitados.
c) Tipologa de las intervenciones
Bajo el trmino de auditora informtica podemos imaginar tres tipos de
intervenciones por parte del auditor de cuentas, son las siguientes:
El examen del control interno de la funcin informtica. La informtica
que conduce a la produccin de diversos listados con repercusiones contables, la fiabilidad del entorno informtico en s mismo slo puede
constituir una preocupacin del auditor de cuentas.
El examen de aplicaciones informatizadas. Aqu tambin, estando la
gran mayora 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 utilizacin de la informtica para controles contables. Numerosos
asientos contables se originan, directa o indirectamente, por medio de los
sistemas informticos, algunas veces el control de las cuentas se facilita
enormemente a travs del desarrollo de software de control.
Por este motivo, los gabinetes de auditores de cuentas, por lo menos los
ms importantes, disponen de equipos de auditores informticos cuya funcin es dar asistencia a los revisores contables en el marco de sus controles,
programando software de anlisis especficos.
d) Legitimidad de la intervencin
El Plan General de Contabilidad Francs de 1982, de obligatorio cumplimiento para todas las empresas industriales y comerciales, segn decreto del
27 de abril de 1982, modificado el 9 de diciembre de 1986, legitima totalmente las intervenciones informticas del auditor de cuentas.*
1. La organizacin 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
documentacin relativa a los anlisis, a la programacin y a la ejecucin de
los procesos con vistas a proceder, entre otras cosas, a los tests necesarios.

(*) La legislacin contable espaola no contempla este tipo de disposiciones.

Presentacin general de la gestin

185

3. Los procedimientos de proceso automtico 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 nocin de proceso automatizado de las
contabilidades cubre no solamente la contabilidad general en el sentido
estricto del trmino, sino tambin generalmente los procesos ascendentes que crean los asientos contables (nmina, facturacin, 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 atae.
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 funcin informtica.
Auditora de la seguridad fsica del centro de proceso.
Auditora de la confidencialidad de acceso (en el marco de una misin
importante, se harn los tests de penetracin).
Auditora de actuaciones.
Auditora de una aplicacin.
Etctera.
Las competencias exigidas del auditor son, adems, igualmente variadas.
Tambin, la presencia de uno o varios auditores informticos puede ser
necesaria cuando se contraten misiones de auditora ms amplias, tales
como:
Auditora contable o financiera contractual (el apoyo del auditor informtico ser entonces similar al dado en el marco del auditor de cuentas).
Auditora operativa de un ciclo de la empresa (compras, ventas, tesorera, produccin, etc.). El auditor informtico 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.
186

Tcnicas de la auditora informtica

13.1.3 El auditor interno


Las misiones susceptibles de ser confiadas al auditor informtico 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 especfica, el auditor interno, que puede pertenecer tanto a la Direccin de Informtica como al servicio de auditora, se enfrenta a un problema delicado. Cmo cubrir en un
plazo razonable el conjunto de los riesgos informticos? A continuacin propondremos un esbozo de respuesta a esta pregunta (apartado 13.2).

13.1.4 El controlador fiscal


El artculo 97.1 de la ley de finanzas francesa de 1982, cuyo texto se cita
en el apartado 4.8, prev explcitamente la posibilidad para la administracin
fiscal: *
de controlar la documentacin relativa a los anlisis, a la programacin y
a la ejecucin de los procesos;
de llevar a cabo tests de control en los ficheros y software utilizados por
la empresa.
La aplicacin prctica de esta ley, a pesar de algunas precisiones aportadas por el decreto n 82-1142 de 29 de diciembre de 1982 y el artculo 103 de
la ley de finanzas de 1990 (apartado 8), levanta, no obstante, varias interrogantes tales como: Cul es el contenido de la documentacin a ser entregada
en caso de control? Cules son los ficheros y software a salvaguardar?... Las
precisiones complementarias sobre la materia estaran bienvenidas.

13.2 EL PLAN PLURIANUAL DE AUDITORIA


INFORMTICA
La definicin de un plan plurianual, que permita cubrir en un perodo
razonable (por ejemplo, del orden de 3 a 4 aos) el conjunto de los compo(*) La normativa fiscal espaola no contempla este tipo de disposiciones.

Presentacin general de la gestin

187

nentes del riesgo informtico, se plantea tanto a los auditores internos como
a los auditores de cuentas. stos tienen adems bastante inters en definir los
programas de trabajo complementarios en la materia.
Por supuesto, no es posible definir un plan de auditora tipo aplicable a
todas las empresas. Las prioridades son especficas de cada entorno. Nosotros nos limitaremos, por tanto, a proponer una cronologa lgica de las intervenciones.
Por lo general y de hecho es deseable, en el momento de una primera intervencin en un emplazamiento, proceder a un reconocimiento del entorno
y a un examen del control interno de la funcin informtica.
Esta primera intervencin permitir, en efecto, no solamente hacer un
primer diagnstico sobre la funcin informtica, sino tambin preparar las
misiones futuras en las mejores condiciones.
Durante las intervenciones posteriores, es deseable prever, en un ciclo de
algunos aos, la auditora del conjunto de las principales aplicaciones informticas. Por ltimo, se prever como necesidad, auditoras generales de ciertos campos en particular (seguridad fsica, seguridad lgica, etc.) utilizando,
si fuere necesario, empresas especializadas en alguno de estos campos.
A ttulo ilustrativo, veremos a continuacin dos ejemplos, voluntariaPlan plurianual de la intervencin del equipo de auditores informticos de
un gabinete de auditora en el marco de la auditora de cuentas de una
PYME con un emplazamiento informtico nico
Temporada2

1991/1992

Trabajos planificados
Toma de conocimiento con el entorno informtico
Examen limitado del control interno de la funcin informtica

1992/1993

Anlisis de la aplicacin de gestin de ventas y de contabilidad auxiliar


de clientes

1993/1994

Actualizacin del informe de 1992 sobre el control interno de la


funcin informtica
Anlisis de la aplicacin de gestin de existencias

1994/1995

Anlisis de aplicacin de gestin de compras y de contabilidad


auxiliar de proveedores

Nota: Las aplicaciones de gestin de las inmovilizaciones y de proceso de la nmina se han considerado
como exentas de riesgos por los revisores contables, y no dan lugar a una misin especfica.

2. La misin del auditor de cuentas es una misin 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 llevarn a cabo en el otoo de 1991, aunque el control final de las cuentas tendr lugar en el curso del primer semestre de 1992.

188

Tcnicas de la auditora informtica

Plan plurianual de la intervencin del equipo de auditora informtica


interna en un grupo empresarial con emplazamientos mltiples
Ao

Trabajos planificados

1992

Examen del control interno de la funcin informtica en la sede


en Pars.
Auditora general de informtica de la filial X
Examen limitado del control interno informtico del establecimiento de Lyon y estudio general del software de gestin de produccin de este establecimiento
Auditora general de la informtica de la filial Y
Anlisis de la aplicacin de gestin del personal en la sede
Examen general del control interno informtico del establecimiento de Lille
Estudio del conjunto de la gestin de la seguridad informtica en el
grupo.
Auditora del software de gestin de existencias del establecimiento de Lille
Auditora general de la informtica en la filial Z
Examen del control interno de la funcin informtica en la sede en
Pars (actualizacin del informe de 1992)
Estudio del conjunto de la gestin de la seguridad fsica en el grupo
(misin llevada a cabo conjuntamente con un gabinete extemo)
Auditora del software de gestin de pedidos y de facturacin del
establecimiento de Lyon

1993

1994

1995

mente simplificados, de planes plurianuales de auditora informtica, 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 auditora 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 actuacin, las misiones previstas en el plan plurianual. Adems, algunos trabajos diversos, eventualmente no indicados en el plan plurianual, se incluirn en este programa de trabajo. Se trata, por ejemplo de:
Misiones de asistencia, puntuales o recurrentes, tales como: participacin en la definicin de una nueva aplicacin (por ejemplo, bajo el nPresentacin general de la gestin

189

guio de la seguridad), participacin en talleres de tipo MARIN (apartado 4.1).


Trabajos especficos realizados por los auditores informticos en el
marco de misiones de auditora operativa o de auditora financiera.
En esta pgina y en la siguiente sealaremos a ttulo informativo los planes anuales correspondientes a los planes plurianuales del apartado 13.2.
Nota: Las cargas de trabajo que aparecen en estos ejemplos son meramente indicativas. Volveremos con ms detalle en los captulos 14 y 15 sobre la estimacin del volumen de trabajo a prever en el marco de las misiones de auditora.

Plan anual del equipo de auditores informticos en el marco


de una auditora de cuentas en una PYME (Temporada 91-92)
Fecha
Octubre
1991

Carga de trabajo
(en jornadas-hombre)

Naturaleza de la actuacin

Toma de conocimiento con el entorno


informtico
Examen limitado del control interno de
la funcin informtica

Diciembre Preparacin y test de software de


auditora aplicable al fichero de las
1991
inmovilizaciones, para analizar los resultados
en el marco de los trabajos de control de las
cuentas
Marzo
1992

Ejecucin de software de auditora


relativo al fichero de las inmovilizaciones al
final de 1991

13.4 LAS HERRAMIENTAS DEL AUDITOR


INFORMTICO
Repetimos aqu dos tipos de herramientas importantes, de las cuales
puede disponer el auditor informtico en el marco de su actividad:
190

Tcnicas de la auditora informtica

Plan anual del equipo de auditora informtica interna


(2 auditores) del Grupo para 1992
Fecha

Naturaleza de la actuacin

Carga de trabajo
(en jornadas-hombre)

Enero
a marzo

Examen del control de la funcin


informtica en la sede

60

Abril
a mayo

Participacin de un auditor en la
misin de auditora de la gestin de
la tesorera del grupo

40

Abril
a julio

Auditora general de la informtica en


la filial X

80

Septiembre Ejemplo limitado del control interno


a
informtico del establecimiento de Lyon y
diciembre estudio general del software de gestin de
produccin de este establecimiento

80

A partir Participacin en un grupo de trabajo


de
Seguridad, en el marco de la creacin
septiembre de una nueva aplicacin de gestin de
aprovisionamiento del Grupo

20

Enero a Participacin en un taller MARIN sobre la


diciembre seguridad informtica

10

Noviembre Participacin de un auditor en una misin


diciembre de auditora contable de una filial

20

Formacin de los auditores informticos

20

Potencial disponible para misiones


excepcionales no planeadas

70

Los mtodos de anlisis de riesgos informticos.


El software de auditora.
13.4.1 Los mtodos de anlisis de riesgos informticos
Existen en el mercado diferentes mtodos cuyo objetivo es suministrar
una evaluacin global de la seguridad y de los riesgos informticos en el
seno de una empresa.
Presentacin general de la gestin

191

Entre ellos el ms conocido es, sin lugar a dudas, el mtodo MARIN,3


elaborado por el CLUSIF (Club de la Seguridad Informtica Francesa) emanado de la APSAIRD (Asamblea Plenaria de Sociedades de Seguros contra
el Incendio y los Riesgos Diversos).
Citemos igualmente el mtodo MELISA, desarrollado para la defensa
nacional.
Estos mtodos tienen todos en comn el suministro de:
Un cuestionario detallado de la evaluacin del riesgo: cada pregunta
da lugar a una anotacin del entorno estudiado.
Una presentacin clara de los resultados de la evaluacin, generalmente despus de la introduccin de las respuestas al cuestionario en un
microordenador y del proceso de los resultados.
Podemos citar para ilustrar esta facilidad el clebre rosetn de presentacin de los resultados de un taller MARION (figura 7). Cada campo que lo
conforma recibe, despus de procesar los resultados del cuestionario detallado, una nota global comprendida entre 0 (nivel de riesgo mximo) y 4 (seguridad mxima), y las calificaciones obtenidas por cada campo se representa en un rosetn.
Si nos fijamos bien, existen, no obstante, diferencias notables entre estos
mtodos de evaluacin del riesgo. De este modo, MARION no es un mtodo
de auditora, sino ms bien un mtodo de autoevaluacin del riesgo por parte
de los propios informticos y usuarios. La buena evolucin de un taller MARIN necesita, sin embargo, la presencia de un animador que conozca perfectamente el mtodo. Esta es la razn por la cual la gran mayora de las empresas que efectan un taller MARION recurren a la asistencia, aunque de
forma puntual, de un gabinete de asesores externos.

13.4.2 El software de auditora


Ya hemos mencionado en la primera parte de la obra (ver apartado
1.3.4 d) la utilizacin por parte de los auditores de lenguajes de interrogacin de ficheros, a veces llamados errnea o acertadamente, programas de
auditora.
Encuentran su utilidad en la gran mayora de las misiones confiadas al
auditor informtico. De este modo:

3. Metodologa de Anlisis de Riesgos Informticos y de Optimizacin por nivel.

192

Tcnicas de la auditora informtica

Figura 7. Ejemplo de representacin de evaluacin de la seguridad


de un entorno informtico segn el mtodo MARIN.

En el marco de una auditora de aplicacin, permiten controlar el contenido de los ficheros y detectar anomalas eventuales.
En el marco de la asistencia a la revisin contable, permiten validar los
resultados de algunos procesos, o tambin poner en evidencia las informaciones anmalas o errneas.
Volveremos posteriormente en el captulo 15 sobre las modalidades prcticas de la utilizacin de los programas de auditora.
Presentacin general de la gestin

193

PRESENTACIN SIMPLIFICADA DEL MTODO MARIN


El mtodo MARIN comporta seis etapas:
El anlisis de los riesgos tiene como objetivo el recuento de los riesgos y la
evaluacin del coste mximo de prdidas consecutivas a cada riesgo enumerado.
La expresin del riesgo mximo admisible permite definir, de acuerdo
con la Direccin de la empresa, el nivel crtico a partir del cual el riesgo ya
no es admisible.
El anlisis de la seguridad existente, basada en las respuestas a un cuestionario de evaluacin, establece una sntesis del riesgo en que se incurre
en la forma del clebre rosetn (figura 7).
La evaluacin de los inconvenientes permite tener en cuenta lo existente
en el anlisis de los riesgos y la definicin de las soluciones: inconvenientes
tcnicos, humanos.
La eleccin de los medios define los medios a aplicar para mejorar la seguridad de manera coherente.
La definicin del plan de seguridad define las modalidades prcticas segn las cuales la seguridad ser mejorada.
A FAVOR O EN CONTRA DE MARIN?

Los argumentos a favor o en contra del lanzamiento de talleres de anlisis del


riesgo de tipo MARIN estn ampliamente desarrollados en la obra Les techniques
de l'organisation informatque. Citaremos aqu algunos de una forma simplificada.
A FAVOR:
El lanzamiento de un taller de tipo MARIN permite estar seguro de contar con un soporte metodolgico.
Un taller de anlisis del riesgo permite sensibilizar al conjunto de los actores, tanto informticos como usuarios, sobre el problema de la seguridad.
La atribucin de notas tiende a fundamentar la evaluacin del riesgo en
criterios objetivos.
EN CONTRA:
Los talleres de anlisis llevan a menudo a una autoevaluacin del riesgo
por parte del personal de la empresa, por lo que es difcil creer que sea del
todo objetiva.
Si bien tales talleres aportan, por lo general, una buena apreciacin de la
candad del control interno de la funcin informtica, permiten con mucha
ms dificultad apreciar la fiabilidad de las aplicaciones.
La aplicacin de una misin de este tipo es a menudo costosa, tanto en trminos 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 aplicacin de un taller de tipo
MARIN ser an ms til cuando el personal est insuficientemente sensibilizado con los problemas de seguridad informtica.
194

Tcnicas de la auditora informtica

Captulo 14

La direccin de la
misin de auditora

Recordaremos a lo largo de este captulo las modalidades prcticas de la


direccin de una misin de auditora informtica, poniendo en evidencia las
etapas que deben necesariamente ser respetadas en la intervencin y los
principales problemas prcticos que pueden surgir en el curso de cada una de
estas etapas.
Adems, si bien se puede considerar que existe una metodologa general
de intervencin, cualquiera que sea la naturaleza exacta de la misin, no sern menos las peculiaridades importantes segn el tipo de objetivo. De este
modo, los mtodos de investigacin propios de una auditora pueden ser bastante diferentes de los mtodos de investigacin propios del examen del control interno de la funcin informtica. Cada tipo de intervencin ser objeto
de desarrollos especficos.

14.1 LA PREPARACIN DE LA MISIN


Es difcil definir una norma en cuanto a la duracin y a las modalidades
prcticas exactas de la fase de preparacin de la misin. De este modo, una
auditora externa tendr como objetivo, por razones comerciales, fijar lo ms
rpidamente posible una primera propuesta de intervencin, con el riesgo de
prever en la misma una fase de investigaciones previas a partir de la cual se
fijarn los lmites de la misin.
La direccin de la misin de auditora

195

En cambio, un servicio de auditora interna, libre de la obligacin financiera relativa a la incertidumbre en cuanto a la aceptacin o no de una propuesta, podr preferir, segn sea el caso, una fase de estudio preliminar relativamente extenso, con el fin de llegar a una propuesta de intervencin lo
ms precisa y completa posible, o bien, una fase preliminar extremadamente
corta, con una propuesta de intervencin lo ms abierta posible.
Esto no quiere decir que algunos trabajos preparatorios sean indispensables para el buen desarrollo de la misin. De una manera general, se trata del
conjunto de las investigaciones necesarias para la elaboracin de dos documentos previos al inicio de la misin, 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 intervencin
Este documento materializa el acuerdo entre el que solicita la misin (a
menudo la direccin general de la empresa) y el que la tiene que ejecutar
(auditora externa o auditora interna) sobre el contenido y las modalidades
prcticas de la misin. Legitima, adems, la intervencin ante los servicios
auditados. Estudiemos ahora las principales incertidumbres que deben ser
eliminadas por medio de este documento.
a) Los objetivos de la misin
Hemos mostrado en la primera parte de la obra que los objetivos que se
buscan en una misin de auditora informtica podran ser muy variados, tales como: examen del control interno de la funcin informtica, examen de
la seguridad fsica, auditora de las protecciones de acceso, control de los
mtodos de desarrollo, auditora de las actuaciones, auditora de una aplicacin especfica, etc.
La propuesta de intervencin deber, por tanto, eliminar cualquier ambigedad aclarando los objetivos a que se destina.
b) El permetro de la misin
La propuesta de intervencin definir claramente las empresas y establecimientos y los emplazamientos correspondientes para los trabajos. En el
caso de una auditora de aplicacin, sern las funciones auditadas las que se
autodefinirn.
196

Tcnicas de la auditora informtica

c) El perodo de intervencin
Se especificarn aqu la duracin global de la misin y sus plazos principales (fecha de inicio y fin de los trabajos, etapas intermedias, fecha de envo
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 misin, la
disponibilidad que ser exigida a los servicios auditados. La sobrecarga de
trabajo demasiado elevada causada por una auditora es, a menudo, objetada
por stos, por error o con razn, y es, tambin, la causa de relaciones difciles.
En el caso de utilizar software de auditora, los inconvenientes especficos deben ser previstos tambin por los servicios auditados. Volveremos sobre este tema en el captulo 15.
De la misma manera, la aplicacin del juego de prueba necesita, la mayora de las veces, un trabajo preparatorio importante.
e) Los mtodos de trabajo empleados
La definicin detallada de los mtodos de trabajo empleados es ms bien
de incumbencia del programa de trabajo, documento interno, que de la propuesta de intervencin. No obstante, es deseable especificar, por lo menos a
grandes rasgos, estos mtodos de trabajo: utilizacin o no de cuestionarios,
mtodos basados en las entrevistas o en el estudio de documentos, aplicacin de juegos de prueba, utilizacin de software, etc.
f) La formacin del equipo
La composicin del equipo y el nombre del responsable de la misin sern especificados aqu. En el caso de misiones importantes de auditora 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 misin, una lista de documentos preparatorios a ser suministrada a los auditores ser, si fuera el caso,
incluida en las propuestas de intervencin, o transmitidas a los servicios
auditados previamente a la primera entrevista. stos sern, por ejemplo:
La direccin de la misin de auditora

197

Para un examen del control interno de la funcin informtica


- El organigrama del servicio.
- La descripcin de la configuracin fsica.
- Una descripcin sucinta del software utilizado.
- La lista de los programas.
- Las notas principales relativas a la actividad informtica en la empresa
y a la organizacin del servicio.
- El plan informtico.
- El presupuesto del servicio informtico.
- Los informes de las ltimas reuniones del comit de informtica.

Para una auditora de una aplicacin informatizada

El organigrama del servicio y la lista de los principales interlocutores a


encontrar (usuarios e informticos).
Los documentos de presentacin de la aplicacin.
Si fuera el caso, la descripcin del contenido de algunos ficheros en los
cuales se espera realizar controles.

Programa de trabajo de la misin de auditora del software de gestin del


personal por parte del auditor de cuentas en un entorno PYME (presupuesto
80 horas)
Lanzamiento de la misin

4 horas

Toma de conocimiento de la aplicacin: entrevistas con el jefe de proyecto y con los principales
usuarios, lectura de la documentacin disponible
Anlisis crtico de las prestaciones de la aplicacin (vase cuestionario estndar)
Examen del control interno de la funcin informtica para esta aplicacin: procedimientos de
desarrollo y explotacin, anlisis de la documentacin, etc. (vase cuestionario estndar)
Desarrollo de software de auditora (prestaciones a ser definidas en el momento de la toma de
conocimiento de la aplicacin) y anlisis de los
resultados
Redaccin del informe y sntesis

198

16 horas
8 horas

16 horas

20 horas
16 horas

Tcnicas de la auditora informtica

14.1.2 El programa de trabajo


El programa de trabajo define claramente los mtodos de auditora elegidos y el trabajo a realizar por parte de los auditores.
Contiene una divisin de las cargas de trabajo previstas para cada mdulo de auditora.
En el recuadro que aparece al final de la pgina anterior se incluye un
ejemplo de programa de trabajo resumido de una misin de auditora de aplicacin.
En el prximo apartado trataremos la eleccin de los mtodos de investigacin, y de la carga de trabajo necesaria para llevar a cabo el conjunto de las
tareas previstas.

14.2 LOS MTODOS DE INVESTIGACIN


Distinguiremos en este campo la auditora del control interno de la funcin informtica y la auditora de una aplicacin informatizada. Pero antes
que nada, sin ningn lugar a duda, vale la pena recordar brevemente las caractersticas generales de la metodologa en materia de auditora del control
interno.
14.2.1 La gestin general de la evaluacin
del control interno
Veremos en la figura 8 una presentacin esquemtica del enfoque de evaluacin del control interno.
La toma de conocimiento y el anlisis de los procedimientos del sistema
evaluado permiten evidenciar sus puntos fuertes y dbiles tericos. De todos
modos, un punto fuerte terico slo 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 aplicacin del procedimiento
terico.

La direccin de la misin de auditora

199

Figura 8. Evaluacin del control interno.

14.2.2 La evaluacin del control interno


de la funcin informtica
a) La evaluacin de los puntos fuertes y dbiles tericos
El anlisis de los procedimientos, necesario para una primera evaluacin
de las fuerzas y debilidades del sistema, se har esencialmente a travs de:
Entrevistas a los responsables del servicio de informtica y, por lo general, a los principales servicios de usuarios.
Un trabajo sobre el conjunto de los documentos disponibles en el servicio:
plan informtico, normas internas, organigramas, plan de seguridad, etc.
200

Tcnicas de la auditora informtica

Los cuestionarios de auditora 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 evaluacin 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 validacin sistemtica de sus conclusiones. No es cuestin de describir aqu los procedimientos
de validacin para cada punto auditado. stos surgen, la mayora de las veces, de s mismos.
Sin embargo, a ttulo de informacin, encontraremos en el cuadro que se
expone a continuacin ejemplos de un programa de validacin de las
respuestas a algunas de estas cuestiones descritas en la segunda parte de la
obra.

EJEMPLO DEL PROGRAMA DE VALIDACIN DE LAS CONCLUSIONES


EN MATERIA DE CONTROL INTERNO DE LA FUNCIN INFORMTICA
A continuacin veremos ejemplos de un programa de trabajo para la validacin de las respuestas a algunas preguntas relativas al examen del control
externo de la funcin informtica.
La organizacin general del servicio de informtica
Pregunta: Hay un plan informtico?
Validacin: Obtener una copia del plan informtico
P.: Se hace un seguimiento de la actividad del personal de informtica?
V.: Controlar las fichas de actividad ms recientes de algunos colaboradores
del servicio de informtica.
P.: Cualquier eleccin de prestacin material (equipos) o de software da lugar a un concurso pblico?
V.: Pedir los concursos y el anlisis de las ofertas para las ltimas adquisiciones ms significativas.
Los procedimientos de desarrollo y de mantenimiento de las aplicaciones
P.: Se elabora siempre un pliego de condiciones previo al lanzamiento de la
realizacin de nuevo software?
V.: Pedir los pliegos de condiciones de las ltimas aplicaciones puestas en explotacin.
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 coordinacin suficiente?
V.: Pedir los informes de reunin de los grupos de trabajo encargados de la
coordinacin.

La direccin de la misin de auditora

201

El entorno de produccin
P. : Son satisfactorios los procedimientos de puesta en explotacin 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 sistemticamente 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 ficheros intiles?
V. : Seleccionar algunos ficheros que figuren en el espacio disco y asegurarse
de que todava estn en uso.
P. : Se salvaguardan con regularidad el conjunto de los ficheros y software
necesarios para el desarrollo y la explotacin?
V. : Seleccionar algunos ficheros en una o varias aplicaciones y asegurarse de
que exista una versin de seguridad.
P. : Cuando la cantidad lo justifique, hay un software de gestin 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), despus seleccionar algunas cintas de los lugares de almacenaje y verificar si estn 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 auditora de la aplicacin


Hemos citado en la primera parte de la obra la diversidad de los objetivos
que se busca en el marco de una auditora de aplicacin y que son:
Auditora de la adecuacin del software desarrollado a las necesidades
especificadas en el pliego de condiciones.
Auditora de la adecuacin del pliego de condiciones a las necesidades
de un control interno satisfactorio (posibilidad de controles jerrquicos
y de una separacin de funciones, continuidad de la va de revisin, etctera).
Auditora de la adecuacin del pliego de condiciones a las necesidades de
una gestin eficaz (se verificar que todas las prestaciones necesarias para
la optimizacin de la actividad de los usuarios hayan sido previstas).
Auditora de la utilizacin del software (se verificar, por ejemplo, que
los controles de explotacin adaptados hayan sido aplicados, que las protecciones de acceso previstas sean efectivas, etc.).
Auditora de la calidad tcnica de los mtodos de desarrollo empleados y
del software realizado.
202

Tcnicas de la auditora informtica

Auditora del control interno de la funcin informtica para esta aplicacin (calidad del software, los procedimientos de explotacin).
Etctera.
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 continuacin:
La entrevista
Adems de las entrevistas con los responsables del desarrollo y de la explotacin de la aplicacin, se programarn igualmente entrevistas con los
principales usuarios involucrados.
Los controles de la documentacin
Segn los objetivos exactos de la misin, harn referencia, por ejemplo, a:
Los documentos previos al desarrollo de la aplicacin (esquema gua, estudio previo, estudio detallado).
La documentacin de estudio.
La documentacin de explotacin.
Los manuales para los usuarios.
Los manuales de procedimientos.
Los programas mismos.
No obstante, notaremos que, salvo estudio a fondo, el auditor, la mayora
de las veces, slo podr pronunciarse sobre el aspecto formal de estos documentos, pero no sobre el fondo de su contenido.
Juegos de prueba
Esencialmente permiten controlar la adecuacin del software desarrollado en el pliego de condiciones. En cambio, no aportan ninguna ayuda a la
evaluacin de la calidad del pliego de condiciones.
Adems, 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 auditora
Los programas permitirn llevar a cabo los controles:
La direccin de la misin de auditora

203

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 ms o menos similares.
Si bien no permiten pronunciarse sobre la fiabilidad del conjunto de la
aplicacin, por lo menos suministran los resultados concretos. Las anomalas eventualmente detectadas son, en este sentido, indicadores valiosos.
El captulo 15 estar dedicado en particular a la utilizacin del software
de auditora.
La realizacin de cdigos de control de los procesos
Si bien el diseo de estos cdigos 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 VALORACIN JDEL VOLUMEN


DE INTERVENCIN
La apreciacin de la carga de trabajo a tener en cuenta para realizar la misin presenta el problema crucial de la necesidad de un compromiso entre la
bsqueda de un coste de intervencin mnimo y la realizacin de unas investigaciones lo ms completas posibles.
De antemano, conviene tener bien claro que, aunque la carga de realizacin de una aplicacin, que responda a las necesidades claramente definidas
en un pliego de condiciones, es fija e incompresible, la carga de realizacin
de una auditora informtica est en funcin del programa de trabajo y puede
tambin modularse, por lo menos dentro de ciertos lmites.
El objeto de este apartado es definir los dos lmites razonables:
Un lmite inferior por debajo del cual es razonablemente imposible llevar a cabo una apreciacin motivada.
Un lmite superior ms all del cual la aportacin marginal de las investigaciones complementarias a las conclusiones de la auditora es demasiado limitada para que tengan algn inters.
204

Tcnicas de la auditora informtica

a) Examen del control interno de la funcin informtica


Veremos en el cuadro que sigue una estimacin bastante indicativa de las
cargas de trabajo a tener en cuenta para una misin general de examen del
control interno de la funcin informtica.

Cargas de trabajo indicativas para el examen del control interno


de la funcin informtica
Pequeo centro
de proceso1

Centro de
proceso de
porte medio2

Examen limitado
del control interno
de la funcin
informtica

2-3 d

5-7 d

8-10 d

Examen normal
del control interno
de la funcin
informtica

5-7 d

10-12 d

15-30d

Examen completo
del control interno
de la funcin
informtica

10-15 d

20-30 d

40-80 d

Gran centro
de proceso3

1. Se consideran pequeos 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 ms de 100 personas o el presupuesto
sea superior a 1.500.000 PTA.

Esta estimacin no incluye, sin embargo, instrucciones completas eventuales sobre los aspectos especiales (estudio de la seguridad fsica, estudio
de las protecciones de acceso con tests de penetracin, estudio de las actuaciones, etc.), las cuales pueden presentar cada una de ellas varias decenas de
das de trabajo.
Debe ser, adems, manipulada con prudencia. En efecto, la carga de trabajo, independientemente de la magnitud del centro, depende de varios parmetros, como por ejemplo: permetro exacto de la misin, procedimientos de
validacin, calidad y acabado del informe, etc.
La direccin de la misin de auditora

205

b) Auditora de una aplicacin


Veremos en el cuadro siguiente una estimacin, igualmente bastante indicativa, de las cargas de trabajo que se deben tener en cuenta para una misin de auditora de aplicacin.

Estimacin indicativa de la carga de trabajo de una auditora de aplicacin


Pequea
aplicacina

Aplicacin
mediab

Aplicacin
importantec

Examen limitado
de la aplicacin1

2-3 d

5-7 d

8-10d

Auditora normal
de la aplicacin2

5-10d

10-15 d

20-30 d

Auditora 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 documentacin, as como de un anlisis muy sucinto de las principales funcionalidades. Se basa esencialmente en las entrevistas y en un control directo de la documentacin.
2. La auditora normal debe permitir un control formal relativamente profundo, acompaado de una
revista de las principales funcionalidades.
3. La auditora profunda utilizar tcnicas de control ms sofisticadas que las entrevistas y los controles
directos: desarrollo de software de control, juego de prueba.
a) Se considera pequea una aplicacin cuya carga de desarrollo sea inferior a 100 d x h.
b) Se considera mediana una aplicacin cuya carga de desarrollo est entre 100 y 500 d x h.
c) Se considera importante una aplicacin cuya carga de desarrollo sea superior a 500 d x h.

Si bien esta estimacin debe ser tambin manipulada con prudencia, no


obstante, es innegable que la auditora de una aplicacin constituye una operacin costosa para una eficacia desigual.
Los mtodos de investigacin, al igual que el nivel del detalle de las tareas planificadas, tambin se deben definir con cuidado.

14.4 LA PRESENTACIN DE LAS CONCLUSIONES


El final de la misin de auditora se materializa, por lo general, con una
presentacin contradictoria con los servicios auditados de las principales
conclusiones, seguido de la emisin de un informe. Adems de un anlisis
206

Tcnicas de la auditora informtica

crtico, es deseable que el informe aporte una sntesis 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 aplicacin de las recomendaciones formuladas por ellos. Este seguimiento se podr, entre otras
cosas, asegurar:
bien a travs de una participacin regular en las principales reuniones de
sntesis relativas al avance de los trabajos;
o bien, a travs de la realizacin de misiones breves de actualizacin del
informe.

La direccin de la misin de auditora

207

Captulo 15

La utilizacin de los
programas informticos
de auditora

Hemos citado en varias ocasiones a lo largo de la obra el desarrollo, por


parte de los auditores, de programas informticos especficos de control en
el marco de su misin.
El presente captulo constituye una sntesis relativa a la utilizacin de
esta tcnica, dejando claro por supuesto que, incluso cuando utilizamos el
trmino software de auditora, el lenguaje de programacin empleado no
es necesariamente un lenguaje dedicado a los auditores y puede ser una herramienta de infocentro, incluso un lenguaje de programacin tradicional.
En los entornos especficos, he tenido que desarrollar en varias ocasiones
software de auditora en COBOL.

15.1 LOS OBJETIVOS DEL DESARROLLO DE UN


SOFTWARE DE AUDITORIA
Distinguiremos estos objetivos segn se trate:
De una misin de auditora de aplicacin.
De la asistencia a la auditora contable, campo en el cual se aprecia en
particular el aporte del software de auditora.
208

Tcnicas de la auditora informtica

15.1.1 Desarrollo de un software de auditora en el


marco de una misin de auditora de
una aplicacin informatizada
Los objetivos que se buscan sern 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 aplicacin
los datos dudosos, susceptibles de detectar anomalas en el software o en
la aplicacin de los procedimientos.
Citemos algunos ejemplos simples:
En un software de control de existencias, seleccin de existencias negativas en el inventario informtico permanente. Unas existencias negativas
traducen un error del software, o un error en la introduccin de datos, o
tambin una mala aplicacin de los procedimientos (registro de una salida antes del registro de una entrada, la cual era cronolgicamente previa a sta).
En un software de facturacin, seleccin de facturas para las cuales los
artculos hayan sido facturados a un precio diferente del que aparece en
el fichero de lista de precios: otra vez veremos la seal, en caso de diferencias importantes no justificadas por condiciones especiales concedidas voluntariamente al cliente, bien de un error en la introduccin de datos, o bien, de un error de programacin del software.
En un software de gestin comercial, seleccin de los clientes que tengan
descuentos superiores a ciertas normas, que puedan proceder de anomalas en la introduccin 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 aplicacin
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 tambin 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 aplicacin.
La utilizacin de los programas informticos

209

Desarrollo de un software que tenga las mismas funciones


Esta tcnica slo puede ser utilizada de una manera puntual, y para una
prestacin en particular. En el caso contrario, conducir a una segunda redaccin de la aplicacin auditada, con las consecuencias que podemos imaginar en la duracin y el coste de la auditora.
De este modo, podemos imaginar:
El reclculo del importe de las existencias valoradas a partir del fichero
de inventario.
El reclculo del total de los crditos de clientes superiores a 6 meses, a
partir del fichero de cuentas de clientes.
El reclculo de la dotacin 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 auditora cuyas prestaciones sern ms
sencillas que las del software auditado, pero cuyos resultados darn elementos de comparacin.
Citamos por ejemplo:
Una estimacin para un mes dado de la masa salarial neta, a partir del fichero de personal y de una evaluacin 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 estimacin de la cifra de negocios del mes partiendo de las facturas
emitidas en el mes.
15.1.2 La asistencia a la revisin contable
Se puede manifestar:
En el marco de las tareas denominadas interinas, realizadas durante el
ejercicio, en particular cuando stas se refieren a la valoracin 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.
210

Tcnicas de la auditora informtica

El software de anlisis del contenido de los ficheros


El objetivo ser poner en evidencia las anomalas existentes en el contenido de los ficheros, como en el caso de la auditora de aplicacin, o bien, los
datos significativos por su importancia que necesitan un anlisis complementario.
As, en un software de gestin de prstamos, en un establecimiento financiero, se separan todos los prstamos superiores a un cierto nivel para
analizar en el dossier las condiciones de concesin de este prstamo.
El software de validacin de los resultados obtenidos de la aplicacin
con una incidencia contable directa
Se intentar tambin dar validez dentro de la aplicacin de control de existencias a la valorizacin del inventario al cierre, al clculo de las diversas provisiones (provisin para rotacin lenta, provisin para la subida de los precios), al valor de las mercancas recibidas y no facturadas por el proveedor, etc.
El software que tenga como nica funcin la automatizacin del trabajo del revisor contable
Citemos, por ejemplo:
El envo de las cartas circulares a algunos clientes.
La automatizacin de los procedimientos de muestreo previos a los controles de los documentos.

15.2 LA ELECCIN 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 hiptesis. Ella le permitir
trabajar con la herramienta escogida por l mismo y que estar mejor adaptada 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 hiptesis, cuyo trabajo preparatorio previo a
la misin (instalacin del software, copia de algunos ficheros, etc.) no ser
tan importante, ser a menudo la preferida por el auditado.
La utilizacin de los programas informticos

211

Como conclusin, podemos considerar que es preferible que el auditor


disponga de su propio software, salvo en caso de inconvenientes tcnicos 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 auditora interna en
un entorno de emplazamiento nico, el software elegido podr ser instalado
definitivamente en el equipo, evitando as el problema de su instalacin y
desinstalacin sucesiva. Si fuere el caso, el servicio de auditora podr, adems, elegir por su propia cuenta el o uno de los lenguajes de infocentro puestos a disposicin de los usuarios.
*

En el caso de la eleccin por parte del equipo de auditora de un software


especfico, nos queda estudiar los principales criterios de esta eleccin. stos estarn relacionados con las caractersticas tcnicas del software, con las
modalidades prcticas de la utilizacin que se piensa realizar, y, claro est,
con las condiciones financieras propuestas.
Lenguaje descifrado o lenguaje compilado?
En un lenguaje descifrado, las instrucciones programadas sern analizadas por el intrprete en cada ejecucin del programa. Por el contrario, en un
lenguaje compilado, el programa-fuente (en lenguaje de programacin) se
transforma por medio del compilador en lenguaje-objeto (lenguaje mquina). La ejecucin 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.
Tratndose del auditor, si slo desea hacer el lanzamiento de las peticiones ocasionales y no repetitivas, la distincin entre los intrpretes y los compiladores no ser determinante en la eleccin. En cambio, si las peticiones se
tienen que ejecutar regularmente, y a fortiori deben comportar volmenes de
fichas importantes, es imprescindible orientarse hacia la eleccin de un compilador, para economizar el consumo de los recursos mquina.
Generador de programa o no?
Algunos lenguajes de programacin rpida son en efecto generadores de
programas, o sea, que crean las instrucciones en un lenguaje de programacin tradicional (COBOL, GAP, FORTRAN), y el programa creado es compilado a continuacin.
212

Tcnicas de la auditora informtica

La evolucin futura deber tender a la desaparicin de los generadores de


programa, en provecho de lenguajes compilados directamente sin pasar por
una etapa intermediaria. Sin embargo, hoy da, la adquisicin de un software
de tipo generador de programa no debe ser rechazada a priori.
Software ejecutado en unidad central o en microordenador?
Esta cuestin no habra tenido ningn sentido hace algunos aos. Las posibilidades de los microordenadores, ya sea en trminos de potencia del microprocesador o de capacidad de almacenamiento en el disco, eran insuficientes para permitir la ejecucin de software de anlisis de ficheros.
En la actualidad, es totalmente al revs. La gran mayora de los proveedores de lenguajes de auditora o de infocentro proponen un software que
funciona en microordenador, despus 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 econmicas (el consumo de medios
est totalmente controlado) y fciles. Deberan ser repetidas durante los prximos aos.
La alternativa principal debera residir en el desarrollo de equipos compartidos entre diferentes usuarios, pero totalmente dedicados al infocentro y
a las consultas ocasionales.
Lenguaje orientado hacia los informticos o lenguaje
orientado hacia los usuarios?
Aun cuando todos los distribuidores que velan por la promocin de lenguaje de infocentro (por lo tanto destinado a los usuarios), califican los lenguajes de lenguaje de cuarta generacin (L4G), o tambin lenguaje de software de auditora, 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 categoras:
Lenguajes de programacin rpida, esencialmente destinados a los informticos.
Lenguajes destinados a los usuarios, particularmente adaptados para peticiones sencillas.
Los lenguajes de programacin rpida ofrecen funciones casi anlogas a
las de los lenguajes tradicionales, con un nmero reducido de instrucciones. Son, adems, algunas veces utilizados como software de desarrollo de
aplicacin. Su principal inconveniente, relacionado con la concisin del lenLa utilizacin de los programas informticos

213

guaje, estriba en la dificultad para los usuarios de controlar bien la programacin de los casos ms complejos. La experiencia nos ensea que la puesta
a disposicin de los usuarios no informticos de tales herramientas acaba, la
gran mayora de las veces, en problemas. En cambio, los informticos las
prefieren, porque les permiten llevar a cabo desarrollos puntuales con una
gran rapidez.
Por el contrario, los lenguajes orientados a los usuarios se preferirn para
peticiones especialmente sencillas, pero rpidamente surgirn sus limitaciones a partir del momento en que la necesidad alcanza un cierto nivel de complejidad.
Tratndose del auditor, podremos considerar que:
Cuando el software est destinado a auditores informticos con experiencia como realizador de aplicaciones, es preferible recurrir a un lenguaje de programacin rpida.
Cuando el software est destinado a ser utilizado por los auditores no especializados en informtica, la eleccin de un lenguaje orientado al
usuario es imperativo.
Software destinado especficamente a los auditores o no?
Algunos software de programacin rpida son bautizados, algunos sin
mucha originalidad, como software de auditora por la existencia en los mismos de algunas rutinas (subprogramas) destinadas muy particularmente a
los auditores, tales como: muestreo, funciones estadsticas, etc.
La presencia de estas rutinas no siempre es una ventaja determinante,
y el auditor pondr todo su inters en comprobar, caso por caso, su utilidad...
Ms an cuando estas funciones especializadas son a menudo objeto de una
facturacin complementaria por parte del proveedor y, lo que es ms, en su
gran mayora muy raramente son utilizadas y no siempre han sido probadas
como deberan.
El coste del software
El coste del software puede revelarse muy heterogneo de un producto al
otro, y variar notablemente entre los lenguajes de interrogacin en microordenadores, por ejemplo, y el software para grandes sistemas.

214

Tcnicas de la auditora informtica

15.3 LAS PRINCIPALES FASES DE LA INTERVENCIN


El desarrollo de software de auditora, que representa en s una actividad
relativamente simple que no requiere un gran nivel tcnico, es innegablemente para el auditor de informtica el campo ms cargado de trampas.
Recordaremos adems, que si bien el auditor, por lo general, tiene en su actividad una funcin de mediador, el auditor informtico, en este caso en especial, tiene una funcin de resultado basndose en los tests que se comprometi a llevar a cabo.
Cualquier misin de desarrollo de software de auditora es, por tanto,
cuidadosamente preparada y planificada. Desde esta ptica, veremos a continuacin una presentacin de las principales fases de la intervencin.
a) El pliego de condiciones del software de auditora a ser desarrollado
La definicin del software a desarrollar implica a menudo varios actores:
El servicio de informtica: si la definicin del test concierne esencialmente al personal de estudio (que suministrar la documentacin de la
aplicacin y las descripciones de los ficheros), es igualmente deseable
que el personal de explotacin sea informado.
Los servicios de usuarios: son ellos los que conocen mejor las prestaciones de la aplicacin auditada y el contenido de los ficheros.
El auditor informtico: es el que redactar el pliego de condiciones de los
tests.
Por ltimo, es frecuente que el auditor informtico slo intervenga en
apoyo tcnico por cuenta de un responsable de misin.
El pliego de condiciones, que define exactamente los tests que se espera
llevar a cabo, permitir materializar la comprensin 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 auditora
De un modo general, es indispensable, por razones de seguridad, que los
auditores trabajen con copias de los ficheros de explotacin, salvo que el
software de proteccin de acceso permita tener absoluta garanta de que slo
se puedan hacer consultas. De hecho, he vivido el caso del auditor que destruye por descuido la cinta de seguridad que le haba sido confiada para analizar. Incluso cuando, en este caso, el servicio de informtica fuese por lo
La utilizacin de los programas informticos

215

menos tan responsable como el auditor, esta situacin no es de ningn modo


propicia a las relaciones armoniosas entre auditores y auditados.
Introducido este principio, distinguiremos tres casos:
El software de auditora debe analizar los ficheros presentes en la
empresa en el momento de la intervencin
En este caso, la preparacin de los ficheros se limitar a una copia el da
de la llegada del auditor.
El software de auditora 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
auditora contable, la cual se lleva a cabo, la mayora 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 ejecucin del software necesita la creacin de un fichero de
extraccin intermedia
Este caso se presenta cada vez con ms frecuencia tras la aparicin de las
bases de datos, cuyo volumen es bastante importante para que se pueda poner a disposicin de los auditores una copia sobre el espacio de disco.
A menudo se debe prever la creacin de un fichero reducido extrado en
la fecha deseada, que ser cargado sin dificultad.
c) La preparacin del software de auditora
Segn las circunstancias y las herramientas de que disponga, el auditor
efectuar sus tareas:
En el equipo de explotacin o en el equipo de infocentro de su cliente
(ya sea interno o externo).
En su propia unidad central: algunos gabinetes de auditora disponen
tambin de una configuracin 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.
216

Tcnicas de la auditora informtica

Adems, cuando trabaja en un equipo puesto a su disposicin, se le debe


destinar:
Una parte del espacio de disco y los recursos de mquinas.
Un terminal.
Una clave de acceso.
Algunas veces, el software de auditora debe, antes de nada, ser instalado
en el equipo de explotacin.
Si bien esta instalacin es la mayora de las veces relativamente rpida, necesita siempre una asistencia del personal del servicio de informtica. Esta asistencia, en el mejor de los casos inferior a una hora, llega algunas veces a varias horas en los sistemas ms complejos.
Comprendemos en estas condiciones la importancia que reviste la planificacin de la intervencin, 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 observacin del plazo, de disociar la fase de preparacin y de test del software de auditora de su ejecucin real.
De este modo, si se ha previsto realizar controles en los ficheros de existencias al 31 de diciembre, que slo estarn 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 anlisis de los resultados
Es raro que los resultados fruto del diseo y la ejecucin de un software
de auditora suministren conclusiones inmediatas. La mayora de las veces,
necesitan un anlisis complementario, el cual tambin 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 informacin suficientemente exacta. Convendr tambin analizar total o parcialmente los casos sealados para determinar la causa de esta anomala.
Del mismo modo, en el caso de un software que recalcule para validacin
el valor de las existencias, ser muy raro que, desde el primer cotejo, los resultados sean estrictamente idnticos a los obtenidos de la aplicacin auditada. Entonces se debe prever una fase de anlisis de los resultados que, muy
a menudo, pondr en colaboracin al conjunto de los actores que han participado en el diseo del pliego de condiciones.
Esta ltima fase de la misin debe ser tanto ms planificada cuanto que,
frecuentemente, es menospreciada o abandonada por falta de tiempo, transformando as en intiles todas las tareas anteriores al llegar a su trmino.
La utilizacin de los programas informticos

217

15.4 LA PLANIFICACIN DE LA INTERVENCIN


En el momento de la preparacin de la intervencin, el conjunto de las
fases precedentes descritas deben ser planificadas, y las cargas de trabajo correspondientes deben ser estimadas.
A ttulo informativo, veremos en el cuadro que sigue un ejemplo de planificacin de intervencin de un equipo de personal informtico de un gabinete de auditores de cuentas para la realizacin de una ronda de comprobaciones en el fichero de las inmovilizaciones.
Plan de actuacin de un gabinete de auditora contable para
realizacin 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 Planificacin de la
e
misin
1991

1dxh

Director del dossier


Director del equipo de
auditora informtica

Director
de informtica

Octubre
1991

2dxh

Jefe de la misin
de revisin contable
Jefe de misin del
equipo de auditora
informtica

Jefe del proyecto


informtico
Jefe de contabilidad

4dxh

Auditor informtico

Jefe de proyecto
informtico
Responsable
de la explotacin

Preparacin del pliego


de condiciones

Diciembre Despus de la aprobacin


del pliego de condiciones,
1991
texto y tests de los
programas de auditora
Marzo
1992

Ejecucin en el fichero
de las inmovilizaciones
a finales de 1991 del
software preparado
en diciembre

1dxh

Auditor informtico

Jefe de proyecto
informtico
Responsable de la
explotacin

Marzo
1992

Anlisis de los resultados

2dxh

Auditor informtico
Revisor contable

Jefe de proyecto
informtico
Jefe de contabilidad

218

Tcnicas de la auditora informtica

Captulo 16

El auditor informtico:
perfil, contratacin y
perspectivas de
evolucin

16.1 PERFIL DEL AUDITOR INFQRMATICO


Y NATURALEZA DE LA MISIN
No es necesario repetir aqu las cualidades humanas que se exige del
auditor informtico, que debe ser al mismo tiempo diplomtico, buen comercial y buen pedagogo.
En cambio, vale la pena aclarar las cualidades tcnicas que se esperan de
l. stas presentan de hecho un doble aspecto:
Un conocimiento de las tcnicas de auditora.
Una competencia en materia informtica.
Esta dualidad explica por s sola la diversidad de perfiles de los auditores
informticos. Algunos sern profesionales de auditora, a los cuales se les
ha dado una formacin en informtica, otros sern informticos a los cuales
se les habr dado una formacin en auditora.
Ms exactamente, las competencias tcnicas exigidas a los auditores dependen fundamentalmente de la naturaleza de las misiones que les son confiadas.
El auditor informtico

219

a) Las misiones de auditora de la funcin informtica


Estas misiones requieren de los auditores una amplia competencia tcnica en el campo de la informtica; mtodos de desarrollo, mtodos de explotacin, caractersticas de los principales equipos y software bsicos. Esta
competencia es, adems, necesaria, no solamente por el hecho del nivel tcnico de las investigaciones y de las conclusiones a ser emitidas, sino tambin
por razones de credibilidad frente a los interlocutores.
A priori el perfil mejor adaptado a esta funcin es el de un diplomado superior (Ingenieros, MBA, etc.) que haya ejercido durante algunos aos las
funciones operativas en el seno de un servicio de informtica, por ejemplo,
como encargado de proyecto. Cuando se tienen en vistas intervenciones de
alto nivel tcnico (pruebas de penetracin, auditora de las actuaciones, auditora de la actividad del sistema, auditora de las bases de datos, auditora 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 auditora informtica justifique una contratacin como sta, teniendo en cuenta la gran especializacin de estos perfiles y
su nivel de remuneracin.
b) Las misiones de auditora de aplicaciones informatizadas
Contrariamente a las misiones de auditora informtica, stas no necesitan grandes competencias tcnicas en materia informtica. En cambio, implican buenos conocimientos en los campos auditados: la auditora de una
cadena de control de produccin requiere el dominio de esta actividad, la
auditora de la cadena especial en un establecimiento financiero requiere
una competencia en materia bancaria, la auditora 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 debern tambin
al mismo tiempo:
Ser profesionales de la auditora, capaces de adaptar su tcnica a exigencias operativas variadas.
Pertenecer a la plantilla fija de la empresa y tener un buen conocimiento
de la organizacin de la empresa y de sus funciones principales.
Disponer de conocimientos bsicos en materia informtica.
Esta diversidad de competencias exigidas es, adems, una de las causas
de la dificultad para llevar a buen fin estas misiones. Se tendrn en cuenta
para ocupar estas funciones:
220

Tcnicas de la auditora informtica

Los jefes de proyectos informticos confirmados.


Los auditores con varios aos en esta funcin que dispongan de conocimientos en materia de informtica.
c) La utilizacin del software de auditora
Se trata esta vez de una funcin asistencial a los equipos de auditora
contable, financiera u operativa, para la realizacin de tests informatizados.
Si bien el diseo de los tests y, si fuere necesaria, la implantacin del
software necesitan una experiencia prctica en materia informtica, la
realizacin 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 formacin bsica en informtica, completada con una formacin de algunos das en el software utilizado parece
suficiente.
Esta capacidad tcnica mnima exigida no excluye adems 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 encontrarn en ellos una formacin concreta y prctica:
En los sistemas de explotacin y en los lenguajes de programacin informtica.
En las tcnicas de auditora.
Tendremos la mayora de las veces para asumir esta funcin:
Jvenes licenciados en estudios superiores (ingenieros, escuelas de negocios, etc.);
Auditores contables u operativos que, despus de una formacin de corta
o media duracin (de algunas semanas a algunos meses), evolucionarn
hacia las funciones de auditor de informtica.

16.2 LA CONSTITUCIN DEL EQUIPO DE AUDITORIA


INFORMTICA
La constitucin del equipo de auditora informtica es, por supuesto, la
consecuencia de los perfiles requeridos para cada tipo de misin y de la naturaleza de las tareas confiadas a este equipo.
El auditor informtico

221

Un equipo de auditores informticos cuya vocacin es de integrarse en


equipos generalistas para ayudarlos a disear y realizar los tests informatizados, no tendr nada que ver con un equipo de auditores esencialmente destinados a realizar misiones difciles y profundas en el seno de los servicios
informticos.
Ms all de estas caractersticas generales, nuestro objetivo ser aqu
mencionar algunas cuestiones concretas y prcticas que pueden surgir en la
constitucin del equipo ideal, por lo menos en el plano terico.
Es preferible contratar principiantes o personal experimentado?
Si bien la responsabilidad de la misin de auditora informtica slo
puede ser confiada a personal con experiencia, es posible en cambio, en la
formacin del equipo, atribuir algunas tareas a los principiantes. Tambin
hace falta que stos tengan el potencial para adaptarse rpidamente a las diversas situaciones tanto en el plan tcnico como en el humano.
Podemos imaginar, por ejemplo que, en el seno del equipo, el personal
principiante estara encargado, durante sus dos primeros aos, de:
La realizacin de los tests ayudados por software de auditora.
La participacin en misiones de auditora de la funcin informtica o de
auditora de aplicacin, sobre la base de un programa de trabajo detallado.
Trabajos de asistencia en materia de ofimtica.
De esta forma, irn progresivamente asumiendo la responsabilidad de
todo tipo de misiones. Veremos, no obstante, que para un auditor informtico el hecho de no haber ejercido nunca responsabilidades operativas puede
constituir un handicap, a la vez tcnico, por razones que podemos imaginar
fcilmente, y psicolgico, ante los servicios auditados.
Adems, la integracin de auditores principiantes en el equipo comporta
el problema de sus perspectivas de evolucin. Tras algunos aos estos generalmente tendrn que elegir entre:
Ejercer las funciones operativas en el seno de un servicio informtico.
Proseguir su carrera en la auditora y la asesora, ampliando sus campos
de competencias (auditora contable, auditora operativa, asesoramiento
en informtica, etc.)
En definitiva, y salvo en los casos donde la naturaleza de la misin lo impida, haremos todo lo posible para mezclar en el seno del equipo de auditora
a responsables de misiones difciles, que hayan ejercido tanto responsabi222

Tcnicas de la auditora informtica

lidades operativas (jefe de proyecto, etc.) como responsabilidades de misin


de auditora, con los auditores juniors, principiantes o que tengan de dos a
tres meses de experiencia.
Profesionales de la auditora o profesionales de la informtica?
Hemos mencionado la dualidad de las competencias exigidas al auditor
informtico:
Competencia tcnica en un campo que est en evolucin permanente.
Conocimiento de los mtodos y las tcnicas de auditora.
Surge entonces una pregunta: Quin ser el mejor auditor, entre el profesional de la auditora al cual habremos dado una formacin en informtica
y el profesional de la informtica a quien habremos dado una formacin en
auditora?
La respuesta es fcil 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 ms
frecuentes de los fracasos.
En cuanto a los profesionales de la auditora, las ms usuales son imputables a una sobrevaloracin de las competencias tcnicas exigidas. Con demasiada frecuencia, los auditores contables piensan que pueden, mediante
algunos das de formacin, desmitificar la informtica, y slo ven el esoterismo 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 informtico sin conocer la informtica. Y este conocimiento de la informtica no puede ser slo terico y pasa imperativamente por varios aos
de trabajo prctico.
A la inversa, los fracasos de los profesionales de la informtica estn,
en su gran mayora, relacionados con su dificultad para abstraerse de su
propia capacidad tcnica. 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 didcticos, por ltimo, y sobre todo, porque carecen de competencias en estos campos. stas, sin embargo, son necesarias para sus misiones tales como: organizacin, gestin, contabilidad,
etctera.
No obstante, hemos de concluir diciendo que no corremos ningn riesgo
en afirmar que los informticos obtienen mejores resultados en la auditora
de la funcin informtica, mientras que los profesionales de la auditora lo
obtienen en la auditora de aplicacin. Los auditores de origen contable son
El auditor informtico

223

los que cosechan ms xitos en la asistencia a la auditora contable. Nadie


puede renegar totalmente de su pasado.

16.3 LA SELECCIN DE LOS AUDITORES


INFORMTICOS
El mercado de la auditora, y en particular el de la auditora informtica,
es hoy da un mercado particularmente difcil.
Citemos a ttulo ilustrativo algunos mtodos de seleccin:
Los anuncios en la prensa diaria nacional.
Los anuncios en la prensa de informtica.
El envo 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 envo de cartas a los alumnos provenientes de la especialidad de informtica de algunas promociones de estas escuelas.
La participacin en los foros.
Recurrir a gabinetes especializados.
Las relaciones (en un mercado crtico, 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 direccin de un
servicio o de un equipo, vale la pena recordar algunas consideraciones propias de la actividad de la auditora informtica.
Los auditores informticos deben estar especializados por
tipo de misin?
Contrariamente a lo que podramos pensar en el primer momento, las misiones confiadas a los auditores informticos son bastante variadas, tanto
por las competencias tcnicas exigidas como por los mtodos de enfoque
elegidos.
224

Tcnicas de la auditora informtico

Por eso, los auditores deben estar capacitados, en funcin de sus propias
competencias, para tomar parte en todo tipo de misin? La respuesta parece
condicionada por dos principios bsicos:
Sera 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 especfico de actividad,
durante toda la duracin de su paso por el equipo.
Verdaderamente, la mejor solucin consiste en proponer a cada auditor,
en el momento de su llegada, una evolucin que le permita progresar a medida que vaya adquiriendo competencias y fortaleciendo su experiencia.
Esta progresin se podr materializar:
Por medio de una evolucin tcnica: el auditor ser asignado a misiones
que requieran una capacidad tcnica cada vez ms importante.
Por medio de una evolucin jerrquica: el auditor ser nombrado responsable de misiones simples, despus progresivamente, de misiones
cada vez ms complejas.
Por medio de una evolucin en la naturaleza del objetivo pretendido: en
particular, cuando al servicio de auditora se le confan misiones de asistencia y asesora, que exigen a la vez un alto nivel tcnico y aptitudes comunicativas evidentes, stas se reservan primordialmente a los auditores
con experiencia.
Algunos auditores deben estar especializados en la utilizacin
del o de los programas (software) de auditora?
Una primera constatacin se impone: un auditor generalista al cual se
le pide que utilice, en el marco de sus misiones, el software de auditora,
slo 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 informtica, su insuficiente dominio de la herramienta
ser a la vez fuente de prdida de tiempo y de una baja fiabilidad de los desarrollos.
Este inconveniente ha llevado a la gran mayora de las grandes empresas
o de los gabinetes de auditora a formar equipos especializados en la utilizacin 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 duracin, por ejemplo de uno a dos
aos.
El auditor informtico

225

La remuneracin
Sera desastroso dar las estadsticas sobre las remuneraciones de los
auditores de informtica, teniendo en cuenta la diversidad de los perfiles encontrados. Veremos, de todos modos, que este mercado es muy crtico teniendo en cuenta la doble penuria sobre el mercado de auditores y sobre el
mercado de informticos. Veremos igualmente que, en estos dos campos, las
remuneraciones de los principiantes evolucionan muy rpidamente durante
los primeros aos de experiencia. No obstante, es indispensable, en el momento de la seleccin de un nuevo colaborador, prever un margen de progresin significativo en caso de xito en este puesto.
La responsabilidad del equipo de auditora informtica deber tener en
mente a la vez, las gamas de remuneracin de los auditores y las de los informticos.

16.5 PERSPECTIVAS DE EVOLUCIN DE LOS


AUDITORES INFORMTICOS
Enfocaremos sucesivamente la evolucin del auditor informtico hacia
tres tipos de funciones:
La funcin de especialista en auditora informtica.
Las funciones de auditor.
Las funciones operativas.
La figura 9 ilustra estas perspectivas de evolucin para algunos tipos de
carreras que tengan como denominador comn el paso por las funciones de
auditora.

a) El especialista de la auditora informtica


La auditora informtica ha conocido a lo largo de los diez ltimos aos
un desarrollo considerable. Aun cuando la progresin debera, antes de nada,
tender a estabilizarse, actualmente es posible enfocar una carrera en la auditora informtica. Esta carrera desembocar en funciones tales como responsable de risk management, responsable de la auditora informtica en el
seno del servicio de auditora (o de inspeccin en un establecimiento financiero), responsable de la seguridad en el seno de una Direccin informtica,
etctera.
226

Tcnicas de la auditora informtica

Figura 9. Ejemplo de carrera pasando por las funciones de auditor.

El auditor informtico

227

El auditor informtico que pretende una carrera de este tipo debe, por
tanto, tener en mente un doble riesgo:
Las carreras en informtica, las cuales permiten ascensos muy rpidos
durante los primeros aos, son a menudo delicadas a partir de la edad de
40 aos, teniendo en cuenta el prejuicio que se relaciona, por lo general,
con esta actividad de alto nivel tcnico.
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 auditora, tanto internas como externas, ofrecen actualmente buenas perspectivas, y hacen falta muchos aos en esta funcin para
poder ser considerado como un especialista.
Ahora bien, para el auditor, el paso durante algunos aos por las funciones de auditora informtica constituye un plus innegable, y ser considerada en el futuro como una condicin sine qua non.
Podemos entonces enfocar:
Un inicio de carrera en la auditora informtica antes de evolucionar hacia funciones de auditor contable u operativo. .
O, por el contrario, un paso por la auditora informtica despus de algunos aos de auditora contable u operativa.
Estas opciones deben, por lo tanto, ser elaboradas suficientemente para
evitar los riesgos de fracaso.
c) Las funciones operacionales
La funcin del auditor informtico constituye un puesto de observacin y
de reflexin 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 informtica. A ttulo de ejemplo, un antiguo
jefe de proyecto, ejerciendo las funciones de auditor informtico, estar a
continuacin en posicin de postular por un puesto de responsable de estudios o de jefe de servicio. El ingeniero que haya iniciado su carrera en la
auditora informtica podr aspirar a un puesto de jefe de proyecto.
Por tanto, veremos que, bajo esta ptica, es deseable no sobrepasar un
perodo de tres a cinco aos en esta funcin.
* * *
228

Tcnicas de la auditora informtica

Bibliografa

Libros
IFACI, Les principes de la scurit informatique: Guide d'audit, Clet-Dunod, 1990.
JAN (C), SABATIER (G.), La scutit informatique, Eyrolles, 1989.
LAMER (J.-M.), La scurit informatique, approche mthodologique, Dunod, 1985.
LAMER (J.-M.), LEROUX (Y.), TOURLY (J.), La scurit des rseaux: mthodes et
techniques, Dunod, 1989.
LAMER (J.-M.), TOURLY (J.), La scurit des petits et moyens systmes informatiques, Dunod, 1988.
LEFEBVRE (Francis) Memento comptable.
"Progiciels de comptabilit, critres de conception et de choix", Estudio de la Compagnie nationale des Commissaires aux Comptes et de l'Ordre des Experts
comptables et des comptables agrs, Mayo 1990.
PLANS (J.), Lapratique de l'audit informatique, Eyrolles.
PLANS (J.), La qualit informatique: comment maitriser les systmes 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, mthodes, 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 (Assemble plnire des socits d'assurance contre
l'incendie et les risques divers) sobre la seguridad informtica
Encuestas y estudios del CLUSIF (Club de la Scutit informatique francaise).

Bibliografa

229