Técnicas de La Auditoría Informática - (PG 41 - 135) PDF

Capítulo 2
La organización
general del servicio
informático
2.1 LA ESTRUCTURA DEL SERVICIO

INFORMÁTICO
• P. ¿Existe un organigrama escrito del departamento de

informática?
Aunque el organigrama escrito pueda parecer superfluo e incluso acon-
gojante en las estructuras pequeñas, se impone desde el momento que el per-
sonal supera una decena de personas.
Copyright © 2009. Marcombo. All rights reserved.
Encontraremos en la figura 1 una estructura tipo de servicio informá-

tico y, en el recuadro que hay a continuación, una sucinta descripción de las
principales funciones extraída de la obra Les techniques de l’ organisation
informatique.
El auditor comprobará, por supuesto, que el organigrama que le es dado
está al día y cubre el conjunto de las funciones necesarias para la buena mar-
cha del servicio.
Además, las fichas de definición de función son deseables, en particular
para ciertos puestos funcionales como: responsables de métodos, adminis-
tradores de datos, responsables de la seguridad, etc. El análisis de estas fi-
chas permitirá algunas veces descubrir que determinadas funciones no están
cubiertas.
La organización general del servicio informático 29

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com
Created from unadsp on 2020-01-30 15:50:42.
Figura 1. Modelo de estructura de un servicio de informática.
30 Técnicas de la auditoría informática

A. LAS FUNCIONES PRINCIPALES EN EL SENO
DE UN SERVICIO DE INFORMÁTICA
a) La función de estudios
La función de estudios representa el conjunto del personal informático
dedicado al desarrollo de nuevas aplicaciones y al mantenimiento de las mis-
mas.
Estas aplicaciones serán utilizadas a continuación por el personal de pro-
ducción. Para fijar bien las ideas, tomemos por ejemplo la aplicación de un
nuevo sistema de gestión de pedidos y facturación, decidida por la Dirección
general. El Director de informática confía este trabajo al responsable de estu-
dios, quien constituye un equipo bajo la responsabilidad de un jefe de pro-
yecto. Este equipo escribe y prueba los programas (utilizando los lenguajes de
tipo COBOL, GAP, o lenguajes más evolucionados conocidos como de cuarta
generación), y posteriormente el usuario valida la aplicación gracias a un jue-
go de prueba. Solamente después de este juego de prueba es cuando los pro-
gramas son puestos en marcha y, por lo tanto, realmente utilizados bajo el
control del personal de producción. El personal de estudios no tendrá ya que
intervenir excepto para las operaciones de mantenimiento, es decir, para las
operaciones de modificación de las funciones de los programas. Volveremos
después sobre los métodos de puesta en marcha y de mantenimiento de las
aplicaciones.
El responsable de estudios tiene, por lo tanto, el control del conjunto de
las operaciones de desarrollo y de mantenimiento del software. Está asistido
en sus funciones por varios jefes de proyecto responsables de uno o varios
proyectos.
El jefe de proyecto dirige un equipo que puede estar constituido:
— por analistas;
— por analistas-programadores;
— por programadores.
b) La función de producción
Hace algunos años esta función era a menudo llamada explotación. Hoy
día, el término de producción consagra definitivamente el paso de la informá-
tica de la era «artesanal» a la era «industrial».
En efecto, la organización de la producción ha evolucionado profunda-
mente en pocos años, principalmente gracias al perfeccionamiento de los ma-
teriales y del software básicos. Al mismo tiempo, la cualificación del personal

de producción ha subido considerablemente.
Para delimitar mejor lo que hoy día es la producción en un centro de tra-
tamiento, partimos de la situación existente hace algunos años (y que hoy día
algunas veces aún existe), para después entretenernos con las evoluciones más
recientes.
Los preparadores: son los que han procedido a poner en marcha, y pos-
teriormente en producción, las aplicaciones desarrolladas por el personal de
estudio.
En efecto, los programas desarrollados por el personal de estudio han es-
tado en un entorno de prueba, utilizando en particular ficheros o bases de da-

tos de test. La aplicación de estos programas necesita, por lo tanto, una modifi-
cación de los procedimientos por medio del JCL (Job Control Language, o sea,
del lenguaje de comando del ordenador), lo que permite relacionar el progra-
ma con su entorno exterior.2 En particular, en el caso de cadenas de trata-
miento en tiempo diferido, los preparadores podrán proceder a una verdade-
ra optimización del procedimiento. A título de ejemplo, si el jefe de proyecto
hubiese previsto conservar en el disco duro un fichero destinado exclusiva-
mente a fines de salvaguarda, el preparador lo podrá copiar en cinta magnéti-
ca para reducir el espacio de disco consumido por la aplicación. En otras pa-
labras y para simplificar las cosas, se puede considerar que el preparador ha-
ce pasar la aplicación a «tamaño real».
Más tarde, cuando una aplicación se encuentre en producción, será el pre-
parador quien asegurará el conjunto de parámetros y el arranque suminis-
trando todas las consignas necesarias a los operadores y, por consiguiente, al
ordenador.
Los preparadores están, por lo general, agrupados en equipos de trabajo,
cada equipo con la responsabilidad de un conjunto de aplicaciones.
Por ejemplo: un primer equipo se encarga de todos los procesos relaciona-
dos con la gestión de producción, otro se encarga de todos los tratamientos de
tipo contable y el tercero se ocupa sólo de las aplicaciones de gestión
comercial.
Los teclistas son las personas que están en relación directa con el ordena-
dor por medio de su consola. Ellos ponen en marcha la máquina, la paran, la
vuelven a poner en marcha en caso de avería. Ponen en práctica la ejecución
de las cadenas partiendo de los procedimientos que fueron introducidos a la
espera de tratamiento por los preparadores, luego, aseguran eventualmente
ciertas intervenciones manuales que figuran en las consignas dejadas por los
mismos preparadores (incluso en caso de incidente). Algunas veces los teclistas
son auxiliados por los operadores en los trabajos más corrientes, tales como la
colocación y retirada de cintas magnéticas en las bobinadoras, colocación de
papel en las impresoras, etc.
Los teclistas están organizados en equipos para así asegurar una utiliza-
ción continua de los ordenadores. Algunas veces 24 horas al día. Por lo gene-
ral están especializados en una máquina. Los equipos de teclistas están algunas
veces bajo la responsabilidad de un jefe de sala.
La célula de control tiene como objetivo el control de los resultados de los
tratamientos en tiempo diferido antes de la distribución a los servicios de
2. Veremos a continuación un ejemplo simplificado intencionadamente con fines pedagó-

gicos de un JCL de lanzamiento del programa FACT que lee en forma de secuencia el fi-
chero de los pedidos para la emisión de facturas.
II JOB EDIFACT Nombre de la tarea a ejecutar
II OPTION LOG, PARTDUMP Opciones de ejecución
II ASSIGNSYS001, DISK,VOL=SYSWK1,SHR Relación entre los ficheros lógi-
cos descritos en el programa y fi-
cheros físicos en disco.
II DLBL FILE, FACTURE
II EXEC FACT Lanzamiento de la ejecución del programa
0292 Parámetro de ejecución

usuarios de los listados correspondientes. La célula de control debe tener de
este modo los «códigos» que permitan detectar eventuales anomalías de uso.
El gestor del archivo de cintas asegura la gestión física del parque de cin-
tas magnéticas necesarias para las operaciones de salvaguarda.
El crecimiento excepcional de las capacidades de almacenaje en disco
magnético en el curso de los últimos años ha conducido algunas veces a bajar
la guardia en la vigilancia del espacio disco. La gestión del espacio disco re-
presenta una función importante en los grandes centros de proceso. El gestor,
por supuesto, cuenta con la ayuda de sistemas de herramientas cada vez más
eficaces, que permiten una gran automatización de esta función.
La gestión de la red representa igualmente una función nueva e importan-
te. En efecto, las configuraciones informáticas actuales recurren, en gran par-
te, a las técnicas de transmisión de datos directamente o a distancia, utilizan-
do, en el segundo caso, conexiones telefónicas especializadas, la red telefónica
conmutada o también las redes especializadas. Además de la necesidad de uti-
lizar el software especializado, cuya implantación es por lo general confiada al
personal de sistema, esta evolución contribuyó a crear las funciones de gesto-
res de red, que garantizan el seguimiento continuo de la misma, por medio de
contacto telefónico con los usuarios,3 implantación de nuevos terminales,
diagnóstico de las paradas de sistema más comunes (corte en la red, incidente
en la unidad central, terminal desconectado, etc.).
Sólo los trabajos de manutención (desconexión, guillotinado, encuader-
nación, etc.) ocupan a menudo varias personas en los grandes centros infor-
máticos.
Por último, el departamento de registro, bajo la responsabilidad de una
monitor a, agrupa el personal encargado de la toma del caudal de documentos,
muy a menudo bajo la forma de una doble toma (asegurada por las perfora-
doras-verificadoras). Como es sabido, esta función se ha reducido considera-
blemente en el curso de los últimos años por el hecho de la aplicación progre-
siva de procedimientos de registro interactivo por los propios usuarios. En al-
gunos casos específicos, sin embargo, el registro masivo encuentra todavía su
razón de ser.
Después de este recuento de las principales funciones propias de la pro-
ducción informática, conviene aportar un cierto número de complementos re-
lacionados con la evolución reciente de esta actividad.
• Teniendo en cuenta el desarrollo de los sistemas de explotación y en
particular del número de aplicaciones que pueden ser ejecutadas simultánea-
mente en una misma máquina (multiproceso), el teclista ya no puede conocer

las especificaciones de estas aplicaciones ni tampoco velar por las operaciones
propias de éstas. Él es el garante del buen funcionamiento del ordenador, pe-
ro no del buen funcionamiento de las aplicaciones utilizadas por este ordena-
dor. Al igual que un fabricante de televisores, que es el garante de la calidad
técnica del aparato, pero no de la calidad de las emisiones. Además, la apari-
ción de los grandes sistemas de programas ha permitido automatizar un nú-
mero importante de órdenes de tecleado y reducir otro tanto la carga de los te-
clistas, los cuales, la mayoría de las veces, sólo procesan las intervenciones
más delicadas. En lo que concierne a la función del operador, ésta debería
3. Se habla a menudo de hot Une.

desaparecer progresivamente, sólo con la sustitución de las cintas magnéticas
por cuya manipulación es totalmente automatizada.
• Simultáneamente, gracias a la evolución de los sistemas de explotación,
es posible prever una automatización cada vez más estimulada por las cadenas
de proceso y por los procedimientos de reanudación en caso de incidente. Par-
tiendo de este hecho, se tiende a sustituir la noción de preparador por la de
responsable de producción de aplicación, teniendo cono funciones:
— La puesta en explotación de las nuevas cadenas de proceso y optimiza-
ción de la utilización de los recursos.
—Su preparación y su arranque con periodicidad ad hoc.
— El control de su buena ejecución.
— Las relaciones con los usuarios.
El responsable de producción de aplicaciones (o analista de aplicaciones)
cuenta además desde ahora con instrumentos informatizados para la prepa-
ración y control de explotación.
• El papel de la célula de control tiene tendencia a reducirse.
En efecto, las anomalías que tiene a su cargo descubrir tienen su origen:
— ya sea en errores de explotación, que pueden ser detectados por el
propio analista de explotación al recibir los informes de explotación
producidos por la máquina;
— o bien, en anomalías funcionales, las cuales también son detectadas
con mucha eficacia por los propios servicios de usuarios.
c) Las funciones de sistemas

El software básico puesto a disposición de los informáticos es cada vez más
numeroso. Los sistemas de explotación, compiladores, monitores de telepro-
ceso, software de protección de acceso, sistema de gestión de base de datos,
diccionarios de datos, gestor de red, gestor de espacio disco, gestor de archivo
de cintas, etc., son solamente algunos ejemplos entre tantos.
El papel de los ingenieros de sistemas es elegir el software que mejor se
adapte a las necesidades de su empresa, implantarlos, regular sus parámetros
y, quizás lo más delicado, conseguir que cohabiten de forma armoniosa.
d) Las junciones técnicas

Estas funciones no han aparecido en la mayoría de los centros informáti-
cos hasta el último decenio.
Citaremos a título de información las funciones en este área:
— Responsable de la microinformática.
— Responsable del infocentro (puesta a disposición de los usuarios de
lenguajes de interrogación simples).
— Responsable de los métodos.
— Responsable de la seguridad.
— Responsable de las bases de datos.
— Responsable de las redes.
En los centros importantes, estas funciones están a veces agrupadas en el
seno de una dirección técnica.

2.2 LA PLANJFICACIÓN DE LA ACTIVIDAD
INFORMÁTICA
• P. ¿Existe un comité informático, responsable de las principales

decisiones estratégicas?
Con frecuencia, la Dirección general de la empresa delega a la Dirección
de informática la definición de la política a llevar a cabo. Esta delegación es
evidentemente peligrosa en la medida de que el personal informático tiene la
tendencia a favorecer a sus propios criterios en la elaboración de las orienta-
ciones estratégicas.
De este modo, las elecciones de equipamiento corren el riesgo de ser lle-
vadas a cabo tanto en función del interés técnico de la maquinaria como en
función de sus cualidades intrínsecas. Igualmente, las prioridades en materia
de desarrollo de los programas podrían estar influenciadas por la calidad de
las relaciones de la informática con los diferentes Directores de la empresa,
o incluso por el carácter más o menos innovador de la aplicación a ser conce-
bida, tanto como por la importancia que ésta representa para la empresa.
Incluso con un equipo de personal informático totalmente integrado y ob-
jetivo, no es bueno que éste asuma la responsabilidad de arbitrajes entre
servicios que puedan, con el tiempo, transformarse en fuente de relaciones
conflictivas.
Por lo tanto, es esencial que las decisiones estratégicas sean llevadas a
cabo por la Dirección general. El comité de informática, compuesto por re-
presentantes de la Dirección general, por responsables de cada Dirección de
la empresa, y por los principales responsables de la Dirección de informá-
tica, es, por lo general, la instancia más apropiada para asumir esta decisión.
Tendrá a su cargo, por ejemplo, la elaboración o la aprobación del plan infor-
mático, tanto equipos como software, los presupuestos, la definición de prio-
ridades a corto plazo, el arbitraje de los conflictos eventuales y el segui-
miento de la calidad del servicio producido.
• P. ¿Hay un plan informático?

El plan informático tiene como objetivo anticipar las principales evolu-
ciones de la actividad informática, tales como: equipos, programas básicos,
progamas de aplicaciones, recursos humanos.
La elaboración del plan informático es, no obstante, un ejercicio peli-
groso, teniendo en cuenta la rapidez de la evolución tecnológica. Así pues,
¿cómo se pueden prever los equipos que serán implantados en una empresa
en un plazo de 24 meses, cuando los propios fabricantes desconocen lo que

será su política comercial en este plazo, o por lo menos no la han revelado
todavía al público?
De forma análoga, las prioridades de desarrollo de aplicaciones pueden
ser cuestionadas por varias razones, como por ejemplo: evolución de la polí-
tica comercial, situación de la competencia, modificación de la legislación
vigente, etc.
Un plan informático demasiado detallado está, por lo tanto, desgraciada-
mente condenado a una rápida obsolescencia. Por el contrario, un plan de-
masiado impreciso no necesitará ser cuestionado, pero no tendrá ninguna
utilidad.
Estos argumentos no deben conducir al rechazo de toda planificación.
Tienen más como finalidad sacar a la luz la necesidad de un cuestionamiento
permanente de los planes. El auditor sacará sus conclusiones sin resaltar el
desacato al plan, por lo menos cuando las evoluciones han sido aprobadas
por la Dirección general.
2.3 EL SEGUIMIENTO DE COSTES
• P. ¿Hay un presupuesto informático?

Más allá de la simple existencia de un presupuesto, el auditor se dedicará
a su contenido, el cual puede ser muy variable de una empresa a otra.
Se encontrará, entre otras cosas, los encabezamientos de capítulo si-
guientes: equipos, programas básicos, programas de aplicación, remunera-
ciones, telecomunicaciones, materiales consumibles (papeles, etc.).
• P. ¿Se justifican sistemáticamente los incrementos de costes?

Un crecimiento importante en los presupuestos de informática no deben
ser criticados a priori. Puede corresponder a necesidades reales, tales como:

introducción de una aplicación importante, evolución hacia un software más
asequible. Pero, a la inversa, los presupuestos deben estar justificados y, si
fuere necesario, ser objeto de arbitrajes por parte de la Dirección general en
función de las prioridades que contenga.
• P. ¿Hay un seguimiento de la actividad del personal de informática?

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

mientas apropiadas, se hace rápidamente imposible a partir del momento
que aumenta la magnitud del servicio.
Así, en ausencia de un procedimiento serio de seguimiento de la activi-
dad, las informaciones tan importantes como el coste de cada proyecto o la
distribución en el seno del servicio entre las actividades de desarrollo y de
mantenimiento, serán mal identificadas.
El argumento frecuentemente evocado por los responsables de informá-
tica para rechazar un seguimiento de este estilo, a saber, el riesgo de rechazo
por su personal de procedimientos demasiado apremiantes, incluso cuando
no debe ser subestimado, es que no pueden resistir una constatación simple
del tipo: ¿Cómo y por qué la informática se ha transformado en la única acti-
vidad que no se preocupa de sus precios de coste?
• P. ¿Se facturan los costes de la informática a los servicios de

usuarios?
La respuesta a esta pregunta sólo puede ser analizada en el contexto más
general del control de gestión en el seno de la empresa.
La falta de facturación de costes encuentra a veces su justificación en la
voluntad de «promover» la informática. Esta «promoción», no obstante, a
priori será limitada en el tiempo.
Cuando hay refacturación, ésta incluirá habitualmente una separación
entre:
— Los costes de desarrollo.

— Los costes de mantenimiento.
— Los costes de explotación.
• P. ¿Hay en el seno del servicio de informática una función

de auditor de gestión?
Curiosamente, la Dirección de informática ha sido una de las últimas di-
recciones de la empresa en preocuparse por controlar sus costes. Con fre-

cuencia, la informática ha vivido en el axioma de que todo crecimiento de su
presupuesto contribuía a la automatización de sus usuarios y, por lo tanto, a
una reducción global de los gastos generales de la empresa. Este principio,
que ha justificado a menudo incrementos de presupuesto considerables, es
frecuentemente rebatido por la realidad. Los desarrollos inútiles o lujosos,
las dificultades sociales que impiden cualquier reducción de los efectivos, la
inadaptación de la organización, son algunos de los factores que limitan las
reducciones posibles de gastos generales.
Hoy día, la mayoría de las empresas ha comprendido que el control de los

gastos generales pasa también, entre otras cosas, por un control de los gastos
de informática, justificando así la creación de una función de auditor de ges-
tión en el seno de esta dirección para los grandes centros, o por lo menos el
seguimiento por parte del auditor de gestión de los costes de informática al
igual que los otros costes.
2.4 LAS PRÁCTICAS CONTABLES Y FINANCIERAS
• P. La elección del modo de financiación de los equipos, ¿es

económicamente satisfactoria?
La elección del modo de financiación (compra, leasing) debe ser objeto
de un estudio que observe, de acuerdo con las condiciones del mercado del
momento, las posibilidades financieras de la empresa y la duración previsi-
ble de la utilización del equipo.
• P. ¿Son coherentes los períodos de amortización elegidos para los

equipos y, en su caso, para el software, con su período de utili-
zación previsible?
Los equipos y programas adquiridos se amortizan en su período probable
de utilización.
Los períodos de amortización demasiado largos son con el tiempo gene-
radores de pérdidas excepcionales.
A título de ejemplo, podemos prever un período de amortización de:
— Tres años para los microordenadores.

— Cinco años para otros equipos.
— Cinco años para los programas, salvo aquellos que están relacionados
con los equipos, que se amortizan en el mismo tiempo que éstos.
Los gastos de desarrollo interno de software específico son la mayoría

de las veces imputados por prudencia. Sin embargo, se notará que, bajo re-
serva de que se cumplan ciertas condiciones, dicho software debe ser in-
movilizado y amortizado en el período probable de utilización de los
programas.4
4. Para más exactitud sobre los principios contables, ver Les techniques de l'organisation informatique,
Dunod, 1991.

2.5 LAS RELACIONES CON LOS SERVICIOS
DE USUARIOS
• P. ¿Hay un seguimiento de la calidad del servicio prestado?

Los instrumentos de medición simples dan una primera estimación de
esta calidad de servicio:
— Disponibilidad de la unidad central.

— Disponibilidad del teleproceso (incluso disponibilidad de las líneas
mismas).
— Tiempo de respuesta medio de las transacciones.
— Frecuencia de los incidentes por aplicación.
Por otro lado, las herramientas de seguimiento permiten optimizar la con-

figuración y, en su caso, anticipar las evoluciones de éstas antes de que se re-
gistre una degradación de las actuaciones. Se trata, por ejemplo, de los ins-
trumentos de medida de la carga de la unidad central de la tasa de ocupación
de los discos.
• P. ¿Está previsto en el servicio de usuarios una Junción de

corresponsal informático?
El corresponsal informático es, en cada servicio, la interfaz con los infor-
máticos. El interés de esta función es innegable. En efecto, el corresponsal
informático dispone, además de un buen conocimiento de la actividad de su
servicio, de una buena cultura general informática que le permite a la vez
aconsejar eficazmente a los usuarios y llevar apropiadamente los procesos
de mantenimiento que emanan de su servicio.
En ausencia de esta función, es de temer que no tardarán mucho en llegar
al servicio de informática peticiones contradictorias.
• P. ¿Se tienen en cuenta en el diseño de nuevas aplicaciones los

problemas relacionados con la organización de los servicios de
usuarios y con la adecuación de los procedimientos
administrativos ?
Se pueden considerar varias soluciones para dar respuesta a este objetivo:
— Creación de una estructura de organizadores dependientes del responsa-

ble de informática.

— Creación de una dirección de la organización dependiente de la dirección
general.
— Reclutamiento de jefes de proyectos de alto nivel capaces de asumir
igualmente la función de organizador (esta última solución es, no obs-
tante, cada vez mas difícil de aplicar teniendo en cuenta la dicotomía en-
tre las competencias técnicas, cada vez más elevadas, exigidas a los jefes
de proyecto, y las competencias específicas inherentes a la función de or-
ganizador).
2.6 LA SEPARACIÓN DE FUNCIONES
• P. ¿Hay en la organización del servicio informático una

separación entre las funciones de estudios y las de explotación?
Los principios de un buen control interno conducen a que sean separadas
las funciones:
— de los usuarios;
— del personal de estudios;
— del personal de explotación.
• Los usuarios
Tienen acceso a las transacciones para las cuales han sido habilitados. En
cambio, no deben tener ninguna otra posibilidad de actualizar los ficheros de
explotación.
• El personal de estudios
Desarrolla y prueba los nuevos programas en un entorno de prueba dedi-
cado a este fin, después solicita la puesta en explotación. En cambio, una vez
en explotación, no tiene acceso por ningún medio a los ficheros.
De este modo:
— No conoce la palabra clave de los usuarios de la aplicación que él mismo

ha desarrollado.
— No tiene acceso ni a los ficheros ni a la biblioteca de programas en ex-
plotación.
— No pone él mismo en explotación los programas que ha desarrollado.

• El personal de explotación
Es responsable de la puesta en explotación y de la producción de los pro-
gramas desarrollados por el personal de estudios. En cambio, no debe, bajo
ningún concepto, desarrollar o actualizar él mismo tales programas.
* * *
Los medios para conseguir una buena separación de las funciones son va-
rios y volveremos a hablar de los mismos más adelante de forma más deta-
llada.
Citemos a modo de ejemplo:
— El control de acceso de los usuarios al entorno informático (palabras

clave, cartas de memoria, etc.).
— La limitación de acceso a los locales. De este modo, el acceso a los
locales que abrigan los despachos y puestos de trabajo de los titulares
de ciertas funciones sensibles (ingenieros de sistemas, teclistas, etc.)
será estrictamente reglamentado y, la mayoría de las veces, el perso-
nal de estudios no tendrá acceso a los locales ocupados por el per-
sonal de explotación.
2.7 EL CONTROL DE LA ACTIVIDAD
• P. ¿Se efectúan regularmente misiones de auditoría de la

actividad informática?
Como hemos aclarado en la primera parte de la obra, un control de la acti-
vidad informática puede cubrir diferentes aspectos, tales como:
— Control de seguridad o control de las actuaciones.

— Control del entorno informático o control de una aplicación particular.
Este control puede, además, ser llevado a cabo a diferentes niveles. En

efecto, podrá ser efectuado dentro del servicio informático (por ejemplo, por
un responsable de seguridad); o bien fuera del servicio informático pero den-
tro de la empresa (generalmente por la Dirección de la auditoría); o, por úl-
timo, fuera de la empresa (contrato de servicio).
Por lo general, el auditor se ocupará de la frecuencia de las auditorías rea-
lizadas anteriormente y, por supuesto, de las conclusiones de las mismas.

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

Un primer indicador «social» es, por supuesto, el turn-over del servicio.
Una rotación muy importante o una rotación muy escasa están encaminadas
a dañar la calidad del servicio prestado. Los inconvenientes de la primera
opción, la cual de alguna forma es la enfermedad crónica de la informática,
son evidentes: poco dominio de las aplicaciones por parte de los equipos que
no participaron en su diseño, falta de experiencia, falta de motivación de los
informáticos que tienen tendencia a considerarse como «de paso».
No se deben menospreciar los inconvenientes de una rotación demasiado
escasa de efectivos. Ésta conduce, en efecto, a un envejecimiento de la po-
blación con los riesgos que esto comporta: falta de motivación, disminución
de la competencia técnica y de la capacidad innovadora y costes de presta-
ciones elevados. Es verdad que el problema se parece bastante a la cuadra-
tura del círculo. El informático, más que ningún otro, está considerado como
obsoleto a partir del momento que se acerca a los cuarenta, además por razo-
nes, la mayoría de las veces, de tipo subjetivas. Conociendo el problema, él
mismo evita, a partir de esta edad, todo tipo de movilidad, de donde surge el
riesgo de reducción de competencia.
Muy concretamente, el auditor estará particularmente vigilante ante tasas
de rotación inferiores al 15 % o superiores al 25 %. También hace falta espe-
cificar la gran propensión que tienen las empresas a «cubrir» las estadísticas
en este campo. Así pues, si todas las ESII5 reconocen el problema general de
un gran turn-over en la profesión, cada uno, individualmente, probará con
base estadística que es bastante reducida.
En cualquier caso, la tasa de rotación del personal sólo puede ser anali-
zada en relación con algunas características de la gestión de los recursos hu-
manos que mencionaremos sucintamente a continuación.
• P. ¿Es satisfactoria la política de contratación de personal?

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

Las remuneraciones muy bajas en la contratación o, por el contrario, de-
masiado elevadas son igualmente orígenes de dificultades rápidas.
Además, la validación de la competencia y de la integridad de las perso-
nas contratadas y su adecuación a los puestos propuestos, constituye un
componente esencial de la calidad del procedimiento. Si bien una validación
técnica es a menudo delicada, la empresa no se encuentra totalmente desar-
mada.
• P. ¿La política de remuneración está de acuerdo con las normas

del mercado?
Una política de remuneraciones muy bajas conduce en poco tiempo a un
turn-over elevado. La situación inversa es igualmente peligrosa. Las remu-
neraciones demasiado altas son fuente de inmovilismo, luego de envejeci-
miento de una población cuya edad media es, en principio, baja.
Además, el auditor comprobará que dentro del servicio las remuneracio-
nes sean coherentes entre sí.
• P. ¿Es coherente la cualificación del personal con la función que

ejerce?
Si el exceso de cualificación del personal es fuente de rotación rápida, la
falta de cualificación es todavía más lastimosa, ya que ella induce a un
riesgo, en muy corto espacio de tiempo, de degradación de la calidad del ser-
vicio prestado.
• P. ¿Está controlado el recurso de colaboradores externos?

El recurso de colaboradores externos no debe estar prohibido a priori. En
efecto, ofrece diversas ventajas:
— Permite absorber las sobrecargas temporales de actividad.

— Permite contar con recursos de competencia técnica especial y adquirir
progresivamente estas técnicas.
— Permite, por último, en algunos casos, integrar temporalmente dentro del
personal perfiles «raros», evitando así un recalentamiento de las remune-
raciones.
Sin embargo, la empresa no debe hacerse tributaria de sus colaboradores.

Dentro de esta óptica, y salvo en casos excepcionales y que estén totalmente
justificados:

— Los colaboradores no deberían ocupar puestos que les dieran las respon-
sabilidades jerárquicas dentro del servicio (jefes de proyecto, etc.).
— El número de colaboradores no debería en ningún caso sobrepasar del 20
al 25 % del personal.
• P. ¿Ha habido en el pasado hechos significativos en materia de

gestión de personal?
El auditor se interesará, por ejemplo, por:
— Un número elevado de despidos, y las condiciones de estos despidos.

— Los movimientos sociales (huelgas,...).
• P. ¿El interés técnico de la actividad informática permite una

motivación satisfactoria del personal?
Está claro que el servicio informático no debe definir su actividad «por
amor al arte». Escoger los equipos y el software básico más sofisticados im-
plica no solamente un incremento del coste de los servicios prestados, sino
también, en particular, un riesgo de encontrarse con problemas técnicos, que
los servicios seguramente no sabrán resolver.
De este modo, muchos programadores, aficionados a las bases de datos
interrelacionadas, han tenido que renunciar a esta técnica, cuando ésta estaba
aún en sus principios, debido al tiempo de proceso prohibitivo que impli-
caba. En este caso los propios programadores se han dado cuenta de que no
tenían ninguna necesidad de una base de datos relacionada. Desgraciada-
mente este descubrimiento ya había costado tiempo y dinero a su empresa.
Se comprende entonces que la utilización de las técnicas más sofisticadas,
aunque no estén todavía muy difundidas, deben continuar siendo patrimonio
de los grandes centros de proceso, los cuales disponen de medios y de com-
petencias para remediar dificultades eventuales y que, además son suscepti-
bles de desarrollar aplicaciones experimentales.
En cambio, la implantación de equipos y de software básico poco difun-

didos, o superados técnicamente, al igual que el desarrollo de aplicaciones
basándose en diseños obsoletos, son un factor de desinterés por parte de los
informáticos. ¿Qué jefe de proyecto estaría interesado actualmente en un di-
seño de un software totalmente basado en tiempo diferido («batch»), cuando
incluso el tiempo real estaría efectivamente totalmente injustificado?
Independientemente de las consideraciones de carácter puramente téc-
nico, que justifican por sí solas la evolución de las configuraciones, la Direc-
ción de la empresa pondrá todo su interés en velar por que su informática no
se torne arcaica.

En el caso de configuraciones estereotipadas y pasadas de moda, que al-
gunas veces encuentran su razón de ser (¿por qué refundir las aplicaciones
en los sectores de actividad con pérdida de velocidad y condenarlas a un
abandono progresivo?), deberá entonces anticipar el riesgo de una falta de
motivación progresiva de los equipos de personal informático.
Y lo que es más, una configuración obsoleta conduce a una «obsolescen-
cia» rápida de los hombres mismos, la cual conviene también prevenir.
• P. ¿Es suficiente la formación del personal?

Incluso cuando la formación permanente «en el taller» es una caracterís-
tica principal de la actividad de los informáticos, las formaciones teóricas
ocupan a la par, y con toda razón, una parte importante en el presupuesto de
los recursos humanos de los servicios informáticos.
Una política de formación insuficiente es, en efecto, un factor a la vez de
falta de motivación y de disminución de capacidad del personal.
• P. ¿El contexto general de la empresa es fuente de motivación?

Un sector de actividad en declive o aun una localización geográfica des-
favorable pueden tener consecuencias catastróficas en la contratación y en la
rotación de los informáticos, los cuales, en un mercado dinámico perderán el
interés por las empresas que tengan algún handicap.
He conocido una empresa con estas características, cuya informática era
técnicamente competitiva y actualizada, pero que no podía retener a sus in-
formáticos por la única razón de que estaba situada en un barrio de poco
prestigio y, por lo general, poco asequible para los medios de transportes.
Como última salida, esta empresa se ha orientado hacia el denominado «fa-
cilities management».6
2.9 LAS RELACIONES CON LOS PROVEEDORES
• P. ¿Existe una licitación o concurso para la elección de los sumi-

nistradores de equipos o de software?
El recurso de proveedores externos para un servicio informático puede
distribuirse en tres categorías:
6. «Facilities management» (gestión de servicios) consiste en la subcontratación total o parcial de la acti-

vidad informática (desarrollo y explotación) a un suministrador del servicio externo.

— La adecuación de los equipos frente a los fabricantes (o, según la forma
de financiación, ante las sociedades de leasing).
— La adquisión de software, comercializado por los fabricantes de hard-
ware o, más frecuentemente, por las ESII (Empresas de Servicios e Inge-
niería Informática).
— El recurso a las ESII para la elaboración, en administración o en bajo
contrato, de software específico para la empresa.
Veremos en los cuadros que siguen una lista de comprobación relativa a

estas prestaciones externas.
B. CUESTIONARIO RELATIVO A LA ELECCIÓN DE LOS EQUIPOS
■ El llamado a licitación del equipamiento

— ¿Se lleva a cabo una licitación para la elección del equipamiento que re-
presenta importes significativos (en la medida en que el equipo no va im-
puesto por una estimación preexistente)?
— Incluye: el pliego de condiciones del equipamiento que sirve de soporte a
la licitación
— ¿La descripción de las aplicaciones a procesar?

— ¿Una estimación de los volúmenes presentes y futuros?
— ¿Una lista de las exigencias de explotación, tales como tiempo de res-
puesta, duración de los procesos, procedimientos de reactivación,
confidencialidad, etc.?
— ¿Las fechas de entrega de los equipos a ser respetadas?
— ¿La elección de las prestaciones se halla formalizada y basada en cri-
terios concretos?
* La negociación del contrato

— Prevé el contrato negociado con el proveedor escogido:
— ¿Penalizaciones en caso de retrasos en las entregas?
— ¿Un compromiso sobre la capacidad del equipamiento servido para
procesar las aplicaciones definidas en el pliego de condiciones con los

volúmenes estimados y respetando las exigencias impuestas?
— ¿Un compromiso sobre el tiempo de respuesta del sistema?
— ¿Un compromiso del coste de los incrementos futuros de la configuración?
— ¿Las condiciones del mantenimiento, como costes, modalidades, retra-
so de intervención, etc.?
• Las condiciones de mantenimiento

— ¿Hay un seguimiento cualitativo de los equipos y de su mantenimiento?:
— ¿Media de tiempo de buen funcionamiento (MTBF)?
— ¿Seguimiento de incidentes y averías?
— ¿Rapidez y calidad de las intervenciones de mantenimiento?

- ¿Se ha estimado el coste de mantenimiento de los equipos?
— ¿El plazo de intervención contractual se corresponde con las necesidades?
— ¿Se han estudiado soluciones del tipo «mantenimiento por parte de
terceros»?
— ¿Se renegocian las condiciones regularmente?
C. CUESTIONARIO RELATIVO A LA ELECCIÓN DE PROGRAMAS
- ¿Se redacta un pliego de condiciones previamente a la elección de los pro-

gramas (salvo cuando esto es impuesto por una situación existente con an-
terioridad, como por ejemplo el caso de cierto paquete de software básico
del fabricante)?
- Incluye el pliego de condiciones del programa:
—¿la descripción de las funciones a procesar?

—¿los volúmenes a procesar?
—¿los plazos para el arranque?
—¿las obligaciones en materia de seguridad?
—¿los datos básicos que deben ser controlados en los ficheros?
—¿una descripción de las funciones cuya entrega podría ser solicitada en
una segunda etapa?
- ¿Se estudian y comparan varios programas antes de la elección definitiva?
- Se apoya la elección definitiva sobre:
— ¿la calidad de las propuestas recibidas?

— ¿visitas a compañías que tienen el programa?
— ¿consideraciones generales sobre el proveedor, como: envergadura,
notoriedad, calidad de los interlocutores, etc.?
— ¿las consideraciones concernientes al programa, como: número de re-
ferencias, perennidad previsible, etc.?
— ¿la calidad de la documentación del programa?
- Prevé el contrato firmado con el suministrador del servicio:
— ¿un compromiso por el procesamiento de las aplicaciones previstas en
el pliego de condiciones?
— ¿un compromiso por el procesamiento de los volúmenes previstos en el
pliego de condiciones?
— ¿las penalizaciones, en caso de retraso por parte del colaborador?
— ¿la definición precisa de la asistencia prestada, como: formación, do-

cumentación, asistencia en el arranque, mantenimiento inicial, etc.?
— ¿las condiciones del mantenimiento del programa?
— ¿las condiciones de pago del coste de la prestación?7
- ¿Está previsto que la empresa disponga de los programas fuente?
7. Por lo general, se prevé un calendario de pagos en función del avance de las prestaciones:
— el primer adelanto al efectuar el pedido;
— pago contra entrega de software después de la «factura provisoria», o sea, de la valida-
ción por parte del cliente basándose en un juego de prueba; se retiene un saldo de garantía
hasta «la factura definitiva».
— pago del saldo cuando se emite la «factura definitiva», después de algunos meses de fun-
cionamiento satisfactorio del software.
La organización general del servicio informático

47
Nota: Aun cuando el colaborador conserve la propiedad del programa
fuente, es deseable que la empresa disponga de una copia, en particular cuan-
do la envergadura de la ESII no permita garantizar la perennidad del progra-
ma; además del interés para la empresa de poder modificar ella misma el soft-
ware en caso de fallo de su proveedor. Nos referiremos en este punto a las obli-
gaciones en materia contable y fiscal.
— ¿Está prevista una fase de validación del programa sobre la base de un
juego de prueba en el momento del arranque?
— La utilización posterior del programa:
— ¿Está previsto un seguimiento cualitativo del programa, como: históri-
co de los bugs,8 rapidez del mantenimiento?
— ¿La modificación por la propia empresa misma del software servido por
la ESII se evita en la medida de lo posible (en caso contrario, la ESII no
estará más en condiciones de garantizar el mantenimiento de su pro-
ducto y, además, será difícil implantar las versiones siguientes)?
D. CONVOCATORIA A LAS ESII PARA LA REALIZACIÓN

DEL SOFTWARE ESPECÍFICO SOBRE UNA BASE DE PRECIO ALZADO
Siendo el procedimiento relativamente cercano a los de la elección de un

programa, las preguntas del apartado C son siempre válidas. Sin embargo,
pondremos especial interés en algunos aspectos más «sensibles» en el caso de
un software específico:
— La calidad del pliego de condiciones que sirve de base a la relación con-
tractual y el hecho que ésta defina con suficiente exactitud las funciones a
desarrollar.
— Los medios para asegurar el respeto de los plazos de realización por el su-
ministrador del servicio.
— Los puntos de validación intermedios proyectados, como: análisis funcio-
nal (si no vienen íntegramente detallados en el pliego de condiciones), aná-
lisis técnico detallado, etc.
— La calidad de las modalidades de validación del software antes de su pues-
ta en explotación (generalmente sobre la base de un juego de prueba que
sirve de soporte a la «receta provisoria»).
— El contenido de la documentación entregada.
E. CONVOCATORIA A LAS ESII PARA LA REALIZACIÓN

DEL SOFTWARE ESPECÍFICO EN ADMINISTRACIÓN9
En este caso, la ESII tiene por lo general como única obligación aportar el
personal de estudio (ingenieros, analistas y programadores) que se integrarán
en los equipos de desarrollo que trabajan con los proyectos conducidos por la
empresa misma.
8. Anomalía de programa.
9. El término «en administración» consiste en que la ESII factura su asistencia en función del
tiempo empleado por los colaboradores que ella pone a disposición de su cliente.

El auditor se encargará de algunos aspectos específicos relativos a la par-
ticipación de colaboradores externos a la empresa en el proyecto, tales como:
— Modalidades de elección de las ESII.
— Calidad general de los participantes.
— Nivel de responsabilidad confiado a los colaboradores (éstos, en principio,
deben estar a las órdenes del personal perteneciente a la empresa).
— Respeto por parte de los colaboradores externos de las reglas deontológicas
en materia de confidencialidad de la información.
— Seguimiento específico de la actividad de los colaboradores externos.
— Prohibición de acceso de los colaboradores externos a ciertas funciones
(si fuere necesario).
— Coherencia de las tasas diarias de facturación.

Capítulo 3
Los procedimientos
de desarrollo y de
mantenimiento del
software
El desarrollo y el mantenimiento del software son, por lo general, califi-

cados como actividades de «estudio», por oposición a la fase de explotación
(o de producción) posterior al arranque «real» de la aplicación.
Serán, por lo tanto, estudiados en este capítulo los principales ámbitos de
investigación relativos a la auditoría de un servicio de estudio.
3.1 LA METODOLOGÍA DE DESARROLLO DE LAS

APLICACIONES
• P. ¿Se realiza siempre un estudio de oportunidad previo

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

torio y que era completamente inútil sustituirlo. O aún, el diseño de la nueva
aplicación adquiría proporciones considerables y ha parecido más razonable
interrumpirla antes que alcanzara proporciones desorbitadas.
Estas situaciones muy costosas son generalmente el síntoma del mismo
error: la ausencia, al principio del estudio, de una reflexión previa en cuanto
a la oportunidad del proyecto. Esta reflexión tiene como objetivo, después
de un análisis sumario de las necesidades de la arquitectura técnica futura de
la aplicación, estimar el coste global del proyecto, para después pronun-
ciarse sobre la prosecución de su aplicación.
Con el fin de facilitar la decisión, el estudio de oportunidad presentará,
además, las ventajas y los límites del sistema propuesto, las principales
obligaciones inherentes de su aplicación, y un primer calendario de reali-
zación.
La instancia de decisión en cuanto al abandono o la prosecución del pro-
yecto será generalmente el Comité informático o, más directamente, la Di-
rección general. Una decisión llevada a cabo por el servicio informático, o
por el único servicio operativo al que concierne, debe ser evitada, en la me-
dida en que ésta se puede transformar posteriormente en fuente de tensiones,
si se sospecha de parcialidad en su elección por parte de los susodichos ser-
vicios.
Si se da el caso, más allá de la decisión de abandono o de prosecución del
proyecto, se arbitrará un cierto número de decisiones técnicas fundamentales
al final del estudio de oportunidad, tales como: informática centralizada o
descentralizada, prioridades de arranque, desarrollo de software específico o
adquisición de programas, etc.
Por último, hacemos mención a que, si se puede admitir una cierta flexi-
bilidad en el nivel de formalización del estudio de oportunidad (no es, por
ejemplo, deseable exigir de una PYME documentos voluminosos para el
estudio de proyectos «pequeños»), la existencia misma de una reflexión
previa al lanzamiento de cada proyecto es, en cuanto a ella, del todo indis-
pensable.
El estudio de oportunidad incluirá principalmente:
— La presentación sucinta de las funciones a desarrollar.

— Las principales obligaciones de aplicación.
— Si fuere necesario, una presentación de las diferentes soluciones técnicas
entre las cuales será conveniente arbitrar.
— Una estimación de los volúmenes a procesar.
— Una estimación de los costes previstos y, si fuere el caso, de los benefi-
cios financieros esperados.
— Un calendario preventivo de la aplicación.
Desarrollo y mantenimiento del software 51

• P. Ante todo desarrollo de software o toda adquisición
de programas, ¿se analizan las ventajas y los inconvenientes
respectivos de la adquisición de un programa
y de la realización de un sistema específico?
Conviene insistir muy particularmente sobre la utilidad de este análisis.
Muy a menudo, los servicios informáticos desarrollan sistemas de contabili-
dad general o de nómina muy complejos, por el solo hecho de incluir algu-
nas necesidades complementarias de menor importancia en relación a las
prestaciones de los programas disponibles en el mercado.
• P. ¿Se redacta un pliego de condiciones previo al lanzamiento

de la realización de nuevo software?
Evitaremos aquí un debate semántico sobre las diferentes fases de la vida
de un proyecto. Modelos conceptuales y organizativos de los procesamien-
tos y de los datos (vocabulario ligado a la metodología MERISE), análisis
funcional (que define las funciones del software a desarrollar por oposición
al análisis orgánico que definió las especificaciones técnicas), pliego de con-
diciones, etc., son muchos términos cuyo contenido exacto puede variar am-
pliamente de una interpretación a otra.
De todas formas, si el número y el contenido exacto de las diferentes fa-
ses de un proyecto puede variar en función del tamaño de la empresa y de la
importancia de los proyectos, existe un punto de paso obligado en todo pro-
yecto: el acuerdo entre los informáticos y los usuarios sobre el contenido de
la aplicación a desarrollar. Este acuerdo se formalizará imperativamente por
medio de un documento escrito, que llamaremos aquí pliego de condiciones
y que incluirá, en efecto, el conjunto de las especificaciones funcionales del
futuro sistema de información.
De alguna forma, se puede comparar el pliego de condiciones con la re-
cuperación de los puntos de apoyo antes de la ejecución de una volea en un
partido de tenis. Si el atacante no se toma su tiempo para la recuperación de
sus puntos de apoyo, la volea, jugada en desequilibrio, terminará en la red o

fuera de los límites de la pista.
Ocurre lo mismo con el pliego de condiciones. En su ausencia, es casi se-
guro que los programas desarrollados no corresponderán a las necesidades
de los usuarios. El ahorro de algunos días empleados en la redacción, sin
duda alguna trabajosa, de un documento de síntesis, parecerá irrisorio en
comparación con los costes extraordinarios y los retrasos en los plazos que
tendrán origen en esta falta de comprensión.
Y además, esta ausencia de formalización será fuente de conflictos. ¿La
inadecuación del software es consecuencia de una mala expresión de las ne-

cesidades por parte de los usuarios, o bien de un mal análisis por parte de los
informáticos?
Por tanto, la formalización de los análisis preliminares al desarrollo de un
software es el origen de duros debates entre auditores y auditados. Cuántas
veces he oído a los responsables de pequeñas estructuras informáticas afir-
mar terminantemente que, si bien, de una forma general, los pliegos de con-
diciones eran útiles sin ninguna duda, no se justificaban en sus casos particu-
lares. La variedad de los argumentos es además infinita:
— «¡para tal máquina, el análisis funcional es inútil!»;

— «en nuestra empresa, los nuevos desarrollos son escasos y siempre de
poca monta (pero mi predecesor, que había desarrollado varias aplicacio-
nes muy gravosas, no nos ha dejado ningún análisis, lo que nos plantea
grandes problemas»);
— «tenemos los informáticos más importantes y los usuarios más inteligen-
tes y, no obstante, los dossieres son inútiles»;
— «mi Director general tiene toda mi confianza».
El único problema de este cuadro idílico es finalmente que, al salir del

contexto de una auditoría, estos mismos responsables informáticos confesa-
rán sus dificultades imputables, por supuesto, a la incompetencia notoria de
sus interlocutores, cuando ésta no es otra que la de sus propios colaboradores.
En definitiva, la famosa frase de los automovilistas «esto sólo ocurre a
los demás» encuentra del todo su aplicación en los fracasos de proyectos in-
formáticos.
Sin que la lista sea exhaustiva, podemos nombrar como principales docu-
mentos contenidos en el pliego de condiciones:
— La descripción de las funciones a desarrollar.

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

cepción de los ficheros de trabajo).
— La previsión de los volúmenes a procesar.
Según el caso, encontraremos igualmente las modalidades y el calenda-

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

sulta que formarán la aplicación. Si bien estos «modelos» no sustituyen en
ningún caso a un pliego de condiciones, ya que sólo definen los soportes de
entradas y salidas interactivas pero no los procesos en sí, se debería, sin em-
bargo, generalizar de forma progresiva y substituir los diseños demasiado
complejos de la pantalla por soporte en papel.
Las herramientas de preparación de prototipos son, en sí mismas, mucho
más completas, puesto que permiten presentar el conjunto de una aplicación
futura antes de una programación en firme. Su único inconveniente, pero en
justa medida, reside por último en el tiempo necesario para la elaboración
del prototipo.
• P. ¿Existen normas en materia de desarrollo de aplicaciones?

Evidentemente, es totalmente indispensable que se adopte un método en
materia de desarrollo de aplicación. En cambio, la cuestión de saber si un
método reconocido en el mercado es preferible a las normas «de la casa» es
más delicada.
En un entorno de grandes empresas o de administraciones públicas, la
elección de un método ampliamente difundido se impone indiscutiblemente.
Los métodos como el MERISE, el estándar por antonomasia, o el AXIAL
(propuesto por IBM) presentan la ventaja, debido a su amplia difusión, de
ser conocidos por gran número de informáticos y, por lo tanto, de poder ser
impuestos con facilidad en el seno de la empresa. Presentan, además, la ven-
taja de un gran rigor, necesario para el desarrollo de proyectos muy impor-
tantes (más concretamente, consideraremos como importantes los proyectos
cuyo coste global alcanza varias decenas de millones de pesetas).
En las empresas pequeñas o medianas, o bien para proyectos de menor
envergadura, los métodos citados anteriormente representan, por lo general,
el inconveniente de una carga demasiado elevada. Por ello, no es extraño en-
contrar en las empresas métodos «caseros». Se imponen entonces en el desa-
rrollo de un proyecto el respeto de ciertas etapas y la formalización de docu-
mentos cuyo contenido tipo será predefinido.
Se impondrán, por ejemplo
— El estudio previo.
— El pliego de condiciones.
— El análisis técnico.
— Las normas de programación.
• P. ¿Existen normas en materia de programación?

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

finalidad mejorar la calidad de los programas producidos, en la medida que
éstos constituyen una verdadera guía de especial utilidad para los programa-
dores debutantes. Además, conducen a una mejor homogeneidad del con-
junto del software de la empresa.
Distinguiremos con más exactitud:
• Las normas concernientes a la estructura general de los programas
Los métodos como la programación estructurada, o también WARNIER,

proponen una estructura común para el conjunto del software desarrollado.
Además, nos daremos cuenta que ciertos lenguajes de desarrollo (lenguajes
de cuarta generación, generadores de programas) imponen, de hecho, una
estructura de programación.
• Las normas relativas al contenido detallado de los programas
Citamos, por ejemplo:
— los nombres de ficheros;

— los nombres de zonas en los ficheros;
— los nombres de etiquetas en los programas;
— etcétera.
Para poder ser respetadas, las normas de programación serán inscritas en

un documento escrito y difundidas al conjunto del personal de estudios.
• P. ¿Se utilizan herramientas del tipo «taller de ingeniería de software»?

El término «taller de ingeniería de software» (TIS) se utiliza, hoy día,
para designar funciones muy diversas en el desarrollo de aplicaciones. El
producto MAESTRO, de PHILIPS, fue, en los años setenta, el precursor de
los TIS de hoy día. Sus funciones en aquella época cubrían principalmente la
gestión de las bibliotecas de software de estudios y de explotación y la auto-
matización de procesos de puesta en explotación.
Las posibilidades de los TIS son hoy día mucho más amplias puesto que
incluyen a menudo, además de las funciones mencionadas anteriormente, la
asistencia en el diseño del software, la gestión automatizada de las especifi-
caciones y de la documentación, la generación del software a partir de las es-
pecificaciones, etc.
Los TIS se relacionan a menudo con un método de desarrollo, principal-
mente el MERISE. Sin embargo, nos daremos cuenta que, si bien el TIS del

mañana será con certeza una herramienta totalmente integrada que dará una
asistencia al conjunto de las etapas del proceso de desarrollo de la aplica-
ción, esto todavía está muy lejos de ser el caso de la mayoría de los TIS dis-
ponibles en el mercado, de los cuales las diferentes funciones no están siem-
pre del todo integradas las unas con las otras.
De todas formas, el auditor no podrá, en ningún caso, contentarse con
considerar la presencia de un TIS como un punto fuerte y su ausencia como
un punto débil. En efecto, un TIS mal utilizado puede ser totalmente inefi-
caz, cuando algunas herramientas de desarrollo escogidas con acierto pue-
den ser suficientes para una excelente productividad del servicio.
Después de enumerar los métodos y herramientas de producción de apli-
cación, el auditor deberá entonces pronunciarse sobre sus efectos en término
de seguridad y de eficacia del proceso.
• P. ¿Se prevén en el proceso de desarrollo de nuevas aplicaciones

las principales fases de puesta en práctica de un proyecto?
Salvo excepciones, ciertas fases deben imperativamente estar previstas
en el proceso de introducción de nuevas aplicaciones. Las principales entre
ellas son citadas a continuación.
• La formación de los usuarios
Una mala formación de los usuarios tendrá como consecuencia una utili-
zación anárquica del sistema, con todos los riesgos que esto comporta, o
bien un desinterés, incluso un rechazo, frente a éste. En ambos casos, la apli-
cación está condenada a una fase de arranque, en el mejor de los casos, cier-
tamente agitada.
• La documentación de la aplicación
El contenido y la calidad de la documentación serán nombrados poste-

riormente (apartado 3.3).
• La recuperación de los ficheros
El arranque de una aplicación necesita casi siempre la constitución y la

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

Estas recuperaciones son con frecuencia delicadas y necesitan una parti-
cipación de los usuarios, aunque sólo sea con el fin de confirmar el conte-
nido de los ficheros recuperados.
Una mala previsión de los gastos de recuperación es, así pues, suscepti-
ble de comprometer el arranque de la aplicación.
• El impacto del nuevo sistema en la organización

y en los procedimientos administrativos
Un nuevo sistema informático va seguido, en la mayoría de los casos, de

una reflexión sobre la organización del trabajo, y sobre la aplicación de nue-
vos procedimientos.
En ausencia de una reflexión de este tipo, es previsible que los procedi-
mientos administrativos sean mal adaptados al sistema de información y no
permitan sacar el mejor partido del mismo.
• La implantación física de los equipos
La reflexión sobre el tema permite prever, entre otras cosas:
— La implantación de la o de las unidades centrales (en un sistema bastante

descentralizado, encontraremos una unidad central por emplazamiento).
— El número y la localización geográfica de los terminales, pantallas e im-
presoras.
• La validación del software
Dos métodos complementarios conducen a la validación del software (se

habla, a menudo, de «receta») antes de su puesta en explotación.
— Los juegos de prueba, que permiten simular casos reales. Después de

los juegos de prueba, diseñados y realizados por los informáticos, que
permitirán asegurarse de que los programas están de acuerdo con los

pliegos de condiciones, es indispensable prever los juegos de prueba
para usuarios, los cuales darán validez a la adecuación de la aplicación a
las necesidades y serán, en definitiva, el último control antes del arran-
que.
— La explotación doble, que consiste en hacer funcionar simultáneamente
el software nuevo y el viejo con el fin de comparar los resultados.
Esta última técnica es muy eficaz puesto que la aplicación sustituye los
programas que tienen funciones similares. No obstante, es engorrosa ya que

impone a los usuarios una importante sobrecarga de trabajo, como: doble re-
gistro, doble control. Así pues, está limitada en el tiempo (por lo general, de
uno a tres meses).
Cualquiera que sea el método de validación del software escogido, el
auditor comprobará que los usuarios hayan sido partícipes y que hayan te-
nido la posibilidad de probar las aplicaciones puestas en explotación.
• La seguridad
Si bien la seguridad del sistema de información es primordial en la fase

de explotación, un primer acercamiento en ciertos ámbitos es deseable a par-
tir del diseño. Nombremos, por ejemplo, las reflexiones sobre:
— la lista de personas autorizadas a acceder al sistema y las funciones ase-

quibles a cada una de ellas;
— el medio de control de la validez de los procesos: controles de explota-
ción, controles de bases de datos, etc;
— el respeto por la aplicación de ciertos principios de control interno: con-
trol jerárquico, separación de funciones, continuidad de la vía de revi-
sión, etc.;
— los procedimientos de explotación: recuperación en caso de incidente,
copias de seguridad, emplazamiento de emergencia, etc.
Volveremos más detalladamente sobre el conjunto de estos puntos a lo

largo de la obra.
• P. ¿Se ha llevado a cabo regularmente un seguimiento del avance

y de los costes de los proyectos?
Este seguimiento tiene como objeto el control del avance de cada una de
las tareas elementales que componen los proyectos, con el fin de detectar lo
más rápidamente posible los riesgos de desaciertos en términos de planifica-
ción y de costes.
Varios programas de seguimiento de proyecto se encuentran actualmente
disponibles para grandes sistemas o, con más frecuencia, para microordena-
dor. De todos modos, un simple tablero puede ser suficiente para un segui-
miento eficaz.
Cualquiera que sea la herramienta utilizada, el auditor se preocupará de
comprobar que el responsable del proyecto disponga de los medios adecua-
dos para anticipar a tiempo todo tipo de error, a fin de tomar las medidas ne-
cesarias.

• P. ¿Son los proyectos objeto de una coordinación suficiente?
Por lo general, el carisma del o de los responsables del proyecto es un
factor primordial del éxito del mismo. Para los proyectos más importantes,
la coordinación del mismo debe estar formalizada a través de reuniones pe-
riódicas (por ejemplo: semanales) de los principales responsables.
En realidad, distinguiremos, para cada proyecto cuya envergadura lo jus-
tifique:
• La coordinación entre los equipos de diseño, y posteriormente entre

los equipos de realización
Si la amplitud del proyecto justifica una distribución de tareas entre va-

rios equipos, es deseable una coordinación periódica, por ejemplo, a través
de una reunión semanal de los grupos de trabajo, a falta de la cual los dife-
rentes subproyectos estarían poco integrados entre sí, además que algunas
funciones habrían sido omitidas o tratadas doblemente.
Además, se deben prevenir las fases regulares de validación de los docu-
mentos producidos.
• La coordinación entre los equipos de puesta en marcha
Hemos citado antes algunas de las tareas a tener en cuenta en la puesta en

marcha de un proyecto informático, tales como: recuperación, organización,
formación, etc. Una coordinación general entre estas tareas es indispensable,
aunque sea sólo por evitar que algunas de ellas se tornen «críticas» en térmi-
nos de plazo.
• La coordinación entre los informáticos y los usuarios
Ya hemos subrayado la importancia de la formación de los usuarios. Ge-

neralmente, es necesario prever una información regular de éstos, incluso de
los que no participan en el diseño y la puesta en marcha del proyecto.
3.2 LA CALIDAD DEL SOFTWARE
* P. ¿Se procede con regularidad a los controles de calidad del

software producido?
Un control por sondeo de los programas producidos, llevado a cabo inter-
namente (afectando, a tiempo parcial, las tareas de control a un miembro del

equipo de desarrollo o del servicio informático), o por medio de terceros,
permite entre otras cosas:
— Controlar la calidad de los programas producidos.

— Asegurarse de la homogeneidad de estos programas.
• P. ¿Los nuevos colaboradores son objeto de una atención especial?

Esta atención especial se traducirá de diferentes maneras:
• Una formación teórica y práctica
Esta formación será, naturalmente, más o menos intensiva según el nivel

de experiencia del colaborador. Siendo una verdadera iniciación para un
principiante, se limitará a una formación en los métodos «de la casa» para
un marco definido.
La formación teórica será completada de forma útil por una formación
más práctica, bajo formas diversas, a saber: «padrinazgo» de los recién lle-
gados, paso por diferentes equipos, etc.
• Un control de actividad reforzado
Una experiencia insuficiente del programador está a menudo en el origen

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

estudio?
¡Por más formalizados que sean, los métodos y las normas de desarrollo
y de programación no pueden constituir una garantía absoluta de la calidad
de los programas, porque no será la existencia de las normas la que garantice
que éstas sean respetadas!
Por consiguiente el auditor pondrá todo su interés en llevar a cabo un con-
trol, por sondeo, de la calidad y del respeto a las normas en algunos pro-
gramas.

3.3 LA DOCUMENTACIÓN
• P. ¿Es satisfactoria la calidad de la documentación producida?

Distinguimos en la documentación de una aplicación informática:
— La documentación de estudio, destinada a los equipos de desarrollo y de

mantenimiento.
— La documentación de explotación, destinada al personal de producción.
— La documentación destinada a los usuarios.
• La documentación de estudio contiene entre otras cosas:

— La descripción del contenido de los ficheros.
— La descripción de las cadenas de proceso.
— La descripción detallada de los programas.
— El historial de las operaciones de mantenimiento.
• La documentación de explotación contiene el conjunto de las informacio-

nes y consignas necesarias al personal de producción:
— Descripción y organigrama de las cadenas de proceso.
— Instrucciones para la preparación.
— Descripción de los controles de la explotación a ser llevados a cabo en el
momento de cada proceso.
— Instrucciones sobre la consola.
• La documentación para usuarios contiene:

— La descripción general de las aplicaciones.
— La descripción de las transacciones.
— La descripción de los listados editados.
— La explicación de los mensajes de anomalías.
Para el auditor, además de la calidad y de la cantidad de la documen-

tación, tendrá importancia la flexibilidad de utilización de la misma. Por
lo tanto, una documentación controlada por soporte magnético, con la
ayuda de un programa previsto para esta finalidad, facilitará en gran me-

dida la puesta al día y permitirá la salvaguarda en un emplazamiento ex-
terno.
De un modo general, el auditor igualmente se preocupará de asegurarse
de que la documentación esté al día. Por más completa que sea, ésta se torna,
de hecho, rápidamente inutilizable si no se reflejan en ella de forma inme-
diata las operaciones de mantenimiento.

La ausencia de la actualización regular de los dossieres es tanto más la-
mentable cuanto que hace caducar en algunos meses el pesado trabajo inicial
de construcción de los mismos.
Más concretamente, el auditor podrá operar este control partiendo de las
últimas fichas de mantenimiento de programa, y controlando que las modifi-
caciones correspondientes hayan estado bien reflejadas sobre la documenta-
ción.
3.4 EL MANTENIMIENTO
• P. ¿Qué procedimientos de mantenimiento de software se formalizan?

Las peticiones de mantenimiento de los programas deben ser formaliza-
das y ser objeto de una petición escrita por parte de los servicios de usuarios,
visada por el correspondiente interesado y pasada al responsable de estudio.
Éste, después de dar su conformidad, se encargará de transferirla al jefe de
proyecto correspondiente. Los programas modificados son probados en el
entorno del estudio antes de ser enviados a explotación.
En caso de urgencia, y en particular si la operación tiene por finalidad la
corrección de una anomalía de diseño de los programas, podrá ser perfecta-
mente derogada la exigencia de una petición por escrito. De todos modos,
incluso en este caso, el servicio informático redactará una ficha describiendo
la modificación aportada a los programas.
Además, de una forma general, el conjunto de fichas de mantenimiento
relativas a una aplicación son archivadas en el dossier de ésta.
3.5 LOS PROCEDIMIENTOS DE PUESTA EN

EXPLOTACIÓN DEL SOFTWARE
Este tema, que toca a la vez el entorno de estudio y el de explotación, se

abordará en el próximo capítulo.

Capítulo 4
El entorno
de producción
4.1 LOS PROCEDIMIENTOS DE PUESTA

EN EXPLOTACIÓN
• P. ¿Son satisfactorios los procedimientos de puesta en explotación

del software?
Antes de imaginar un procedimiento «ideal» de puesta en explotación de
los programas, conviene definir los principales objetivos de un buen control
interno en este campo.
• El procedimiento de puesta en explotación debe garantizar una

buena separación entre las funciones de estudio y las de explotación
Concretamente, el personal de estudio no debe tener acceso a las biblio-

tecas de programas de explotación, como tampoco a los ficheros de explota-

ción. Este objetivo, además, tiene como propósito más bien prevenir los ries-
gos de error de manipulación que los riesgos de operaciones fraudulentas
por parte del personal de estudio.
• El procedimiento de puesta en explotación debe, en todo momento,

garantizar que estén disponibles en las bibliotecas los programas
fuente correspondientes a los programas objeto en explotación
¡Atención!: el programa «fuente» es el programa escrito por el informá-

tico en un lenguaje evolucionado y comprensible por el ser humano, el pro-
El entorno de producción 63

grama «objeto» es el lenguaje compilado, o sea, transformado en código bi-
nario directamente ejecutable por la máquina. El lenguaje objeto, casi ilegi-
ble por el ser humano, se conserva en máquina:
— Por un lado, el programa fuente, en una biblioteca de programas fuente,

que será modificada, después compilada, en caso de operación de mante-
nimiento de aplicación.
— Por otro, el programa objeto, listo para ejecución, en una biblioteca de
programas objeto; en realidad, y más precisamente, algunos programas
objeto deben ser conectados los unos a los otros antes de ejecutarlos. Se
trata de la fase de edición relacionada (linkedit) que transforma los mó-
dulos objeto en módulos ejecutables (load-modules).
En ausencia de programas fuente, o bien en presencia de programas

fuente no compatibles con los programas objeto en ejecución, el manteni-
miento de la aplicación será imposible a corto plazo.
• El procedimiento de puesta en explotación debe permitir conservar el

historial de traslado de programas en el entorno de explotación
Este historial permitirá entre otras cosas:
— Elaborar estadísticas tales como: puestas en explotación por programa,

cantidad de mantenimientos por programa y por aplicación, etc.
— Efectuar búsquedas, si fuere necesario, en caso de accidente, sobre la fe-
cha de las últimas modificaciones de un software.
Si es posible, durante el proceso se tendrá en cuenta guardar la penúltima

versión de todo programa en explotación, con el fin de facilitar una «vuelta
atrás» en caso de anomalías de proceso en la última versión.
* * *
Aclarados estos objetivos, veremos a continuación, extraídos de la obra

Les techniques de l'organisation informatique, las grandes líneas de un pro-
cedimiento de puesta en explotación «ideal».
El equipo de desarrollo trabaja en un entorno de prueba y utiliza para este
fin la biblioteca de programas de comprobación, en particular una biblioteca
de programas fuente (que llamaremos BIB.TEST.FUENTE) y una biblio-
teca de programas objeto, compilados (que llamaremos BIB.TEST.OB-
JETO).

En el entorno de explotación es evidentemente necesario manejar una biblio-
teca de programas objeto, ejecutables (que llamaremos BIB.EXPL.OBJETO).
Por otro lado, se conservará una copia de los programas fuente en una bi-
blioteca de entorno de explotación, que llamaremos BIB.EXPL.FUENTE.
El procedimiento de puesta en explotación de un programa PGM, esque-
matizado en la figura 2, será el siguiente:
a) El programa fuente se transfiere del entorno de prueba al de explotación,

bajo control del personal de explotación.
b) El programa fuente es recompilado en el entorno de explotación.
Figura 2. Procedimiento de puesta en explotación.

Eventualmente, el programa fuente y el programa objeto pueden ser des-
truidos en el entorno de prueba. En el caso de operaciones de mantenimiento
posteriores, el programa de comprobación será devuelto del entorno de ex-
plotación al de prueba. Entonces, después de la realización y comprobación
de las modificaciones del software, el programa fuente corregido será trans-
ferido y recompilado en el entorno de explotación.
Además, la versión precedente será generalmente conservada de manera
que se disponga, para cada programa, de la última y de la penúltima versión
de los módulos fuente y objeto.
Tratándose de la aplicación práctica de este procedimiento, se pueden su-
poner las modalidades siguientes:
— El responsable de la aplicación prepara su petición en un fichero de peti-

ciones de traslado.
— Periódicamente, el responsable de los traslados revisa el fichero de peti-
ciones y procede a la ejecución de estos traslados.
— Un fichero histórico de traslados se actualiza. Si fuere necesario se podrá
saber de este modo el plazo de las puestas en explotación por programa,
por aplicación, por peticionario, por orden cronológico, o según cual-
quier otro criterio.
4.2 LOS PROCEDIMIENTOS DE TOMA

DE DATOS
Recordemos a continuación que la toma de datos puede realizarse:
— En tiempo diferido, a partir de impresos rellenos por los servicios de

usuarios en los equipos dedicados a la recogida de datos; la toma cono-
cida como «masiva» está también asegurada por las «perforadoras ve-
rificadoras» en los «talleres de toma de datos» especializados en esta
función; los talleres de entrada de datos están, hoy día, en vías de desapa-
rición, pero todavía se justifican en algunos casos particulares.
— En tiempo real, es decir, con actualización inmediata de los ficheros. La
entrada está también asegurada ya sea directamente por los usuarios, o
bien por los servicios que aseguran una toma masiva «inteligente». Así
pues, en tema comercial, los pedidos serán recogidos, según sea el caso,
por los mismos vendedores, por sus secretarias (por ejemplo, cada día
después de la centralización de los pedidos del día), o también por un
servicio de administración de ventas. De la misma forma, en un estable-
cimiento financiero, las operaciones en el mercado serán registradas,

bien por los mismos operadores, o bien por un servicio de registro y control
en el seno de un middle office o de un front office.
• P. Los principios de un buen control interno, ¿ se respetan en el

software de toma de datos?
Los principales elementos de un buen control interno de los procedimien-
tos de toma de datos son:
— Cuando la entrada se realiza partiendo de un impreso, la existencia de un

visto bueno de una persona autorizada controlado por el personal de in-
troducción.
— La doble introducción (únicamente en el caso de introducciones masivas
en tiempo diferido).
— La existencia de claves de control para los códigos numéricos. Los erro-
res de introducción del código también serán rechazados inmediata-
mente.
— El control por totalización de los lotes de introducción, que comprueba
que todo documento haya sido introducido una única vez con los impor-
tes exactos.
— El control de la existencia en la mesa o en el fichero de los códigos intro-
ducidos.
— Los controles de compatibilidad (ejemplo: control de compatibilidad del
día, del mes y del año en la introducción de una fecha); en algunos casos,
la introducción de datos redundantes será voluntariamente prevista con
la finalidad de control [ejemplo: entrada, en una factura, del importe sin
impuestos (A), del IVA (B) y del importe total (C). El programa de intro-
ducción comprueba que C = A + B].
— La visualización para validación desde la introducción del texto corres-
pondiente (sólo en caso de introducción interactiva) al código introdu-
cido: por ejemplo, en el momento del registro de una factura de provee-

dor, el nombre del proveedor se fija a partir del código de proveedor
registrado.
— La edición para análisis eventual de la lista exhaustiva de los datos regis-
trados y, si fuere el caso, de una lista por exclusión de los datos más «sig-
nificativos».
* * *

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 reali-
dad);
— que los datos introducidos no tengan errores (principio de exactitud).
Volveremos posteriormente sobre los controles propios de los procedi-

mientos de autorización.
4.3 LA EJECUCIÓN DE LOS PROCESOS EN TIEMPO

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

planificación?
La planificación de la ejecución de los procesos es un principio básico de
una organización racional. En su ausencia, el ordenador se puede encontrar
saturado en ciertos períodos (de donde surgen los retrasos en la distribución
de los resultados) y bloqueado en otros.
Además, una planificación sistemática permite comprobar con facilidad
que sólo los procesos planificados y autorizados hayan sido ejecutados.
Los programas de asistencia a la planificación y al ordenamiento de los
trabajos están disponibles hoy día en el mercado (principalmente, para
los más completos, pertenecientes a los grandes sistemas) y gracias a los
cuales:
— Todo proceso ejecutado sin planificación, o bien se rechaza, o bien se

pone en evidencia para ser controlado.
— Los inconvenientes del encadenamiento de trabajos son puestos en pará-
metros, evitando, de esta forma, algunos errores relacionados con los
arranques manuales (trabajo olvidado o, por el contrario, ejecutado do-
blemente, trabajos ejecutados en una mala secuencia, etc.).
En primer lugar, estos programas permiten a los preparadores (o, con

más frecuencia, a los responsables de aplicación), «poner parámetros» du-
rante el día a los trabajos que serán ejecutados por la noche bajo control
único de los teclistas.

• P. ¿Se asume de manera satisfactoria la Junción de preparación
de los trabajos?
Citemos, como principales características de una organización que cum-
pla la función de preparación de los trabajos:
• La calidad de la documentación destinada a los responsables de la

preparación: la calidad de la documentación es, por supuesto, la condición
sine qua non de la calidad del trabajo de preparación por parte de los respon-
sables de la aplicación.
• El carácter de intercambiabilidad de los responsables de apli-

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

eficaces reducen muchísimo los riesgos de errores de explotación al limitar
al mínimo estricto el número de parámetros a ser modificados en el mo-
mento de cada explotación.
Los JCL, por lo general, son modificados por los responsables de aplica-
ción en el momento de la puesta en explotación de una nueva cadena de pro-
ceso, con la preocupación de optimizar las actuaciones de explotación, que
no siempre tienen los equipos de desarrollo.
Además, las herramientas de automatización de la explotación (genera-
ción automática de los JCL, gestión de recuperación, gestión de las gene-
raciones sucesivas de un mismo fichero, gestión de las copias de seguridad,
etc.) participan de forma notable en la reducción del número de los paráme-
tros de explotación.
• P. ¿Las cadenas de proceso son sistemáticamente objeto de con-

troles a posteriori?
Podemos distinguir entre los controles de una cadena de proceso:
— Los controles sobre la coherencia técnica de la explotación.

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

• Los controles sobre la coherencia técnica
Estos controles llevan, por ejemplo:
— A las cantidades de registros procesados.

— Al contenido de las bases de datos.
— Al buen fin de los procesos (por el análisis de los mensajes y los indica-
dores de fin de proceso).
— A la coherencia de los listados editados.
Un buen número de estos controles pueden, además, ser informatizados

en gran medida, ya sea por la creación de «codificadores numéricos» auto-
máticos, o bien por la utilización de programas existentes en el mercado, en
particular para el control del buen fin de los procesos.
• Los controles sobre la coherencia funcional de la explotación
Si bien es absolutamente deseable que estos controles sean llevados a

cabo por el servicio informático, en la práctica, hace varios años, hay una
tendencia a transferir la responsabilidad a los servicios destinatarios.
La razón principal radica en la imposibilidad ante la cual se encuentran
los servicios informáticos para definir y realizar los controles funcionales
pertinentes.
Lo cual no quiere decir que estos controles de coherencia funcional re-
vistan una importancia primordial.
• P. ¿Están claramente definidas las modalidades de recuperación

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

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

caso de ausencia del responsable de aplicación, estará previsto proporcionar
al teclista un manual de explotación que describa exactamente el procedi-
miento de recuperación a seguir.
4.4 EL CONTROL DE SUPERVISIÓN DEL ENTORNO

DE PRODUCCIÓN
* P. ¿Existen herramientas de control y de asistencia destinadas a

los teclistas?
Si bien en los grandes centros los teclistas trabajan sistemáticamente en
equipo, no ocurre siempre lo mismo en los pequeños. En algunos casos, los
trabajos no urgentes son iniciados y ejecutados por la noche en ausencia de
cualquier presencia humana (a excepción, si es posible, de los guardias de
seguridad o bomberos). En caso de incidente, los trabajos se interrumpen y
se vuelven a iniciar la mañana siguiente.
Además, en los grandes centros hay cada vez más herramientas de con-
trol y asistencia al trabajo de los teclistas: prohibición de transmitir ciertos
pedidos, respuestas automáticas al ordenador, etc.
Esta automatización permite enfocar la actividad de los teclistas hacia ta-
reas más delicadas, en particular el tratamiento de algunos tipos de inciden-
tes. Correlativamente, la automatización es acompañada siempre en los
grandes centros de una centralización de funciones de tecleado, con la crea-
ción de equipos que tengan la responsabilidad simultánea de varias unidades
centrales.
4.5 EL CONTROL DE LA CALIDAD,

DE LA PRODUCCIÓN INFORMÁTICA
• P. ¿Hay un seguimiento de la calidad de las prestaciones

suministradas ?
Este seguimiento asume formas variadas:
— Disponibilidad de la máquina y de la red.

— Tiempo de respuesta de las aplicaciones interactivas.
— Frecuencia de incidentes por software.

— Frecuencia de retrasos en la distribución de los listados, y retraso medio
constatado.
— Cantidad de operaciones de mantenimiento por aplicación.
— Etcétera.
• P. ¿Existe un seguimiento destinado a optimizar las actuaciones

del sistema informático?
Este seguimiento asume también formas variadas:
— Tasa de carga de la unidad central.

—- Tasa de llenado de los discos. .,
— Frecuencia de las entradas-salidas.
— Seguimiento del tiempo de proceso por software de aplicación.
— Seguimiento de la utilización de la red.
— Etcétera.
• P. ¿Se edita y archiva sistemáticamente el «diario de a bordo»

del (de los) ordenador(es)?
Recordamos que este diario de a bordo (printlog) describe en una forma
más o menos detallada (parametrable), el historial de las órdenes dadas al
sistema de explotación y los mensajes recibidos de éste.
Cada mensaje viene de esta manera a alimentar un fichero, que podrá
ser utilizado con fines de búsqueda después de cualquier incidente de explo-
tación.
El auditor comprobará en particular:
— que el tamaño del fichero permita contener el historial de los mensajes

durante un período suficientemente largo (que comprenda de uno a va-
rios días);
— que el «diario de a bordo» sea objeto de salidas en papel, archivadas

igualmente durante un período que sea suficientemente largo (algunos
meses).
Una recomendación, formulada a menudo por los auditores, de que el

diario sea regularmente objeto de controles por sondeo, por parte del jefe de
sala por ejemplo, parece relativamente poco realista teniendo en cuenta el
volumen de este documento.

4.6 LA GESTIÓN DEL ESPACIO EN DISCO
• P. ¿Se realiza regularmente un análisis del contenido de los discos

para suprimir ficheros inútiles?
La proliferación en el espacio del disco de ficheros totalmente inútiles
constituye un síndrome común a casi todos los centros de proceso.
Es, por lo tanto, indispensable que se lleven a la práctica procedimientos
que permitan reconocer estos ficheros inútiles. Citemos por ejemplo:
— El censo periódico con los jefes de proyecto y los responsables de pro-

ducción de aplicación de todos los ficheros operativos.
— La eliminación automática de los ficheros cuyo nombre no respeta una
estructura definida previamente.
Los programas de gestión automatizada del espacio en disco permiten en

particular luchar contra esta proliferación de ficheros inútiles.
* P. ¿La implantación de los ficheros en los discos es objeto de una

optimización?
En efecto, una optimización de la implantación física de los ficheros en
los discos permite:
— Disminuir el tiempo de ciertos procesos, ya sean interactivos o en tiempo

diferido.
— Mejorar la seguridad.
4.7 LA GESTIÓN DE LAS BIBLIOTECAS DE PROGRAMAS

Ya hemos mencionado, por medio de los procedimientos de puesta en ex-

plotación (apartado 4.1), la gestión de las bibliotecas de programas. Nos li-
mitaremos a mencionar aquí algunos objetivos de una gestión sana:
— Conservar en las bibliotecas sólo los programas efectivamente utilizados.

— Tener la seguridad de que están disponibles en las bibliotecas todos los
programas fuentes correspondientes a los programas objetivo utilizados.
— Dar al personal de estudio y de producción un máximo de procedimien-
tos automatizados de gestión de las bibliotecas (puesta en explotación,

traslado de un programa del entorno de producción al entorno de prue-
ba, etc.).
— Prohibir al personal no autorizado la entrada a las bibliotecas.
4.8 LA GESTIÓN DE LAS COPIAS DE SEGURIDAD
Nota previa: el soporte físico de la copia de seguridad no tiene ninguna

incidencia particular en la política general. Las cuestiones siguientes se
aplican entonces indistintamente a las copias de seguridad en cintas o en car-
tucho.
Si bien la finalidad de las copias de seguridad es fácilmente comprensi-
ble, las modalidades prácticas son a menudo bastante diferentes de un em-
plazamiento a otro. Así, esto se debe a que éstas dependen del tamaño del
centro, de los volúmenes de información a salvaguardar y de los sistemas de
explotación propuestos por el fabricante.
Cualesquiera que sean los procedimientos a aplicar, el auditor se encar-
gará de comprobar que éstos satisfagan los objetivos básicos de una buena
política de salvaguarda, a saber:
— Permitir volver a arrancar todas las cadenas de proceso en caso de fallo

(ejemplo: reempezar con un turno interrumpido por un falta de fluido
eléctrico, o incluso por un fallo de software).
— Permitir corregir un fallo en un soporte físico (ejemplo: un incidente en
un disco lo hace ilegible y obliga a su sustitución física, además de la re-
carga de su contenido a partir de una copia de seguridad).
— Permitir arrancar de nuevo en un emplazamiento exterior en caso de des-
trucción total del emplazamiento de producción.
— Responder a las obligaciones legales en materia de archivo, o sea: obli-
gaciones comerciales, contables y fiscales.
• P. ¿Se salvaguarda regularmente el conjunto del software y

ficheros necesarios para el desarrollo y la explotación?
Imperativamente deben ser salvaguardados:
— El software básico.
— Los ficheros y software de aplicación del entorno de explotación.
— Los ficheros y software de aplicación del entorno de estudio.
La diversidad de los tipos de incidentes que las copias de seguridad de-


ben poder paliar tiene como consecuencia la necesidad de combinar diferen-
tes métodos de salvaguarda.
De este modo, asociamos, por lo general, las copias de seguridad totales
de los soportes físicos (copia total de cada volumen de disco), destinadas a
responder ante una destrucción de estos soportes, a las copias de seguridad
selectivas por naturaleza funcional de las informaciones almacenadas (copia
de cada fichero y de cada biblioteca), destinadas a dar respuesta a las necesi-
dades más localizadas, como por ejemplo: recuperación de una cadena de
proceso, recarga de una biblioteca, etc.
Además, tratándose de copias selectivas de los ficheros y de las bibliote-
cas, los sistemas de explotación proponen la mayoría de las veces, con el fin
de reducir la duración de esta operación, una función de copia de seguridad
únicamente de las informaciones modificadas; por ejemplo, preveremos, a
intervalos regulares, copias de seguridad completas de cada fichero y, entre
éstas, un historial de las modificaciones.
• P. ¿Permiten las copias de seguridad resolver en un plazo

satisfactorio todos los tipos de fallos?
Ilustraremos esta pregunta a través de diferentes ejemplos de una mala
política de salvaguarda.
• Los ficheros y bibliotecas se salvaguardan totalmente una vez por

mes, y, dentro del período, todas las modificaciones son incluidas en
el historial
Esta política es mala pues, para los ficheros y bibliotecas que se modifi-
can a menudo, la reconstrucción de la situación en el momento de un fallo
(en particular cuando éste surge justo antes de una salvaguarda total) será ex-
cesivamente larga.
• Todas las copias de seguridad se realizan por medio de un soporte fí-

sico y no hay ninguna copia selectiva de los ficheros
En esta hipótesis, en el caso de un incidente en una aplicación dada, la re-

construcción de uno o varios ficheros será algunas veces larga, ya que nece-
sita la recarga previa de un disco completo.
• Sólo hay copias de seguridad selectivas de ficheros y de bibliotecas y

ninguna copia total por medio de soporte físico
Es aquí donde, en caso de necesidad de reconstrucción de un soporte fí-

sico (después de la destrucción de éste o después de la destrucción total del
emplazamiento), la carga de trabajo será considerable.
• P. ¿Cuándo el acervo lo justifica, hay un software de gestión de

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

(por ejemplo, para todo fichero, la versión V se encontrará en el empla-
zamiento y será transferida a un emplazamiento externo transformán-
dose en la versión V-l, tornándose la vieja versión V-l sin interés).
— La banalización de las cintas que contienen los ficheros inútiles.
— El control de acceso a las cintas que contengan ficheros activos (y la
prohibición de cualquier modificación de éstas).
El auditor podrá en primer lugar comprobar por sondeo:
— que toda cinta indicada en el programa esté bien colocada en el sitio geo-
gráfico de almacenamiento previsto (y, si fuere el caso, que el nombre y la
versión del fichero contenido en la cinta sean exactamente los indicados);
— que toda cinta presente físicamente esté bien marcada en el programa.
• P. ¿Responde la gestión de las copias de seguridad a las

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

ción de los documentos o declaraciones considerados obligatorios por la
normativa fiscal».
No obstante, dejaremos que cada auditor se preocupe de definir caso por
caso cuáles podrían ser estas copias. Nos limitaremos a subrayar que se trata,
en principio, del conjunto de los ficheros y del software que hayan tenido
una incidencia contable, incluso indirecta, sobre el período no prescrito. Por
tanto, el campo es amplio.
ALGUNAS DISPOSICIONES FISCALES EN MATERIA

DE COPIAS DE SEGURIDAD EN FRANCIA
■ El artículo 97-1 de la Ley de Finanzas para 1982, que completa el ar-
tículo 54 del Código General de los Impuestos, es aplicable a las empresas
afectadas por el régimen de beneficio real.
«Cuando la contabilidad está establecida por medio de sistemas informatiza-
dos, el control se extiende a la documentación relativa a los análisis, a la progra-
mación y a la ejecución de los procesos. Con el fin de comprobar la fíabilidad de
los procedimientos de proceso automatizados de la contabilidad, los agentes de
hacienda pueden llevar a cabo comprobaciones de control en el equipo utilizado
por la empresa cuyas condiciones serán definidas por decreto»
• El decreto ir 82-1142 del 29 de diciembre de 1982 precisa las condi-

ciones de realización de los controles.
«Art. 1º- Cuando las comprobaciones de control previstas por el artículo
97-1 de la Ley de Finanzas para 1982 se realizan en el equipo utilizado por la
empresa inspeccionada, las fechas y las horas de intervención se fijan de for-
ma que sean compatibles con el funcionamiento normal del sistema informáti-
co de la empresa y con el ejercicio del derecho de control de la administración.
Sin embargo, si la empresa lo desea, podrá pedir a los agentes de hacien-
da, cuando éstos lo acepten, que le permitan entregar la copia de las informa-
ciones y del software utilizados por ella. Las copias son hechas en un soporte
informático suministrado por la empresa y respondiendo a las normas que se-
rán fijadas por decreto.
«Art. 2º.- Las comprobaciones previstas en el artículo 1Q llevan en las in-

formaciones, datos y procesos automáticos de cualquier tipo a partir del mo-
mento en que estas informaciones, datos o procesos concurren directa o indi-
rectamente en la formación de los resultados contables y fiscales del período
verificado o en la confección de los documentos o de las declaraciones consi-
deradas obligatorias por el Código General de los Impuestos. Estas informa-
ciones están protegidas por el secreto fiscal.
Art. 3º.- Las comprobaciones y los trabajos de copia previstos en el ar-
tículo lº son realizados por parte del personal habilitado de la empresa o por
el consejero que haya nombrado, bajo el control de los agentes de hacienda.
Art. 4º.- Cuando la empresa utiliza para todos o parte de sus procesos
automáticos los servicios de un detallista o de un suministrador externo, ten-

drá la obligación de permitir a los agentes de hacienda llevar a cabo en el do-
micilio del detallista o del suministrador externo las comprobaciones que esti-
men necesarias para el ejercicio del derecho de verificación. Estas comproba-
ciones se llevan a cabo en las condiciones definidas en el artículo 1º del pre-
sente decreto, incluso en lo que concierne a la posibilidad para los suministra-
dores o detallistas de suministrar copias de las informaciones y del software.»
• El artículo 103 de la Ley de Finanzas para 1990 modifica el artículo L

13 del libro de los procedimientos fiscales.
«Art. 103 - Texto del artículo. - I. El artículo L 13 del LPF se completa
por un apartado redactado así:
«Cuando la contabilidad es llevada por medio de sistemas informatizados,
el control se produce sobre el conjunto de las informaciones, datos y procesos
informáticos que concurren directa o indirectamente en la formación de los
resultados contables o fiscales y en la elaboración de las declaraciones consi-
deradas obligatorias por el CGI así como sobre la documentación relativa a los
análisis, a la programación y a la ejecución de los procesos.»
II. El artículo L 82 del LPF está abolido.
III. Va insertado después del artículo L 102 A del LPF un artículo L 102
B redactado como sigue:
«Art. L 102 B: los libros, registros, documentos o piezas sobre los cuales
se puedan ejercer los derechos de comunicación y de control de la administra-
ción deben ser conservados durante un período de seis años a contar de la fe-
cha de la última operación mencionada sobre los libros o registros o de la fe-
cha en la cual los documentos o piezas fueron establecidos.
Sin perjuicio de las disposiciones del apartado primero, cuando los libros,
registros, documentos o piezas mencionadas en el apartado primero son apo-
yados o recibidos en soporte informático, deben ser conservados bajo esta for-
ma durante un período por lo menos igual al plazo previsto en el artículo L 169.
Las piezas justificativas de origen relativas a las operaciones que dan de-
recho a una reducción en materia de impuestos sobre la cifra de negocio se
conservan durante el plazo previsto en el apartado primero.
Cuando no estén previstos en los apartados precedentes, las informaciones,
datos o procesos sometidos al control previsto en el apartado segundo del ar-
tículo L 13 deben ser conservados en soporte informático hasta el agotamiento
del plazo previsto en el artículo L 169. La documentación relativa a los análisis,

a la programación y a la ejecución de los procesos debe ser conservada hasta ha-
berse cumplido el tercer año después del que corresponde la misma.»
IV. Le sigue al artículo L 47 del LPF un artículo L 47 A redactado como

sigue:
— Art. L 47 A: cuando la contabilidad se lleva por sistemas informatiza-
dos, los agentes de la administración fiscal pueden efectuar la verificación so-
bre el equipo utilizado por el contribuyente.
Este puede solicitar para efectuar él mismo todos o parte de los procesos
informáticos necesarios para la verificación. En este caso, la administración
aclara por escrito al contribuvente o a un representante designado a este efec-

to, los trabajos a ser realizados y el plazo acordado para llevarlos a cabo.
El contribuyente puede igualmente solicitar que el control no sea efectua-
do sobre el material de la empresa. Pone entonces a disposición de la admi-
nistración las copias de los documentos, datos y procesos sometidos a un
control.
Estas copias serán hechas en un soporte informático suministrado por la
empresa, respondiendo a las normas fijadas por decreto.
Al contribuyente se le informa de los nombres y direcciones administrati-
vas de los agentes por los cuales, o bajo control de los cuales, las operaciones
son llevadas a cabo.
Las copias de los documentos transmitidas a la administración no deben
ser reproducidas por esta última y deben ser restituidas al contribuyente an-
tes del cobro.»
V. Va insertado después del primer párrafo del artículo L 57 del LPF, un

párrafo redactado así:
«En caso de aplicación de las disposiciones del artículo L 47 A, la adminis-
tración aclara al contribuyente la naturaleza de los procesos llevados a cabo.»
VI. El artículo L 74 del LPF se completa con el siguiente párrafo:

Estas disposiciones se aplican en caso de oposición a la aplicación del con-
trol en las condiciones previstas en el artículo L 47 A.
VII. El párrafo tercero del artículo 54 del CGI está abolido.
• P. ¿Se llevan a cabo copias de seguridad en emplazamientos

externos?
Un día, durante una auditoría, yo mismo insistía ante un responsable de
informática que guardaba el conjunto de sus copias de seguridad en una caja
fuerte ignífuga: «¿Pero, qué haría Vd. en caso de riesgo de destrucción de su
armario, por ejemplo en caso de explosión violenta?». Este responsable in-
formático, un técnico excelente, me dio una respuesta bastante apabullante:
«¡Exactamente, su pregunta llega en el momento preciso. Hemos tenido un

aviso de bomba la semana pasada; como me he dado cuenta en seguida de
que se trataba de una broma, no hice nada, pero, si hubiera tenido la menor
duda me hubiera ido corriendo de la sala de máquinas para recuperar todas
las cintas de la caja fuerte!».
Una gran mayoría de los responsables informáticos reconocerán de buen
grado que, para evitar tener que tomar decisiones tan valientes como ésta, es
preferible que haya, en un emplazamiento externo, una copia de todos los fi-
cheros y programas necesarios para un back-up en caso de destrucción del
emplazamiento de producción.

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

EMPLAZAMIENTOS EXTERNOS (BACK-UP)
• P. ¿Está previsto un procedimiento que permita en un plazo

satisfactorio un nuevo arranque en otro emplazamiento?
Si bien la noción de plazo satisfactorio puede parecer estar relacionada a
un «determinado tiempo», sin embargo, no es posible aclarar bien esta idea.
En algunas actividades, será indispensable reactivar en las 24 horas, en otros
casos el plazo de 15 días será del todo aceptable.
Entre las principales medidas destinadas a preparar un eventual back-up,
podemos nombrar:
— El contrato de back-up con una sociedad especializada.

— La «sala blanca», sala vacía, equipada con anterioridad para las teleco-
municaciones y lista para recibir los materiales de urgencia en caso de
necesidad.
— El contrato de asistencia con empresas que dispongan de equipos similares.
— El montaje en común de un emplazamiento de urgencia entre varias em-
presas.
— Y por último, la solución que está en auge, la existencia dentro de la em-
presa de dos emplazamientos alejados el uno del otro, en que cada uno es
capaz de asumir el back-up del otro, por medio de la aplicación de proce-
dimientos deteriorados.
No olvidemos por último que, en nuestros días, un plan de recuperación

serio implica que haya sido previsto cuidadosamente el back-up de la red de
telecomunicaciones.

• P. Cuando la recuperación en un emplazamiento externo implica
la aplicación de procedimientos deteriorados, ¿han sido
definidos éstos?
Es muy extraño que el emplazamiento de urgencia permita «procesar»
las aplicaciones en las mismas condiciones que el emplazamiento inicial.
Resulta, por tanto, indispensable definir las aplicaciones y los usuarios prio-
ritarios, es decir, los procedimientos de funcionamiento en modo «dete-
riorado».
• P. ¿Los procedimientos de recuperación en un emplazamiento

externo son comprobados con regularidad?
Sólo el test «tamaño natural» de las recuperaciones detectará las imper-
fecciones del procedimiento teórico: memoria central insuficiente, ficheros
no salvaguardados, usuarios no conectados, etc.
4.10 LA SEGURIDAD FÍSICA

Sólo citaremos aquí las características esenciales del control de la seguri-
dad física del centro de proceso, que es objeto de largos desarrollos en la lite-
ratura.
• P. ¿Está protegido el acceso físico al entorno informático?

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

tar protegido. Los sistemas de autorización más difundidos en el momento
actual son el código digital y el distintivo (que permite, si se diera el caso,
conservar un fichero histórico de las entradas).
En algunas empresas, la localización de la sala de máquinas y su disposi-
ción (planta, ventanas, paredes, etc.) tienen en cuenta los riesgos de motines,
de conflictos sociales, o de cualquier intrusión fraudulenta por medios vio-
lentos. Si fuera el caso, la implantación geográfica del emplazamiento de ur-
gencia se mantendrá en secreto.

• P. ¿Está controlado el acceso físico al lugar de almacenamiento
de las cintas (o cartuchos) magnéticas?
Es conocido por parte de los auditores que un buen número de robos de
información han podido tener lugar dentro de los entornos de alta seguridad,
debido a que las cintas magnéticas, soportes de ficheros sensibles, estaban
almacenadas sin protección.
Por tanto, es deseable que los soportes magnéticos de almacenamiento
estén agrupados en un mismo emplazamiento (con excepción de las copias
de seguridad externas) cuyo acceso será estrictamente reglamentado.
• P. ¿Los locales están protegidos contra incendio?

Distinguiremos:
— Los dispositivos de detección, generalmente basados en la detección del

humo.
— Los dispositivos de extinción; como ejemplos se pueden citar el gas ha-
lón, el gas carbónico, el agua (utilización de aspersores), etc.
Nos daremos cuenta que un procedimiento de alarma, conectado por

ejemplo a un servicio de seguridad, o con los servicios de bomberos, puede
mostrarse más eficaz que un procedimiento de extinción automática (¡hemos
visto algunas veces dispararse inesperadamente aspersores y verter grandes
masas de agua en la sala de las máquinas, dañando gravemente los equipos y
las copias de seguridad magnéticas!).
• P. ¿Los locales están protegidos contra los daños por agua?

Incluso en el mismo París, puede ser peligroso instalar una sala de má-
quinas en el sótano, por ejemplo si éste está situado en los márgenes del
Sena.
• P. ¿Está el centro informático protegido contra los fallos de fluido

eléctrico?
El sistema de alimentación ininterrumpida (SAI) permite, a un coste ra-
zonable, protegerse contra los cortes de alimentación de corta duración.
También lo encontramos en la mayoría de los centros.
Para los cortes de larga duración, por ejemplo en caso de huelga, sólo el
grupo electrógeno puede suministrar la electricidad necesaria. Igualmente,
teniendo en cuenta su coste, sólo será implantado cuando, más allá de las ne-

cesidades puramente informáticas, la prosecución de la actividad de la em-
presa lo justifique.
• P. ¿Se ha previsto un sistema de detección de las intrusiones?

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

El auditor comprobará que se hayan previsto las coberturas financieras
de los riesgos relativos a:
— La destrucción de los equipos.

— La reconstrucción de los ficheros perdidos.
— Las pérdidas de explotación a consecuencia de la falta de disponibilidad
de los equipos.
— Las pérdidas financieras a consecuencia de actos malintencionados o
fraudulentos.
No obstante, tendrá el cuidado de no recomendar sistemáticamente la sus-

cripción de las pólizas más completas. La falta de evaluación de los riesgos
incurridos constituye un error de gestión; en cambio, si los riesgos han sido
evaluados, la decisión de asegurarlos o no constituye una decisión de ges-
tión de la incumbencia de la Dirección general, de acuerdo con los riesgos
incurridos, el coste del seguro y las medidas preventivas que pueden ser
tomadas.
Los contratos de seguro contra los riesgos informáticos pueden ser clasifi-
cados en:
— Los contratos «a todo riesgo informático» (TRI) que cubren, según la ga-
rantía, todos o parte de los riesgos relativos a los sucesos accidentales.
— Los contratos «de extensión a los riesgos informáticos» (ERI), que cubren,
según las garantías, total o parcialmente los daños relacionados con una
utilización no autorizada de los sistemas informáticos (actos fraudulentos
o mal intencionados).
— Los contratos de tipo «informático global» que acumulan las coberturas
relacionadas con los dos tipos de riesgos precedentes.

4.12 LAS OBLIGACIONES LEGALES DE
DECLARACIÓN
• P. ¿Está la empresa suscrita al conjunto de las declaraciones

obligatorias?
Citemos a título de ilustración:
— Las obligaciones relativas a la ley “informática y libertades” que asegura

la protección de los datos nominativos (véase recuadro).
— Las obligaciones relativas a la transmisión de los datos cifrados en las re-
des (decreto nº 86/250 del 18 de febrero de 1986).
— Las obligaciones relativas a la utilización de las redes con valor añadido,
o sea, las redes telemáticas abiertas a terceros y que utilizan las co-
nexiones especializadas (decreto nº 87/775 del 24 de septiembre de
1987).
— Las obligaciones relativas a la «puesta a disposición del público o de cate-
gorías de público por un procedimiento de telecomunicación, de signos, de
señales, de escritos, de imágenes, de sonidos o de mensajes de todo tipo
que no tengan el carácter de correspondencia privada» (ley ne 86/1067 del
30 de septiembre de 1986 relativa a la libertad de comunicación, decreto ns
87-277 del 17 de abril de 1987 y circular del 17 de febrero de 1988).
La ley informática y libertades de Francia del 6 de enero de 1978
Esta ley tiene como objetivo la protección del individuo frente a las
informaciones nominativas controladas por cadenas de proceso automa-
tizado.
Con este propósito:
— el capítulo 2 de la ley instituye la creación de una Comisión Nacional de la
Informática y Libertad (CNIL);

— el capítulo 3 impone que todo proceso automatizado que contenga infor-
maciones nominativas sea objeto de una declaración previa en la Comi-
sión;
— el capítulo 4 aclara las condiciones en las cuales las informaciones nomi-
nativas pueden ser recogidas y conservadas;
— el capítulo 5 es relativo al derecho de acceso de cada individuo a los datos
nominativos que le conciernen;
— el capítulo 6 aclara las sanciones aplicables en caso de falta de respeto a las
disposiciones precedentes.
A continuación veremos algunos extractos de esta ley.

Capítulo III
Formalidades previas a la aplicación de procesos automatizados
Art. 14. - La Comisión Nacional de la Informática y de las Libertades ve-

la por que los procesos automatizados de informaciones nominativas, públicos
o privados, sean llevados a cabo de acuerdo con las disposiciones de la pre-
sente ley.
Art. 15. - Salvo los casos en los cuales deben ser autorizados por la ley, los
procesos automatizados de informaciones nominativas llevados a cabo por
cuenta del estado, de un establecimiento público o de una colectividad terri-
torial, o de una persona física de derecho privado que dirige un servicio pú-
blico, son decididos por un acto reglamentario llevado a cabo después del con-
forme del Consejo de Estado.
Cuando el aviso de la Comisión no es notificado al cabo de un plazo de dos
meses, renovable una sola vez por decisión del presidente, se entiende como
favorable.
Art. 16. - Los procesos de informaciones nominativas automatizados lle-
vados a cabo por cuenta de personas que no están autorizadas por las dispo-
siciones del artículo 15, deben ser objeto de una declaración de la Comisión
Nacional de la Informática y de las Libertades previa a su aplicación.
Esta declaración comporta el compromiso de que el proceso satisface las
exigencias de la ley.
A partir del momento en que ha recibido el comprobante emitido de in-
mediato por la Comisión, el peticionario puede aplicar el proceso. No está exo-
nerado de ninguna de sus responsabilidades.
Art. 17. - Para las categorías más corrientes de procesos de carácter pú-
blico o privado, que no comporten manifiestamente ningún atentado a la vida
privada o a las libertades, la Comisión Nacional de la Informática y de las Li-
bertades establece y publica las normas simplificadas inspiradas en las carac-
terísticas mencionadas en el artículo 19.
Para los procesos que respondan a estas normas, sólo una declaración sim-
plificada de conformidad con una de estas normas es depositada ante la Comisión.
Salvo decisión en particular de ésta, el comprobante de la declaración se entrega
inmediatamente. A partir de la recepción de este comprobante, el peticionario
puede aplicar el proceso. No está exonerado de ninguna de sus responsabilidades.
Capítulo V
Ejercicio del derecho de acceso

Art. 34. - Toda persona que justifique su identidad tiene el derecho de
examinar los servicios u organismos encargados de aplicar los procesos auto-
matizados cuya lista es asequible al público en aplicación del artículo 22 pre-
cedente, con el fin de saber si estos procesos llegan a las informaciones nomi-
nativas que se refieran a ella y, si fuera el caso, obtener comunicación.
Art. 35. - El titular del derecho de acceso puede obtener comunicación de
las informaciones que se refieran a él. La comunicación, en lenguaje claro, de-
be ser conforme al contenido de los registros.

Las normas y deliberaciones de la CNIL han aportado además aclaracio-
nes en cuanto a la aplicación de esta ley. De este modo, están sujetos a decla-
ración simplificada los procesos relativos a la remuneración y a la gestión de
ficheros de clientes y de proveedores. La contabilidad general está exonerada
de cualquier declaración.
Por último, conviene remarcar que, en la práctica, la Ley Informática y
Libertad está lejos de ser aplicada de forma universal y que la falta de decla-
ración casi nunca ha sido sancionada.
Por fortuna, la evolución hacia las aplicaciones microinformáticas no se
hace para facilitar las eventuales investigaciones en estos campos.
A continuación se incluye la legislación vigente en España sobre el trata-

miento o proceso de datos.
Ley informática
Regulación del tratamiento automatizado de los datos de
carácter personal (España)
Ley 5/1992 de 20 de octubre
Esta ley tiene como objeto limitar el uso de la informática y otras técnicas
y medios de tratamiento automatizado de los datos de carácter personal para
garantizar el honor, la intimidad personal y familiar de las personas físicas y
pleno ejercicio de sus derechos.
Se estructura en los siguientes siete títulos principales:
TITULO I, Disposiciones Generales, en el que se recogen los preceptos deli-

mitadores del ámbito de aplicación de la Ley y las definiciones de datos de ca-
rácter personal, fichero automatizado, tratamiento de datos, responsable de
fichero, afectado y procedimiento de asociación.
TITULO II, Principios de la protección de datos, en el cual se desarrollan los

principios generales que definen las pautas a las que debe atenerse la recogi-
da de datos de carácter personal. Estas pautas tienen como finalidad garanti-
zar tanto la veracidad de la información contenida en los datos almacenados
como la congruencia y la racionalidad de la utilización de los datos.
TÍTULO III, Derechos de las personas, que configura jurídicamente las ga-
rantías de las personas —derechos de información, de acceso de los datos y de
rectificación y cancelación, entre otros— como derechos subjetivos encami-
nados a hacer operativos los principios genéricos del Título II. Los derechos
de acceso a los datos y de rectificación y cancelación son las piezas centrales
del sistema cautelar o preventivo instaurado por la Ley.

TÍTULO IV, Disposiciones sectoriales, en el que se distingue entre los distin-
tos tipos de ficheros, según sea su titularidad pública o privada.
TITULO V, Movimiento internacional de datos, que regula los posibles efectos

perniciosos asociados con la transmisión internacional de datos de carácter
personal.
TÍTULO VI, Agencia de Protección de Datos, por el cual se establece la crea-

ción de un órgano independiente, al que se atribuye el estatuto de Ente públi-
co, para el control de la aplicación de Ley con objeto de asegurar la máxima
eficacia de sus aplicaciones.
TÍTULO VII, Infracciones y sanciones, en el que la Ley se limita a tipificar, de

acuerdo con la práctica usual, unos supuestos genéricos de responsabilidad
administrativa, con arreglo a una gradación de infracciones que sigue la dis-
tinción habitual de leves, graves y muy graves.
A continuación, veremos algunos extractos de esta Ley:
TÍTULO I. Disposiciones generales

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

1. La presente Ley será de aplicación a los datos de carácter personal que fi-
guren en ficheros automatizados de los sectores público y privado y a toda
modalidad de uso posterior, incluso no automatizada, de datos de carácter
personal registrados en soporte físico susceptible de tratamiento automati-
zado.
TÍTULO II. Principios de la protección de los datos

Artículo 4. Calidad de los datos
1. Sólo se podrán recoger datos de carácter personal para su tratamiento au-
tomatizado, así como someterlos a dicho tratamiento, cuando tales datos

sean adecuados, pertinentes y no excesivos en relación con el ámbito y las
finalidades legítimas para las que se hayan obtenido.
2. Los datos de carácter personal objeto de tratamiento automatizado no po-
drán usarse para finalidades distintas de aquellas para las que los datos
hubieran sido recogidos.
5. Los datos de carácter personal serán cancelados cuando hayan dejado de
ser necesarios o pertinentes para la finalidad para la cual hubieran sido re-
cabados y registrados.
6. Serán almacenados de forma que permitan el ejercicio del derecho de ac-
ceso por parte del afectado.

Artículo 5. Derecho de información en la recogida de datos
1. Los afectados a los que se soliciten datos personales deberán ser previa-
mente informados de modo expreso, preciso e inequívoco:
a) De la existencia de un fichero automatizado de datos de carácter perso-
nal, de la finalidad de la recogida de éstos y de los destinatarios de la in-
formación.
b) Del carácter obligatorio o facultativo de su respuesta a las preguntas
que les sean planteadas.
c) De las consecuencias de la obtención de los datos o de la negativa a su-
ministrarlos.
d) De la posibilidad de ejercitar los derechos de acceso, rectificación y
cancelación.
e) De la identidad y dirección del responsable del fichero.
Artículo 11. Cesión de datos

1. Los datos de carácter personal objeto del tratamiento automatizado sólo
podrán ser cedidos para el cumplimiento de fines directamente relaciona-
dos con las funciones legítimas del cedente y del cesionario con el previo
consentimiento del afectado.
TITULO III. Derechos de las personas

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

1. El afectado tendrá derecho a solicitar y obtener información de sus datos
de carácter personal incluidos en los ficheros automatizados.
Artículo 15. Derecho de rectificación y cancelación

1. Por vía reglamentaria se establecerá el plazo en que el responsable del fi-
chero tendrá la obligación de hacer efectivo el derecho de rectificación o
cancelación del afectado.
2. Los datos de carácter personal que resulten inexactos o incompletos serán
rectificados y cancelados en su caso.

3. Si los datos rectificados o cancelados hubieran sido cedidos previamente,
el responsable del fichero deberá notificar la rectificación o cancelación
efectuada al cesionario.
TÍTULO VI. Agencia de Protección de Datos

Artículo 34. Naturaleza y régimen jurídico
1. Se crea la Agencia de Protección de Datos.
2. La Agencia de Protección de Datos es un Ente de Derecho Público, con
personalidad jurídica propia y plena capacidad pública y privada, que ac-
túa con plena independencia de las Administraciones Públicas en el ejerci-
cio de sus funciones.

Artículo 36. Funciones
Son funciones de la Agencia de Protección de Datos:
a) Velar por el cumplimiento de la legislación sobre protección de datos y
controlar su aplicación, en especial en lo relativo a los derechos de infor-
mación, acceso, rectificación y cancelación de datos.
b) Emitir las autorizaciones previstas en la Ley o en sus disposiciones regla-
mentarias.
c) Dictar, en su caso y sin perjuicio de las competencias de otros órganos, las
instrucciones precisas para adecuar los tratamientos automatizados a los
principios de la presente Ley.
d) Atender las peticiones y reclamaciones formuladas por las personas afec-
tadas.
e) Proporcionar información a las personas acerca de sus derechos en mate-
ria de tratamiento automatizado de los datos de carácter personal.
f) Ordenar la cesación de los tratamientos de datos de carácter personal y la
cancelación de los ficheros, cuando no se ajusten a las disposiciones de la
presente Ley.
g) Ejercer la potestad sancionadora en los términos previstos por el título
VII de la presente Ley.
h) Informar, con carácter preceptivo, los proyectos de disposiciones genera-
les que desarrollen esta Ley.
i) Recabar de los responsables de los ficheros cuanta ayuda e información
estime necesaria para el desempeño de sus funciones.
j) Velar por la publicidad de la existencia de los ficheros automatizados de
datos con carácter personal, a cuyo efecto publicará periódicamente una
relación de dichos ficheros con la información adicional que el Director de
la Agencia determine.

Capítulo 5
Las funciones
de asistencia técnica
Cada vez más se han desarrollado durante la última década las funciones
de control o de asistencia técnica:
— definición de normas y métodos,

— gestión de las bases de datos,
— infocentro,
— microinformática,
— gestión de redes,
— gestión de la seguridad.
En los grandes centros de procesado, algunas veces, estas funciones están

agrupadas en el seno de una dirección técnica. Éstos son los puntos clave de la
auditoría de estas diferentes funciones que serán estudiados en este capítulo.
5.1 LAS BASES DE DATOS
La generalización de la utilización de los sistemas de gestión de bases de

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

• P. ¿Hay un «administrador de datos»?
El administrador de datos tiene como papel la gestión de los datos de la
empresa (en las PYME) o, en el caso de las aplicaciones importantes, la ges-
tión de los datos de la aplicación.
Es el garante de la coherencia y de la falta de redundancia de los datos
controlados por el SGBD.
Distinguiremos, por lo menos en los grandes centros, la noción de admi-
nistrador de datos, responsable de los datos de la empresa, de la de adminis-
trador de base de datos, responsable de la implantación física de las bases de
datos, de su optimización y de su coherencia técnica (ver a continuación). La
administración de la base de datos es una función de sistema, mientras que
la administración de datos es más bien una función de estudio.
• P. ¿Se utiliza un «diccionario de datos»?

El «diccionario de datos» es un programa que facilita la gestión de los
datos por parte del administrador y su utilización por parte de los equipos de
desarrollo.
• P. ¿Se procede a tareas de búsqueda de optimización de la base

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

administrador de datos en conjunto con los programadores.
• P. ¿Se controla regularmente la integridad de las bases

y la coherencia de los datos?
Se deben controlar regularmente:
— la coherencia técnica de las bases de datos,

— la coherencia funcional de los datos.
Las funciones de asistencia técnica 91

• Coherencia técnica
La técnica de las bases de datos, en cualquier tipo de arquitectura (jerár-

quica, en red o relacional) implica la presencia de apuntadores y de un ín-
dice, que aseguren la relación entre los segmentos (o entre las tablas) y que
eviten de este modo la redundancia de los datos.
No obstante, los incidentes pueden conducir a un deterioro de los apunta-
dores y de los índices, y a una incoherencia técnica del contenido de la base,
conduciendo a la pérdida de algunos datos.
• Coherencia funcional
Si bien es posible controlar la coherencia de los datos en el momento de

su introducción, este control no excluye una degradación posterior de éstos,
por razones diversas (error en un programa a tiempo diferido, modificación
de los datos no controlados, incidente máquina, etc.).
Es, por lo tanto, deseable que las normas de integridad y de coherencia de
los datos puedan ser incluidas en la definición de la base misma, y que el res-
peto a estas normas sea controlado regularmente para el conjunto de los da-
tos de la base.
5.2 LA GESTIÓN DE REDES
• P. ¿Existe una célula técnica de gestión de redes?
En los entornos «gran sistema», la aplicación de una red necesita la elec-

ción de programas coherentes los unos con los otros, para luego proceder a
su implantación y su «parametraje».
La elección de las redes (TRANSPAC, TRANSCOM, TRANSFIX, etc.)
necesita estudios técnicos y económicos.

Por lo general, esta función es atribuida a una célula técnica agregada al
equipo de sistema.
Además de la existencia misma del equipo de red, el auditor controlará
su actividad:
— justificación técnica y económica de las elecciones,

— comprobación de las nuevas configuraciones,
— back-up entre los ingenieros de sistemas, etc.

• P. ¿Existe una célula de asistencia de red?
Contrariamente a la célula técnica precedente, ésta tiene esencialmente
un papel de asistencia a los usuarios:
— instalación de nuevos puestos de trabajo,
— primeros auxilios por teléfono en caso de problema,
— mantenimiento, si éste no está confiado a empresas especializadas,
— gestión de algunas mesas.
En verdad se trata de una función de tipo «SVP», que debe estar disponi-
ble a toda hora para dar respuesta a las necesidades de los usuarios.
• P. ¿Están controlados los accesos a la red?

La existencia de una red implica riesgos adicionales de acceso no autori-
zado, por diferentes razones:
— El número de terminales conectados al ordenador central aumenta cons-
tantemente y éstos pueden encontrarse en posiciones geográficas muy
alejadas.
— Si bien en la mayoría de las aplicaciones la lista de terminales física-
mente autorizados a estar conectados al sistema central se establece de
forma limitativa, es cada vez más frecuente que por razones de flexibili-
dad de utilización los terminales no identificados físicamente sean auto-
rizados a acceder a la red: esto se da, sobre todo, cuando se aplican los
procedimientos de mantenimiento a distancia.
— La gestión de redes combina, la mayoría de las veces, la utilización de lí-
neas privadas (líneas alquiladas) y de redes públicas (red telefónica con-
mutada, TRANSPAC), donde los datos que circulan se mezclan con los
de las demás empresas.
— Por último, algunas aplicaciones informáticas están destinadas, por natu-
raleza, a un acceso público: consulta de cuentas por la clientela en los es-
tablecimientos financieros, consulta de existencias y registro de los pedi-
dos en las empresas industriales o comerciales.
Los diferentes métodos de control de acceso serán estudiados en el capí-

tulo 6.
• P. ¿Se han previsto técnicas de salvaguarda y recuperación

especiales para la utilización de la aplicación
en procesamiento a distancia?
Las técnicas de salvaguarda diaria de los ficheros (por lo general, durante

el proceso nocturno) se encuentran con una gran limitación en el caso de las
aplicaciones interactivas: la actualización permanente de los ficheros o una
copia de seguridad en la víspera o durante la noche, implica introducir otra
vez todos los movimientos del día, en el caso de un incidente y de necesidad
de recuperar a partir de la copia de seguridad.
Además, esta molestia es aceptable en algunos casos a condición de que,
por lo menos, los usuarios obren en consecuencia. En el caso contrario, se
deben aplicar técnicas específicas.
La más frecuente y la más vieja consiste en el registro periódico (log-
ging) de las transacciones. Cada puesta al día de ficheros da lugar a la crea-
ción de movimientos en un fichero-diario, descargado regularmente en cinta
o cartucho. En caso de fallo, la nueva aplicación de los movimientos del día
en la copia de seguridad en la víspera o por la noche permitirá reconstruir la
situación de los ficheros en el momento del incidente.
Más exactamente, el contenido del fichero diario podrá variar de un en-
torno al otro. En algunos casos, contendrá las propias transacciones de ac-
tualización, en otros contendrá la imagen de los registros de fichero modifi-
cados antes y después de la puesta al día.
Una técnica más reciente consiste en crear para los ficheros puestos al día
en tiempo real ficheros «imagen» en un disco distinto de aquel que contiene
los ficheros originales, y puesto al día al mismo tiempo que éstos. De este
modo, en caso de fallo en el disco que contenga el fichero original, será posi-
ble proseguir la aplicación, casi de inmediato, partiendo del disco imagen.
El principal inconveniente de estas técnicas de registro periódico y disco
«imagen», que explica además que no sean utilizadas en ciertos emplaza-
mientos (esencialmente las PYME), reside en el coste. La creación del fi-
chero diario multiplica las operaciones de entradas-salidas («I/O») y re-
quiere también configuraciones de equipamiento más importantes. La
técnica de los ficheros «imagen» es aún más onerosa, debido a que necesita
una duplicación de los volúmenes en disco, que hacen los soportes magnéti-
cos costosos.
Veremos, por último, que la técnica del registro periódico se podría ex-
tender en los próximos años a los procesos en tiempo diferido. Esto ya ocu-
rre con el SGBD relacional DB2 de IBM, que permite periodificar las modi-
ficaciones de la base, salidas, a la vez, de los procesos en tiempo real y en
tiempo diferido.
• P. Si las aplicaciones lo necesitaran, ¿se han previsto

procedimientos de «back-up» de la red?
En el capítulo anterior, hemos enfocado esencialmente los procesos de
recuperación a consecuencia de una indisponibilidad de la unidad central.

Pero existe otro riesgo propio de las redes, que es: la indisponibilidad de un
soporte de transmisión de datos. Es el caso bien conocido, por ejemplo, de la
línea alquilada no disponible durante algunos días debido a que se encuentra
físicamente estropeada.1
Cuando la importancia del software lo justifica, conviene por tanto prever
los procedimientos con el fin de paliar estos fallos. Citemos, por ejemplo:
— Duplicación de una línea especializada por medio de un abono a TRANS-

PAC, preparada para tomar inmediatamente el relevo en la transferencia
de datos.
— El desarrollo de software que permita el procesamiento en el local y en
modo degradado de algunas aplicaciones, en el caso de imposibilidad
total de asegurar la conexión entre los usuarios y el emplazamiento
central.
— La utilización de conexiones TRANSFIX, que permiten sus propias so-
luciones de urgencia.
5.3 LA MICROINFORMATICA
• P. ¿Están coordinadas la adquisición y la utilización de

microordenadores ?
Las propuestas de los auditores no deben acabar en una centralización
abusiva de la política microinformática, que sería mal entendida y marcharía
en sentido contrario a la historia.
Una política de elección y de compra descentralizada en los servicios es
aceptable a condición de ser eficazmente enmarcada.
Por tanto, el auditor se asegurará de que estén coordinadas al nivel de la
Dirección informática:
— La elección de los equipos «aceptados» en la empresa, con vistas a ofre-

cer una diversidad de material suficientemente difundida.
— La elección de las aplicaciones de ofimática «aceptadas»: proceso de
texto, hojas de cálculo, software gráfico, software integrado, gestores de
ficheros, etc.
— La elección de proveedores y la negociación de las condiciones comer-
ciales.
1. Nos acordaremos igualmente de la parada durante varios días del «nudo» TRANSPAC de Lyon, en los
primeros años de funcionamiento de esta red.

— Las modalidades del mantenimiento de los equipos y de los programas.
— La definición de la política en materia de infocentro, y las modalidades
de transferencia de datos entre unidad central y microordenadores.
Es evidente que la falta total de coordinación, que encontramos en algu-

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

transforme en el soporte de un desarrollo anárquico
de aplicaciones autónomas y heterogéneas?
Si bien la microinformática actualmente es un soporte fiable y eficaz
para procesar el conjunto de las necesidades de la empresa en materia de ofi-
mática, su utilización en calidad de soporte del desarrollo de aplicaciones de
gestión, cuando no está sistemáticamente prohibida, debe, por lo menos, ser
estudiada cuidadosamente.
Cantidad de programas de gestión presupuestaria, de gestión del in-
movilizado, de gestión de existencias, de contabilidad general, desarrolla-
dos por principiantes con simples hojas de cálculo o gestores de ficheros,
son verdaderos peligros para el director de empresa. Redactados en pocos
días, puestos en explotación sin verdaderas comprobaciones, estos pro-
gramas raramente ofrecen los controles suficientes en el momento de la
entrada de los datos (que, además, a menudo debe ser realizada doble-
mente, teniendo en cuenta la falta de coordinación con los desarrollos en
gran sistema).
En cambio, bien controlados, los desarrollos en microordenadores, even-

tualmente completados por intercambios de datos con los grandes sistemas,
constituyen un medio valioso para dar satisfacción a los usuarios, descar-
gando los servicios informáticos atascados.
En definitiva, el auditor comprobará:
— que la utilización de la microinformática con la finalidad de desarrollo

de aplicaciones sea conocida por el servicio informático y controlada por
éste (los programas serán, si es posible, desarrollados por el servicio in-
formático);

— que las aplicaciones desarrolladas en estas condiciones estén documen-
tadas correctamente y presenten las mismas garantías en materia de se-
guridad que las aplicaciones desarrolladas en gran sistema:
• control de datos introducidos,
• procedimientos de copia de seguridad y de recuperación,
• control de entrada,
• etcétera.
• P. ¿Está controlado el acceso a las aplicaciones o a los datos

sensibles gestionados por microordenador?
Las técnicas habituales de protección de acceso a los ficheros, a las bi-
bliotecas de programas y a las aplicaciones pueden llegar a ser aplicadas en
un entorno microinformático.
Conviene, no obstante, reconocer que éstas están todavía demasiado
poco difundidas incluso cuando se procesan aplicaciones «sensibles» en mi-
croordenadores.
¿Cuál es la proporción de puestos de trabajo en los cuales las posibilida-
des de control de acceso por contraseña han sido efectivamente utilizadas?
Si bien hace algunos años los microordenadores eran particularmente per-
meables, la negligencia es aún más palpable cuando, algunos de ellos ofre-
cen actualmente posibilidades de control de acceso análogas a las de los
grandes sistemas.
Además, y excepto cuando los microordenadores están conectados en re-
des, las mejores protecciones son en la actualidad las protecciones físicas ta-
les como el bloqueo por medio de llave o tarjeta magnética, o simplemente
cierre a llave de los despachos y armarios.
• P. ¿Se toman las medidas específicas para limitar los riesgos de

robo de los microordenadores?
En las grandes empresas, los riesgos de robo de equipos deben estar

siempre presentes. Este riesgo es tanto más importante que el propio micro-
ordenador. Algunos componentes anexos son susceptibles de ser robados,
tales como: el software, varias tarjetas de extensión, etc.
Entre las medidas preventivas, podemos citar:
— El control de las entradas y salidas de la empresa.

— La identificación precisa de las inmovilizaciones y del inventario físico
regular del conjunto del parque.

• P. ¿La empresa no incurre en ninguna sanción penal por la
implantación de programas sin licencia de utilización?
Muchas grandes empresas han tenido, hasta nuestros días, una actitud
poco ejemplar en este campo ya sea por una política deliberada o bien por
falta de control. El caso de la encuesta realizada en los locales del INPI2 en
noviembre de 1990, que ha puesto en evidencia la implantación en algunos
micros de este organismo de software «desprecintado», mas allá de la anéc-
dota, es del todo significativo.
Ahora bien, el no respeto a la reglamentación implica para la empresa:
— Un riesgo de sanciones penales, previstas en la ley del 3 de julio de 1985

relativa a la propiedad intelectual y artística (ver recuadro).
— Un riesgo de deterioro del parque existente, en caso de la presencia de
«virus» en el software utilizado sin licencia.
Los controles por sondeo de la ausencia de software ilícito en los micro-

ordenadores deben estar previstos.
Ley del 3 de julio de 1985 relativa a la protección

intelectual y artística (Francia)
Esta ley extiende a los autores de software las disposiciones de la ley del 11
de marzo de 1957 relativa a la propiedad literaria y artística. Encontraremos
a continuación las disposiciones del título V, relativas al software.
Título V
De los programas informáticos
«Art. 45 - Salvo cuando se estipule lo contrario, el software creado por
uno o varios empleados en el ejercicio de sus funciones pertenece al empleador
al cual se asignan todos los derechos reconocidos a los autores.
Todo contencioso sobre la aplicación del presente artículo está sometido al
tribunal supremo del lugar de residencia del empleador.

Las disposiciones del primer párrafo del presente artículo son igualmente
aplicables a los agentes del estado, de las colectividades públicas y de los esta-
blecimientos públicos de carácter administrativo.
Art. 46 - Salvo cuando se estipule lo contrario, el autor no puede oponer-
se a la adaptación del software dentro de los límites de los derechos que ha ce-
dido, ni tampoco de ejercer su derecho de arrepentimiento o de retractarse.
Art. 47 - Por derogación del 2B del artículo 41 de la ley nº 57-298 del 11 de
marzo de 1957 anteriormente citada, toda reproducción aparte del estableci-
2. Instituto Nacional de la Propiedad Industrial.

miento de una copia de seguridad por parte del usuario y toda utilización de
un software no autorizado expresamente por el autor o sus derecho habientes,
está sujeto a las sanciones previstas por la mencionada ley.
Art. 48 - Los derechos objeto del presente título se extinguen al venci-
miento de un período de veinticinco años contados a partir de la fecha de la
creación del software.
Art. 49 - El precio de cesión de los derechos de utilización de un software
puede ser global.
Art. 50 - En materia de software, el registro falsificado se ejecuta en vir-
tud a una ordenanza surgida por requerimiento del presidente del tribunal su-
premo. El presidente autoriza, si fuere el caso, el embargo real.
El funcionario instrumental o el comisario de policía puede ser asistido
por un experto designado por el demandante.
A falta de designación o de citación en la quincena del embargo, el embar-
go incorrecto es nulo.
Además, los comisarios de policía tienen la obligación de presentar, si fue-
re pedido por cualquier autor de un software protegido por la presente ley o
por sus derechohabientes, un registro descriptivo del software falsificado, re-
gistro descriptivo que puede ser materializado por medio de una copia.
Art. 51 - Bajo reserva de convenciones internacionales, los extranjeros
gozan en Francia de los derechos reconocidos en el presente título, con la con-
dición que la ley del Estado del cual son ciudadanos o en el territorio en el cual
tienen su domicilio, su sede social o un establecimiento efectivo otorgue pro-
tección a los programas creados por los nacionales franceses y por las perso-
nas que tengan su domicilio o un establecimiento efectivo en Francia.»
* * *
Cabe destacar que la falsificación puede estar penada por una prisión de
tres meses a dos años y/o una multa de 6.000 a 120.000 F.
Pero aquí también, el número de registros fraudulentos es irrisorio en
comparación con el número de copias ilícitas de programas en circulación, in-
cluso en las empresas más grandes.
A continuación en el siguiente recuadro aparece un extracto de la legisla-

ción vigente actual en España sobre derechos de autor en los programas.
Ley de propiedad intelectual. Normas Reguladoras (España)

LEY 22/1987 de 11 de noviembre
Entre sus disposiciones reguladoras para la protección de los derechos de
propiedad intelectual, esta Ley recoge también, en su Título VII, la protección
de los derechos de autor derivados de la creación de los programas de orde-
nador.

TÍTULO VII. De los programas de ordenador
Artículo 95
El derecho de autor sobre los programas de ordenador se regirá por los
preceptos del presente título y, en lo que no esté específicamente previsto en el
mismo, por las disposiciones que resulten aplicables de la presente Ley.
Artículo 96
1. A los efectos de la presente Ley se entenderá por programa de ordenador
toda secuencia de instrucciones o indicaciones destinadas a ser utilizadas,
directa o indirectamente, en un sistema informático para realizar una fun-
ción o una tarea o para obtener un resultado determinado, cualquiera que
fuere su forma de expresión y fijación.
2. La documentación técnica y los manuales de uso de un programa gozarán de
la misma protección que este título dispensa a los programas de ordenador.
3. Los programas de ordenador que formen parte de una patente o un mode-
lo de utilidad gozarán, sin perjuicio de lo dispuesto en la presente Ley, de
la protección que pudiera corresponderles por aplicación del régimen jurí-
dico de la propiedad industrial.
4. La protección establecida en la presente Ley se extiende a cualesquiera
versiones sucesivas del programa, así como a los programas derivados.
Artículo 97
La duración de los derechos de explotación de un programa será de cin-
cuenta años, contados desde el 1 de enero del año siguiente al de su publica-
ción, o al de su creación si no se hubiera publicado.
Artículo 98
El autor, salvo pacto en contrario, no podrá oponerse a que el cesionario
titular de derechos de explotación realice o autorice la realización de versio-
nes sucesivas de su programa ni de programas derivados del mismo.
Artículo 99
1. Se entiende por cesión del derecho de uso aquel acto en virtud del cual el ti-
tular del derecho de explotación de un programa de ordenador autoriza a
otro a utilizar el programa, conservando el cedente la propiedad del mismo.
Se entenderá, salvo prueba en contrario, que la cesión del derecho de uso
es de carácter no exclusivo e intransferible, presumiéndose asimismo que
lo es para satisfacer únicamente las necesidades del usuario.

2. La reproducción del programa, incluso para uso personal, exigirá la auto-
rización del titular del derecho de explotación, con excepción de la copia
de seguridad.
3. No constituye reproducción, a los efectos previstos en el artículo 18 de es-
ta Ley, la introducción del programa en memoria interna a los solos efectos
de su utilización por el usuario, sin perjuicio de su necesaria comunicación
al titular del derecho de explotación cuando así se hubiere pactado.
4. No constituye transformación, a los efectos previstos en el artículo 21, la
adaptación de un programa realizada por el usuario para la utilización ex-
clusiva por el mismo.

Artículo 100
Los derechos sobre los programas de ordenador, así como sobre sus suce-
sivas versiones y los programas derivados, podrán ser objeto de inscripción en
el Registro de la Propiedad Intelectual.
Reglamentariamente se determinarán aquellos elementos de los progra-
mas registrados que serán susceptibles de consulta pública.
• P. ¿Se ejecutan regularmente programas de detección de virus en

los microordenadores?
Estos programas son susceptibles de detectar la presencia de virus en los
microordenadores, permitiendo de este modo desactivarlos antes que éstos
hayan tenido tiempo de causar daños.
5.4 LOS MÉTODOS
• P. ¿Hay en la empresa una función de responsable de

métodos?
El responsable de métodos, si es posible, tendrá a su cargo la definición
del conjunto de las normas propias de la actividad informática, ya sean rela-
cionadas con los procedimientos de desarrollo y de programación o con los
procedimientos de puesta en explotación y de producción.
• P. ¿Las normas son objeto de una difusión sistemática al conjunto

de los colaboradores involucrados?
Por supuesto, los procedimientos de actualización periódicos deben estar
previstos.
• P. ¿Efectúa regularmente el responsable de métodos los controles

con vistas a la aplicación efectiva de las normas?
En ausencia de cualquier control, las normas, teniendo en cuenta su
carácter obligatorio, corren el gran riesgo de caer progresivamente en el
olvido.

5.5 EL INFOCENTRO
La idea de infocentro, o de infoservicio, corresponde a la puesta a dispo-

sición de los usuarios de lenguajes de programación de fácil manipulación,
destinados a preguntas sobre las bases de datos y que permiten descargar
otro tanto a los equipos de desarrollo del servicio informático.
• P. ¿Las herramientas de infocentro están bien adaptadas para la

utilización por parte de los no informáticos?
Muy a menudo, los lenguajes de programación rápida totalmente inadap-
tados a una utilización por los no informáticos por ser demasiado complejos,
son denominados abusivamente lenguajes de infocentro.
En la mejor de las hipótesis, son olvidados totalmente, o peor aún engen-
drarán numerosos resultados erróneos.
En caso de necesidad, en los centros más grandes, se pondrán varias he-
rramientas a disposición de los usuarios, tales como:
— lenguajes simples destinados a peticiones elementales para la mayoría de
ellos,
— verdaderos lenguajes de desarrollo rápido para los más prevenidos.
• P. ¿Está controlado el acceso a las herramientas de infocentro?

El acceso a las herramientas de infocentro debe estar limitado tan sólo a
los usuarios habilitados. Además, lo que más se autoriza es la consulta de da-
tos, no su actualización.
• P. ¿No se desvían las herramientas de infocentro de su objetivo

original en provecho del desarrollo de aplicaciones «pirata»?
La asistencia dada por el servicio de informática para la utilización del
infocentro debe servir para comprobar que éste no es desviado de su función

original.
De hecho, ya hemos mencionado, cuando hablamos de los microordena-
dores, el riesgo relacionado con una proliferación no controlada de aplica-
ciones paralelas desarrolladas por los usuarios mismos.
• P. ¿Se vigilan las cargas-máquinas imputables al infocentro?

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

También es importante realizar seguimientos del consumo por aplica-
ción, por usuario y por servicio, a fin de detectar abusos eventuales.
Este problema debería desaparecer progresivamente en los próximos
años, gracias a la utilización de nuevas técnicas como:
— Equipos dedicados al infocentro.

— Utilización de microordenadores, descargando en primer lugar los datos
del emplazamiento central hacia el microordenador, y después procesán-
dolos otra vez en éste con la ayuda de herramientas apropiadas.
5.6 LA FUNCIÓN SISTEMA
• P. ¿Se ha creado en los grandes centros un entorno específico

para los ingenieros de sistemas?
En los grandes centros de proceso, los ingenieros de sistemas tienen po-
deres muy amplios, por el hecho de que ellos cuentan con los programas o
software de base.
A título de anécdota, los medios para eludir el RACF, software de control
de acceso en los entornos de gran sistema de IBM, son conocidos por la ma-
yoría de los ingenieros de sistemas.
El objetivo de la creación de un entorno específico será permitir a los
«hombres-sistema» comprobar con toda serenidad las nuevas versiones de
los programas de base.
• P. Si se ha elegido desarrollar algún software de base

internamente, ¿se ha justificado debidamente esta elección?
Algunos grandes centros informáticos, en particular en los años setenta
y comienzos de los años ochenta, han elegido desarrollar internamente al-
gunos programas de base como: sistema de gestión de ficheros, sistema de

explotación, monitor de procesamiento a distancia, etc. Esta elección, que
implica a veces cargas de trabajo considerables, estaba justificada por la
necesidad de procesar volúmenes de información muy importantes con
actuaciones que no ofrecían los programas de base disponibles en el
mercado.
Desgraciadamente, el mantenimiento de este tipo de software, por lo ge-
neral escrito en ensamblador, al cabo del tiempo se ha revelado cada vez más
complejo, incitando a los responsables de estos centros a volver a las herra-
mientas estándares, que mientras tanto se hicieron más útiles. No obstante,

en este caso también, la conversión fue a menudo larga y delicada, teniendo
en cuenta sus consecuencias en los programas aplicables.
De una manera general, el auditor se asegurará de que ningún software
de base sea desarrollado en la empresa sin haber sido estudiados los progra-
mas que ofrecen funciones similares. Hoy día, el desarrollo de software es-
pecífico importante debería ser muy excepcional.
Además, podemos preguntarnos si los mismos errores del pasado no se
pueden cometer otra vez, cuando oímos hablar a los grandes grupos, por
ejemplo, que desarrollan su propio software de gestión de redes locales.
5.7 LA FUNCIÓN SEGURIDAD
• P. ¿Hay en la empresa una función de gestión de riesgos?

La seguridad informática es de hecho un aspecto importante de las atri-
buciones del risk-manager.
No obstante, esta función sólo existe por lo general en las empresas de ta-
maño importante.
• P. ¿Hay un responsable de la seguridad en el departamento

de informática?
Cuando existe el cargo, el auditor se encargará de conocer las responsa-
bilidades exactas, las cuales pueden variar bastante de un centro a otro.
Encontrará, por ejemplo:
— la seguridad física de los locales y de los equipos,

— la gestión de los contratos de seguro,
— los procedimientos de salvaguarda,
— los procedimientos de recuperación,

— la definición de los procedimientos de autorización de acceso al entorno,
— la protección de los datos confidenciales.
Algunos aspectos metodológicos podrán igualmente estar subordinados

a este cargo, por ejemplo, la definición de los procedimientos de puesta en
explotación y de control de bibliotecas, o también la definición de los proce-
dimientos de mantenimiento.
Es igualmente deseable que el responsable de la seguridad sea consul-
tado en el momento de los desarrollos de nuevas aplicaciones, con el fin de

asegurar que las molestias relacionadas con un buen control interno sean to-
madas en cuenta desde el principio del proyecto.
Por último, si fuere el caso, el responsable de seguridad será consultado
sobre ciertos aspectos de la organización del servicio de informática.
• P. ¿Hay un plan de seguridad informática?

Este plan, actualizado regularmente, define las medidas a aplicar con el
fin de mejorar la seguridad informática. Constituye a menudo la última etapa
de una auditoría, o incluso de un taller de prueba del riesgo informático del
tipo MARIÓN (apartado 13.4.1).

Capítulo 6
La protección y la
confidencialidad
de los datos
La protección y el control de la confidencialidad de los datos de la em-

presa implica la previsión de tres tipos de manipulaciones:
— El acceso no autorizado a los datos y al software que se encuentran en el

emplazamiento central.
— El robo o la copia de ficheros o software depositado en un soporte mag-
nético de seguridad.
— La conexión física con las líneas de telecomunicación por las cuales cir-
culan 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 ope-
rador fraudulento no solamente la posibilidad de consultar los ficheros y, si
se diera el caso, los programas, sino también de modificarlos con las conse-
cuencias catastróficas que pueden tener las manipulaciones, como: malver-
sación de fondos y destrucción del entorno.

Distinguiremos en las medidas de prevención las siguientes:
— Medidas de prevención de acceso por la identificación del individuo re-

currente.
— Medidas de prevención de acceso por la identificación del terminal recu-
rrente.
— Medidas de prevención de acceso a la forma de los datos y su soporte de
almacenamiento.
6.1.1 Medidas de prevención por la identificación

del individuo recurrente
Estudiaremos primeramente los modos de identificación del individuo

recurrente, después examinaremos las técnicas de software de protección.
6.1.1.1 El modo de identificación del individuo recurrente

Distinguiremos de nuevo:
— la identificación lógica por contraseña;

— la identificación por cualquier medio físico.
a) La identificación lógica por contraseña
La eficacia de una protección de acceso al entorno informático por atri-

bución de códigos de usuarios y de contraseñas supone respetar algunas re-
glas básicas.
• P. ¿Las contraseñas se atribuyen individualmente a cada

usuario?
Las contraseñas colectivas, por ejemplo por servicio o por aplicación, ra-
ramente mantienen su confidencialidad por mucho tiempo.
• P. ¿Las contraseñas deben ser modificadas regularmente?

Algunos programas dedicados al control de las protecciones de acceso
imponen que la contraseña sea modificada con regularidad por su propie-
tario, condición indispensable para una confidencialidad real (la obliga-
ción de una modificación cada trimestre parece ser una periodicidad razo-
nable).
La protección y la confidencialidad de los datos 107

• P. ¿Las contraseñas son suficientemente «sofisticadas»?
Algunas contraseñas son utilizadas tan a menudo que unas cuantas tenta-
tivas son suficientes para dar con ellas. Éstas son, por ejemplo, las iniciales
de los usuarios, su fecha de nacimiento, la fecha de la creación de la contra-
seña, etc. El auditor, por sondeo, procederá al control de la verdadera confi-
dencialidad de algunas de ellas.
• P. ¿Se protege el cuadro de contraseñas?

Además de la protección del acceso al fichero de contraseñas, el auditor
se asegurará de que éste no sea objeto de ediciones regulares.
• P. ¿Es posible detectar las tentativas de acceso no autorizadas?

La identificación, en tiempo real o en tiempo diferido, de las tentativas de
acceso no autorizado permite detectar a tiempo operaciones fraudulentas
eventuales.
No obstante, esta identificación no debe llevar a sospechar sistemática-
mente de todos los usuarios sin razón.
• P. Después de varias tentativas de acceso infructuosas,

¿son desconectados los usuarios?
Por lo general, se prevé una desactivación de un código de usuario des-
pués de tres tentativas de acceso con contraseñas equivocadas. En caso con-
trario, sería fácil, con las técnicas disponibles hoy día, programar en un mi-
croordenador un algoritmo de búsqueda de la contraseña.
* P. ¿Se ha sensibilizado a los usuarios de los riesgos que puede

originar el «préstamo» de sus contraseñas?

Esta pregunta vale a fortiori para las «ventas» de contraseña.
b) La identificación física del individuo que opera
Estas técnicas sustituyen generalmente el uso de contraseñas, y no se

acumulan a ella, salvo aplicaciones de altísima seguridad.

• P. ¿Existen sistemas de autorización de acceso por medio
de tarjeta magnética?
La tarjeta magnética también se refiere al individuo. Esta técnica, tam-
bién costosa, está llamada a desarrollarse en los próximos años.
• P. ¿Existen otros sistemas de identificación?

A título de ilustración citemos el reconocimiento vocal, la identificación
de las huellas dactilares, del fondo de ojo. Estas técnicas están hoy día en
fase experimental y, por supuesto, reservadas a campos específicos de altí-
sima seguridad (militares, etc.)
6.1.1.2 Las técnicas de software de protección

a) Los principales modos de acceso a los datos
Una protección eficaz representa que se tiene que conocer perfectamente
el conjunto de los modos de acceso al entorno informático. Estos modos de
acceso pueden ser clasificados en varias categorías.
• El acceso a través de una aplicación transaccional
Para cada una de las aplicaciones procesadas en una empresa (gestión co-
mercial, gestión de compras, contabilidad, producción, etc.) las transaccio-
nes son puestas a disposición de los usuarios, el acceso inicial se hace, por lo
general, a través de menús. Según sea el caso, las transacciones autorizan la
toma de datos, o la consulta sobre la puesta al día de los datos.
• El acceso a través del arranque de programas en tiempo diferido
Este modo de acceso está, en principio, reservado al personal informá-

tico. Implica la posibilidad de conformar trabajos en el entorno de produc-
ción por medio del editor. Los JCL y los programas a ejecutar son, por lo ge-
neral, almacenados en las bibliotecas previamente a su ejecución, pero es
igualmente posible, si el autor del programa aspira a ser discreto, crear y
conformar un trabajo en tiempo real, sin ninguna copia de seguridad en bi-
blioteca.
• El acceso a través de herramientas de sistemas
Siempre por medio del editor, existe software básico que permite consul-
tar y poner al día los ficheros sin pasar por un programa o una transacción.

Este software básico no deja ninguna pista de las modificaciones llevadas a
cabo.
• El acceso a través de herramientas de infocentro
El infocentro pone a disposición de los usuarios todos o parte de los fi-

cheros de explotación para consultas.
El acceso a las herramientas de infocentro se hace bien por las transac-
ciones dedicadas a este efecto, o bien por medio del editor.
b) La auditoría de las técnicas de software de protección
A continuación encontraremos un conjunto de preguntas cuya única fi-

nalidad es responder a un objetivo más general: ¿el acceso al entorno infor-
mático está limitado sólo a las personas autorizadas? Las respuestas a las
preguntas siguientes, ya sean positivas o negativas, deben ser también inter-
pretadas en su conjunto.
• P. ¿El acceso a las aplicaciones transaccionales está protegido

por contraseña?
El acceso a las transacciones, en principio, está prohibido al personal in-
formático. Cada usuario está autorizado a acceder a algunas transacciones,
definidas de forma limitada en función de su perfil.
• P. ¿Está prohibido a los usuarios el acceso al editor?

Una limitación de acceso eficaz se obtiene orientando a cada usuario, a
partir de su conexión, hacia un menú que contenga sólo las funciones que le
están autorizadas.
En algunos casos, la disponibilidad del infocentro implica que los usua-
rios tengan acceso al editor. En tal caso, se tendrá en cuenta una limitación a
las únicas funciones útiles de éste.
• P. ¿Está protegido con contraseña el arranque de programas en

tiempo diferido?
No obstante, un control de este estilo representa que la contraseña figure
claramente en el JCL. Por esta razón se puede preferir el control de acceso en
el editor. Por lo menos, el acceso a las bibliotecas que contengan el JCL de-
berá estar protegido.

• P. ¿Está estrictamente reglamentado el acceso al software
de sistema de actualización de los ficheros?
En términos de auditoría, los programas básicos son temibles por su faci-
lidad de utilización y por la falta de huellas tras cualquier manipulación lle-
vada a cabo.
Si bien no deben estar prohibidos totalmente (se revelan extremadamente
útiles en algunos casos), su uso debe estar reservado a un número extrema-
damente limitado de personas, y ser objeto de una formalización muy es-
tricta (cualquier intervención será referenciada, y se indicarán los objetivos
y la naturaleza de las operaciones llevadas a cabo).
• P. ¿La utilización de las herramientas de infocentro impide toda

modificación de los ficheros de producción?
El infocentro debe excluir cualquier posibilidad de actualización de los
ficheros de producción. En cambio, es del todo previsible entregar a los
usuarios una copia de todo o parte de estos ficheros para el análisis con un
nuevo proceso eventual. Esta copia estará disponible en el emplazamiento
central, o transferida a un microordenador.
• P. ¿Está previsto el control de acceso a los datos?

Se pueden prever en este campo:
— Controles de acceso a los ficheros; a cada fichero se le asociará una lista

de usuarios autorizados a acceder a él.
— Controles de acceso específicos en el interior de un fichero, a ciertos ti-
pos de datos. A título de ejemplo, en un fichero de personal, distinguire-
mos tres niveles de autorización: el más amplio, para los datos adminis-
trativos, un segundo más limitado, para el acceso a las remuneraciones, y
un tercero, todavía más reducido, para el acceso a los ficheros de cuadros
superiores y dirigentes; los sistemas de autorización específicos están

previstos en algunos sistemas de gestión de base de datos.
• P. ¿Están previstos los controles de acceso a las bibliotecas?

Las bibliotecas de programas en explotación, fuente u objeto, serán trata-
dos con una atención especial.

• P. ¿Están previstos los controles de acceso por volumen-disco físico?
De no ser así, sería imposible reconstruir el contenido de un fichero, ana-
lizando los datos que figuran en el disco físico en el que está implantado.
• P. ¿Los controles de contraseñas están controlados en las tablas y

no están incluidos «en bruto» en los programas?
Aunque en los grandes sistemas existan programas dedicados al control
de las protecciones de acceso, no ocurre siempre lo mismo en los microorde-
nadores, donde los controles algunas veces deben ser programados por los
equipos de desarrollo. El auditor comprobará que las contraseñas estén in-
cluidas en las tablas y fácilmente modificables, y no directamente incluidas
en los programas, en cuyo caso el sistema sería demasiado rígido para ser
eficaz (en efecto, en la segunda hipótesis, es muy posible que las contraseñas
no serían jamás modificadas).
• P. ¿El software de control de autorización de acceso permite

discernir entre la autorización de consulta de los datos
y la autorización de actualización de los mismos?
Las autorizaciones de consulta pueden estar más ampliamente distribui-
das que las de actualización.
Ejemplo: sólo la contabilidad introduce los asientos contables, pero otros
servicios pueden ser autorizados a consultar las cuentas de terceros.
• P. ¿Se ha implantado un software de control de la seguridad?

Los grandes sistemas IBM son la herencia de un cierto número de pro-
gramas dedicados al control de la seguridad. Estos programas tienen en co-
mún la ventaja de controlar la protección del entorno independientemente
del modo de acceso.
Ilustramos esta afirmación por medio de la figura 3. Desde un terminal,

se puede acceder a los ficheros y a las bibliotecas de programas de aplica-
ción a través de diferentes programas básicos, del sistema de explotación
(MVS), del monitor de teleproceso (CICS), del editor (TSO) o de cualquier
programa a tiempo diferido introducido en la lista de espera.
Un primer método de control de acceso consiste en integrar en algunos
de estos programas básicos un proceso de autorización. De este modo, el
monitor de teleproceso CICS posee sus propias tablas de contraseña.
El inconveniente de este método reside en el hecho de que cada programa
básico sólo controla los accesos que utilizan sus propios procedimientos. Por

Figura 3. Ejemplo de acceso a los ficheros y a las bibliotecas en el entorno
de IBM.
ejemplo: el monitor de teleproceso no permitirá a un informático no autorizado

la utilización de las transacciones de consultas de ficheros de personal, pero no le
imposibilitará modificar directamente este fichero con la ayuda del editor.
Por el contrario, los programas de control de seguridad permitirán prote-
ger los recursos (ficheros, bibliotecas, volúmenes discos físicos, bases de da-
tos, transacciones, programas), independientemente del modo de acceso
utilizado. En la figura 4 se muestra una ilustración de este método.
Citemos como ejemplos de estos programas los tres más difundidos ac-
tualmente en el gran sistema IBM:
— RACF del BM;

— TOP SECRET de COMPUTER ASSOCIATES
— ACF2, también de COMPUTER ASSOCIATES, que está avocado a ser
abandonado progresivamente.
c) Los principios funcionales del control de las autorizaciones de acceso
A continuación, volveremos sobre algunos principios fundamentales del

control de las autorizaciones de acceso.

• P. ¿Hay un responsable de autorizaciones de acceso?
Este responsable podrá crear los perfiles de cada director o jefe de servi-
cio, y les proporcionará el conjunto de las habilitaciones necesarias para el
ejercicio de sus funciones. A continuación, cada uno de ellos podrá, a su vez,
definir las habilitaciones que concederá a sus colaboradores.
Figura 4. Ejemplo de un acceso a los ficheros y a las bibliotecas

controladas por RACF en el entorno IBM.
•P. ¿Las habilitaciones están acordes con el principio de un buen

control interno?
El auditor se interesará en particular por:
—El principio de separación de las funciones.

—El principio de control jerárquico.

6.1.2 Las medidas de prevención de acceso
por identificación del terminal recurrente
Cada vez más, las aplicaciones informáticas autorizan, por razones di-
versas, las conexiones a la unidad central desde terminales no identificados
nominativamente por el sistema:
— El ingeniero de sistemas se conecta desde su miniterminal personal para

asegurar un mantenimiento urgente.
— El fabricante se conecta con el sistema central para asegurar el «teleman-
tenimiento», o sea, el mantenimiento a distancia.
— La aplicación «administración de ventas» prevé una conexión de los
vendedores durante sus viajes desde un microordenador portátil.
— Los clientes se conectan desde puestos miniterminal para obtener infor-
maciones comerciales.
Estos tipos de accesos son extremadamente peligrosos, pues la sola pro-

tección contra intrusiones externas reside en la confidencialidad de las con-
traseñas.
En algunos casos, las técnicas de identificación del terminal que se co-
necta permite reducir notablemente el riesgo de intrusión.
• P. ¿Está previsto un procedimiento de identificación física

del terminal que se conecta?
Cuando los terminales susceptibles de conectarse a la unidad central son
conocidos, es posible memorizar sus señas físicas en una tabla. La tentativa
de acceso de cualquier otro terminal será rechazada.
• P. En la utilización de redes públicas, ¿se prevén, si esto

es posible, procedimientos de recuperación automática

del comunicante?
En algunas aplicaciones, se prevén procedimientos de conexión entre la
unidad central y los terminales o microordenadores a distancia a través de
una red pública (red conmutada, TRANSPAC, etc.). Citemos por ejemplo:
— Las tiendas que se conectan cada tarde con sus centrales para «teletrans-
mitir» el fichero de ventas de la jornada.
— Las direcciones regionales de una empresa que introducen sus pedidos
en modo transaccional en el ordenador de la central.

Estos dos ejemplos tienen en común:
— El hecho de que la lista de llamadas posibles (tienda o dirección regio-

nal) está identificada.
— Un riesgo de intrusión si un defraudador potencial conociera el número
del comunicado y simulara una llamada desde una tienda o de una direc-
ción regional.
El procedimiento que permite prevenir este riesgo es, por tanto, el si-
guiente:
— La lista de números (telefónicos o TRANSPAC) de los comunicantes po-

tenciales se encuentra identificada en la unidad central.
— En el momento de cada llamada, el comunicante se identifica.
— Después del control, la unidad central vuelve a llamar al comunicante al
número de abonado conocido registrado en sus propios ficheros.
• P. En el caso de la utilización de una red TRANSPAC, ¿se prevé,

si esto fuere posible, la utilización de un grupo cerrado
de abonados (GCA)?
El grupo cerrado de abonados es un servicio prestado por FRANCE TE-
LECOM en las redes TRANSPAC que permite identificar, para una aplica-
ción dada, la lista de abonados autorizados a llamar los unos a los otros.
Cualquier llamada de un abonado de la red TRANSPAC que pertenezca al
GCA por un abonado que no pertenezca será rechazada.
6.1.3 Las medidas de prevención de acceso a las formas de

datos y su soporte de almacenamiento
• P. ¿Los datos más sensibles son objeto de una codificación?

La codificación consiste en la transformación, con la ayuda de un soft-
ware apropiado, de los datos en un formato que les hace totalmente incom-
prensibles para una persona que no disponga del software.
La operación inversa consiste en remitir los datos en su formato inicial
antes de su utilización para las aplicaciones.
Veremos que la técnica de la codificación sólo puede ser totalmente efi-
caz cuando el acceso a los datos o, por lo menos, al software de codificación,
esté también reglamentado.

• P. ¿Está previsto para algunos ficheros o programas
extremadamente sensibles que sólo sean cargados
en el momento de su ejecución?
Esta solución, debido a lo trabajoso de su puesta en práctica, sólo debe
ser considerada en casos muy excepcionales. Encontraremos a continuación
una ilustración concreta.
Imaginemos que una empresa desea imperativamente mantener confi-
denciales las remuneraciones de sus cuadros superiores, pero que, por razo-
nes prácticas, desea que sus fichas de nóminas estén establecidas por los
mismos programas y en los mismos equipos que las de los demás em-
pleados.
El acceso al fichero de personal será, por supuesto, estrictamente regla-
mentado. Por precaución complementaria, podemos imaginar que los regis-
tros que contengan los cuadros superiores sean objeto de una codificación.
Pero una codificación sólo es eficaz cuando el software de las codificaciones
está también protegido.
Por ello, una solución eficaz consiste en que el software, en vez de estar
almacenado permanentemente en los discos, sea conservado en cinta magné-
tica (guardada en sitio seguro) y cargado en el momento de la ejecución del
programa de nóminas.
El procedimiento del proceso de la nómina será, en este caso, el si-
guiente:
— El responsable carga el programa de codificación y después ejecuta la

aplicación.
— Recupera también los listados de salida.
— Tras la terminación del proceso, destruye el software de cifrado en el
disco.
6.2 EL ROBO O LA COPIA DE FICHEROS

O SOFTWARE QUE SE ENCUENTRAN

EN UNJ3OPORTE DE PAPEL O
MAGNÉTICO
Por soporte magnético, se entiende esencialmente las cintas o cartuchos
magnéticos que sirven para las copias de seguridad o para las transmisiones
de datos.

• P. ¿El acceso al parque de cintas y de cartuchos magnéticos está
reglamentado ?
Recordemos que gran número de robos de ficheros están relacionados
con una insuficiente protección del acceso a los archivos de cintas.
• P. ¿Para los ficheros «sensibles» se evitan los procedimientos de

envíos de cintas o cartuchos «por mensajero» ?
La mayoría de los responsables informáticos tienen en mente por lo me-
nos un caso de ficheros transmitidos por un servicio de entrega (interno o ex-
terno a la empresa) y que no han llegado jamás a su destinatario.
• P. ¿Se han incluido en los ficheros «sensibles» trampas que

permitan comprobar que no hayan sido divulgados en el exterior?
Cuando algunos ficheros son susceptibles de interesar a otras empresas,
de la competencia o no (por ejemplo, los ficheros de clientes), es útil incluir
trampas con el fin de evidenciar inmediatamente cualquier utilización no au-
torizada. Se incluirá, por ejemplo, en el fichero el nombre y la dirección de
uno de los directores, voluntariamente mal ortografiados.
• P. ¿Están previstos, si fuere necesario, procedimientos de

validación de los datos contenidos en los ficheros sensibles?
El caso más conocido es el de ficheros de remesa de nóminas enviados
por las empresas a sus bancos, los cuales deben tener un registro en cabeza
de totalización que permita validar el contenido de la cinta enviada.
Recordaremos, a título ilustrativo, que aunque este procedimiento sea,
por lo general, conocido por la población informática, ha permitido ya de-
senmascarar a defraudadores que habían modificado el importe de su propio
salario en el fichero de remesas, sin pensar en modificar el registro de tota-
lización.
• P. ¿Existe un software que permita controlar la lectura

y la reescritura de las cintas o cartuchos magnéticos?
Es de desear que estén previstos, con la ayuda de un programa de control
de la seguridad o de un programa de control del parque de cintas o cartuchos,
controles que impidan:
— la reescritura de cintas que contengan ficheros activos,

— la lectura de ficheros almacenados en cintas por personas no autorizadas
a acceder a estos ficheros.
• P. ¿Se ha previsto un procedimiento de control específico en el

momento de la edición de listados «sensibles»?
Para evitar el riesgo de difusión de informaciones confidenciales, se pre-
verá, por ejemplo, que algunos listados sensibles sean editados en presencia
del usuario responsable de la aplicación.
• P. ¿Se ha previsto la destrucción sistemática después

de la utilización de los listados que contengan
informaciones «sensibles»?
Hace algunos años, una ESII se hizo involuntariamente bastante célebre
cuando copias de listados confidenciales destinados a uno de sus clientes
fueron substraídas de sus papeleras y difundidas en el exterior.
6.3 LA CONEXIÓN FÍSICA CON LAS LINEAS EN LAS

CUALES CIRCULAN LOS DATOS
• P. ¿Se ha previsto la codificación de las informaciones

confidenciales que circulan en las redes públicas o privadas?
En la medida que es casi imposible controlar la ausencia de conexión no
autorizada en el conjunto de la línea física (incluso en el caso de la utiliza-
ción de la red TRANSPAC, la unión entre la empresa y el punto de entrada
más próximo es propia de ésta), la técnica de la codificación es el medio más
eficaz de evitar el robo de los datos que circulan por las líneas.


Tercera parte
EL CONTROL DE LAS
APLICACIONES
INFORMATIZADAS
Hemos presentado en la primera parte de la obra los objetivos y métodos

de control de una aplicación informatizada.
La fiabilidad de una aplicación pasa siempre por la fiabilidad del control
interno de la función informática propia de ésta. En otras palabras y más
concretamente, el auditor podrá aplicar, al entorno de desarrollo y de explo-
tación propios de esta aplicación, el conjunto de los controles mencionados
en la segunda parte de la obra.
Controlará de esta forma por este sistema:
• Al nivel de la organización general del servicio:

— El seguimiento de los costes.

— El seguimiento cualitativo.
— Las relaciones con los servicios de usuarios correspondientes.
— El respeto a los principios de separación de funciones estudio-explota-
ción-usuarios.
— La evolución de los procedimientos administrativos.
— La calidad y la perennidad de los equipos de desarrollo, de manteni-
miento y de explotación (analistas de aplicaciones).
— Las modalidades de recurso a la subcontratación.
— La elección de los equipos físicos.
— La existencia de auditorías recientes.
El control de las aplicaciones informatizadas 121

• Al nivel de los procedimientos de desarrollo y de mantenimiento:
— La metodología aplicada.
— La calidad del software.
— El contenido de la documentación.
— Los procedimientos de mantenimiento.
— La toma de conciencia, en el momento del desarrollo, de los problemas
de seguridad tales como: control de introducción de datos, integridad de
los datos, continuidad de la vía de revisión, etc.
— Los juegos de pruebas previos a cualquier puesta en explotación.
• Al nivel de la producción:
— Los procedimientos de puesta en explotación.
— La introducción de datos en masa.
— La planificación y el arranque de los trabajos en tiempo diferido.
— Los controles de explotación.
— Los métodos de recuperación en caso de incidente.
— Las copias de seguridad.
— Las modalidades de recuperación en unidad externa.
— El control de las bibliotecas.
— El respeto a las obligaciones declaratorias.
— La seguridad física de la unidad y de los materiales dedicados a la aplica
ción.
• Al nivel de la dirección técnica:

— El control de la red.
— La administración de las bases de datos.
— El control de los microordenadores utilizados en la aplicación.
— El infocentro.
— La toma en consideración de las obligaciones relacionadas con la seguri-
dad y con la protección de acceso a los datos.
Además, ya hemos presentado en la primera parte de la obra (apartado

1.3.4), los principios generales de control interno relativos al diseño y a la
utilización de una aplicación informatizada:
— Los controles de usuarios relativos a la coherencia de los datos y proce-

sos de la aplicación.
— Los controles jerárquicos.
— La separación de funciones.

— La continuidad de la vía de revisión.
— La existencia de procedimientos de autorización de acceso satisfactorios.
— La existencia de validaciones regulares del contenido de los ficheros.
— La existencia de juegos de prueba de usuarios previos a toda puesta en
explotación.
— La capacidad y la integridad del personal.
Habíamos igualmente mencionado en la primera parte los diferentes en-

foques prácticos de auditoría de una aplicación, por otra parte complementa-
rios y que son:
— El examen del control interno.

— Los juegos de prueba.
— La utilización de programas de auditoría, que tengan por objetivo ya sea
la validación de algunas cadenas de proceso, o bien la detección de ano-
malías en los ficheros.
El objetivo de esta tercera parte será presentar, para cada uno de los prin-
cipales programas de gestión utilizados en una empresa:
— Una descripción resumida de las modalidades habituales de funciona-

miento de éste.
— La presentación de los principales puntos clave de control durante una
auditoría de la aplicación, aclarando para cada punto el tipo de riesgos
así como las modalidades prácticas del control.
— Las posibilidades de utilización de los programas de auditoría con fines
de control.
En cambio, no se han tratado, o bien son simplemente citadas a título

ilustrativo, las condiciones generales propias de la existencia de un buen
control interno (confidencialidad, fiabilidad de la explotación, documenta-
ción, etc.) ya especificadas en la segunda parte de la obra.
Por último, veremos en la cuarta y última parte una presentación más

concreta de los problemas inherentes de la implementación de la misión:
planificación de la intervención, definición de los medios de investigación
más apropiados, elección de un programa de auditoría.
El control de las aplicaciones informatizadas 123


Técnicas de La Auditoría Informática - (PG 41 - 135) PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Técnicas de La Auditoría Informática - (PG 41 - 135) PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Capítulo 2

2.1 LA ESTRUCTURA DEL SERVICIO

• P. ¿Existe un organigrama escrito del departamento de

Encontraremos en la figura 1 una estructura tipo de servicio informá-

La organización general del servicio informático 29

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

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

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

teriales y del software básicos. Al mismo tiempo, la cualificación del personal

La organización general del servicio informático 31

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

2. Veremos a continuación un ejemplo simplificado intencionadamente con fines pedagó-

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

mente en una misma máquina (multiproceso), el teclista ya no puede conocer

La organización general del servicio informático 33

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

c) Las funciones de sistemas

d) Las junciones técnicas

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

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

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

• P. ¿Hay un plan informático?

La organización general del servicio informático 35

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

2.3 EL SEGUIMIENTO DE COSTES

• P. ¿Hay un presupuesto informático?

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

ser criticados a priori. Puede corresponder a necesidades reales, tales como:

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

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

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

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

— Los costes de desarrollo.

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

recciones de la empresa en preocuparse por controlar sus costes. Con fre-

La organización general del servicio informático 37

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

2.4 LAS PRÁCTICAS CONTABLES Y FINANCIERAS

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

• P. ¿Son coherentes los períodos de amortización elegidos para los

— Tres años para los microordenadores.

Los gastos de desarrollo interno de software específico son la mayoría

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

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

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

— Disponibilidad de la unidad central.

Por otro lado, las herramientas de seguimiento permiten optimizar la con-

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

• P. ¿Se tienen en cuenta en el diseño de nuevas aplicaciones los

— Creación de una estructura de organizadores dependientes del responsa-

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

2.6 LA SEPARACIÓN DE FUNCIONES

• P. ¿Hay en la organización del servicio informático una

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

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

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com

— El control de acceso de los usuarios al entorno informático (palabras

2.7 EL CONTROL DE LA ACTIVIDAD

• P. ¿Se efectúan regularmente misiones de auditoría de la

— Control de seguridad o control de las actuaciones.

Este control puede, además, ser llevado a cabo a diferentes niveles. En

La organización general del servicio informático 41

Derrien, Y. (2009). Técnicas de la auditoría informática. Retrieved from http://ebookcentral.proquest.com