Fecha: 2 9 / 0 5 / 2 0 0 3

UTN
Facultad Regional Córdoba

Materia: Auditoría de Sistemas

C urso: 5 K 3 – Turno Noche
Tema: Plan de Contingencia

Gru p o N º 8
In te g ran te s:
Bonino, Luciano
Durán, Javier
Guzmán, Ariel
Marelli, Maximiliano
U . T. N . - F. R . C . Auditoría de Sistemas

Tabla de Contenidos

1. I n t r o d u c c i ó n ................................................................................................................................ 3
4.1. Propósito.........................................................................................................................................................4
4.2. Descripción General del Resto del Documento .................................................................................4
2. O b j e t i v o ........................................................................................................................................ 5

3. L í m i t e s .......................................................................................................................................... 5

4. A l c a n c e s ....................................................................................................................................... 5
4.1. Identificar y Controlar Riesgos Potenciales. ......................................................................................5
4.2. Analizar el Impacto Sobre el Negocio. .................................................................................................5
4.3. Desarrollar Estrategias de Recupero. ...................................................................................................6
4.4. Determinar los Procedimientos para Estructurar un Plan de Contingencias ..........................6
4.5. Desarrollar Políticas Estándares y Documentar el Plan. ...............................................................7
4.6. Asegurar la Efectividad y la Constante Actualización del Plan. .................................................7
5. I m p l e m e n t a c i ó n d e l P l a n d e C o n t i n g e n c i a ............................................................................ 8
5.1. Niveles de Contingencias ..........................................................................................................................8
5.2. Período Crítico de Recuperación ............................................................................................................8
5.3. ¿Cómo armar un Plan de Contingencias? ...........................................................................................8
5.4. Elementos que Componen un Plan de Contingencias .....................................................................9
5.5. Procedimientos de Respaldo ....................................................................................................................9
5.6. Hardware y Software Alternativo ..........................................................................................................10
5.7. Procedimientos de Emergencia .............................................................................................................11
5.8. Prueba del Plan de Contingencias .......................................................................................................11
5.9. Mantenimiento del Plan de Contingencias ........................................................................................12
5.10. Auditoría del Plan de Contingencias ...................................................................................................12
6. C o n c l u s i ó n ................................................................................................................................. 1 3

7. A n e x o I ....................................................................................................................................... 1 4
7.1. Check List de Auditoría del Plan de Contingencia ........................................................................14
Verificación...........................................................................................................................................................14
8. A n e x o I I ...................................................................................................................................... 1 7
8.1. Definiciones, Acrónimos y Abreviatur as ............................................................................................17
8.2. Referencias ..................................................................................................................................................17

Curso 5k3 - Grupo Nº 8 Pág. 2

U . T. N . - F. R . C . Auditoría de Sistemas

Plan de Contingenc ia
1. Introducción
A finales del siglo XX, los Sistemas Informáticos se han constituido en las
herramientas más poderosas para materializar uno de los conceptos más vitales y
necesarios para cualquier organización empresarial, los Sistemas de Información de la
empresa.
La Informática hoy, está subsumida en la gestión integral de la empresa, y por eso las
normas y estándares propiamente informáticos deben estar en concordancia con los de
toda la organización. En consecuencia, la estructura informática forma parte de lo que
se ha denominado el “management” o gestión de la empresa. Cabe aclarar que la
Informática no gestiona propiamente la empresa, ayuda a la toma de decisiones, pero
no decide por sí misma. Por ende, debido a su importancia en el funcionamiento de
una empresa, existe la Auditoría Informática.
El término de Auditoría se ha empleado incorrectamente con frecuencia ya que se ha
considerado como una evaluación cuyo único fin es detectar errores y señalar fallas. A
causa de esto, se ha tomado la frase “Tiene Auditoría” como sinónimo de que, en dicha
entidad, antes de realizarse la auditoría, ya se habían detectado fallas.
El concepto de auditoría es mucho más que esto. Es un examen crítico que se realiza
con el fin de evaluar la eficacia y eficiencia de una sección, un organismo, una
entidad, etc.
Una Auditoría es un examen crítico pero no mecánico, que no implica la preexistencia
de fallas en la entidad auditada y que persigue el fin de evaluar y mejorar la eficacia y
eficiencia de una sección o de un organismo.
Los principales objetivos que constituyen a la auditoría Informática son el control de la
función informática, el análisis de la eficiencia de los Sistemas Informáticos que
comporta, la verificación del cumplimiento de la normativa general de la empresa en
este ámbito y la revisión de la eficaz gestión de los recursos materiales y humanos
informáticos.
El auditor informático ha de velar por la correcta utilización de los amplios recursos
que la empresa pone en juego para disponer de un eficiente y eficaz Sistema de
Información. Claro está, que para la realización de una auditoría informática eficaz, se
debe entender a la empresa en su más amplio sentido, ya que una Universidad, un
Ministerio o un Hospital son tan empresas como una Sociedad Anónima. Todos utilizan
la informática para gestionar sus “negocios” de forma rápida y eficiente con el fin de
obtener beneficios económicos y menores costos.
Por eso, al igual que los demás órganos de la empresa (Balances y Cuentas de
Resultados, Tarifas, Sueldos, etc.), los Sistemas Informáticos están sometidos al
control correspondiente, o al menos deberían estarlo. La importancia de llevar un
control de esta herramienta se puede deducir de varios aspectos. He aquí algunos:
 Las computadoras y los Centros de Proceso de Datos se convirtieron en blancos
apetecibles no solo para el espionaje, sino para la delincuencia y el terrorismo. En
este caso interviene la Auditoría Informática de Seguridad.
 Las computadoras creadas para procesar y difundir resultados o información
elaborada pueden producir resultados o información errónea si dichos datos son, a
su vez, erróneos. Este concepto obvio es a veces olvidado por las mismas

Curso 5k3 - Grupo Nº 8 Pág. 3

U . T. N . - F. R . C . Auditoría de Sistemas

empresas que terminan perdiendo de vista la naturaleza y calidad de los datos de

entrada a sus Sistemas Informáticos, con la posibilidad de que se provoque un
efecto cascada y afecte a aplicaciones independientes. En este caso interviene la
Auditoría Informática de Datos.
 Un Sistema Informático mal diseñado puede convertirse en una herramienta harto
peligrosa para la empresa: como las maquinas obedecen ciegamente a las órdenes
recibidas y la modelización de la empresa está determinada por las computadoras
que materializan los Sistemas de Información, la gestión y la organización de la
empresa no puede depender de un Software y Hardware mal diseñados.
 La interrupción del funcionamiento de los sistemas informáticos de la empresa,
cualquiera sea la causa que lo origine, puede generar graves inconvenientes al
desempeño de las funciones de la misma. En este caso intervine la Auditoría del
Plan de Contingencia.

Estos son solo algunos de los varios inconvenientes que puede presentar un Sistema
Informático, por eso, la necesidad de realizar Auditoría de Sistemas.

4.1. Propósito
El propósito del presente trabajo es brindar una introducción a la Auditoría de Plan
de Contingencia, dado que el conocimiento y el nivel de especialización que se
requiere para realizar una Auditoría de Plan de Contingencia no pretendemos con
este trabajo enseñar a realizar una Auditoría de Plan de Contingencia; nuestro
propósito es mucho más modesto. En el presente trabajo vamos a presentar el
tema y mostrar los puntos salientes que deben considerarse a la hora de encarar
una Auditoría de Plan de Contingencia. En síntesis lo que buscamos es aportarles
un punto de partida y una guía útil a la hora de a abordar una Auditoría de Plan de
Contingencia.

4.2. Descripción General del Resto del Documento

El presente documento plantea el objetivo y los límites que debe poseer un Plan de
Contingencia; esto nos permite encuadrar el resto del trabajo. Luego desarrollamos
los alcances del Plan de Contingencia para, a partir de allí generar una guía de
implementación del mismo.
Por último cerramos este trabajo con un Chek List genérico que intenta ser una
guía para la realización de Auditorías de Plan de Contingencia.

Curso 5k3 - Grupo Nº 8 Pág. 4

U . T. N . - F. R . C . Auditoría de Sistemas

2. Objetivo
Cuando hablamos de Plan de Contingencia hacemos referencia a un conjunto de pasos
a seguir que se llevan a cabo, en caso que ocurra una contingencia. Esta planificación
tiene como objetivo:
 Maximizar la capacidad de mantener el nivel de procesamiento a un costo
razonable y en el ámbito aceptable.
 Mantener la continuidad del negocio durante el periodo de tiempo que hay entre la
ocurrencia del siniestro y la recuperación total de las facilidades del
procesamiento.
 Minimizar los daños y las perdidas económicas.

Teniendo en cuenta estos objetivos se debe desarrollar un Plan de Contingencias para

recuperar las áreas criticas que han sido afectadas por un desastre físico, como ser:
fuego, inundaciones, falla de energía, cortes de servicios, falta de telecomunicaciones
u otros desastres como robo, accidentes, catástrofe, etc.

3. Límites
Para delimitar el ámbito de este trabajo sobre Auditoría del Plan de Contingencia, se
entenderá que el mismo comprende desde el momento que surge una necesidad de
mejorar cuestiones de seguridad informática o detectar riesgos potenciales, hasta la
entrega del informe final por parte del auditor.

4. Alcances
Todo Plan de Contingencia debe tener cierto alcance y contemplar puntos tales como:

4.1. Identificar y Controlar Riesgos Potenciales.

 Establecer la vulnerabilidad de su organización frente a potenciales desastres.
 Determinar controles para prevenir o minimizar el efecto de posibles
eventualidades:
 Ubicación
 Infraestructura
 Protección (detección, notificación, supresión)
 Procedimientos del personal
 Back up y protección de información
 Seguridad de la información (hardware, software, datos, redes)
 Mantenimiento preventivo y pre planeamiento del equipo
 Protección de base espejada

4.2. Analizar el Impacto Sobre el Negocio.

 Identificar y establecer la importancia de diferentes funciones críticas del
negocio
 Analizar el valor de la información
 Entender los alcances del impacto

Curso 5k3 - Grupo Nº 8 Pág. 5

U . T. N . - F. R . C . Auditoría de Sistemas

 Pérdidas financieras e interrupción de la continuidad del negocio

 Efecto en los clientes y proveedores
 Pérdida de información vital
 Impacto en el personal
 El factor tiempo como un aspecto crucial

4.3. Desarrollar Estrategias de Recupero.

 Determinación de niveles de riesgo aceptables
 Establecer de la cantidad mínima de recursos necesarios para la continuidad de
los negocios
 Identificación de los requerimientos de la estrategia de recupero
 Tiempo
 Ubicación
 Comunicaciones entre el personal
 Establecer de sitios alternativos y lugar remoto de almacenaje
 Evaluar la eficacia de los controles
 Costos vs. Beneficios
 Procedimientos de implementación
 Control sobre los procedimientos

4.4. Determinar los Procedimientos para Estructurar un Plan de

Contingencias
 Identificar los equipos de recupero y asignar tareas y responsabilidades

 Preparar Checklists y procedimientos técnicos

 Planificar la activación del sitio de recupero: centro de cómputos alternativo

 Gerenciamiento y administración

 Equipamiento y logística

 Servicios técnicos, comunicaciones, redes y soporte

 Logística e intercomunicaciones entre los sitios

 Preparación de datos

 Tecnologías de back up

 Duplicación de unidades de almacenamiento

 Almacenamiento y Espejado

 Distribuir recursos operativos cuando no hay desastre, evitando que estos se

recarguen en caso de contingencia

Curso 5k3 - Grupo Nº 8 Pág. 6

U . T. N . - F. R . C . Auditoría de Sistemas

4.5. Desarrollar Políticas Estándares y Documentar el Plan.

 Desarrollo de estándares para la documentación del plan
 Asegurar la obtención de los datos críticos, información, programas y
documentación en condiciones de emergencia
 Estimar los requerimientos de equipos necesarios durante el desastre
 Consideración sobre todos los aspectos del gerenciamiento de la emergencia
 Entrenar a los empleados sobre la importancia de su rol en el Plan de
Contingencia

4.6. Asegurar la Efectividad y la Constante Actualización del Plan.

 Determinación de objetivos
 Desarrollo de métodos de testeo confiables
 Evaluación de tipos de tests:
 Simulaciones y walk-throughs
 Testeo modular y funcional
 Testeo anunciado y no anunciado
 Testear el Centro de Operaciones de Emergencia (COE)
 Iniciación y establecimiento de comunicaciones
 Obtención de la documentación y otros tipos de datos
 Equipamiento
 Evaluación de los resultados del test
 Optimizar el enlace durante la contingencia, permitiendo transmitir muchos
datos en el menor tiempo posible
 Mantener Actualizado el Plan de Contingencias

Curso 5k3 - Grupo Nº 8 Pág. 7

U . T. N . - F. R . C . Auditoría de Sistemas

5. Implementación del Plan de Contingencia

5.1. Niveles de Contingencias

No toda interrupción en el servicio debe ser clasificada como una contingencia. Es
necesario tener definido un sistema de clasificación de las aplicaciones en el orden
crítico a fin de determinar los pasos a seguir en cumplimiento del plan definido.
Para este fin es recomendable establecer una guía de criticidad respondiendo a las
siguientes preguntas:
 ¿Cuánto puede operar el área sin los sistemas?

 ¿Cuál es el riesgo y/o pérdida económica?

 ¿Qué problemas pueden llegar a ocurrir si falla determinado sistema?

 ¿Podríamos sufrir penalidades, multas?

 ¿Existe impacto en la imagen de la entidad?

 ¿Podemos afectar / impactar en la operativa de clientes en forma significativa?

 ¿Podemos perder evidencias y/o registros y/o pruebas importantes y vitales

como resultado de la discontinuidad del sistema?
 ¿Existen alternativas de procesamiento ante una falla?

Según los criterios utilizados para determinar si una aplicación es crítica o no, se
deben definir diferentes niveles, como se detallan en el cuadro siguiente:

Nivel de Criticidad Descripción

Críticas o Nivel 4 Aplicaciones extremadamente críticas o vitales para la continuidad del negocio. Estos son
sistemas de información que deben estar disponibles en orden para que la organización
sea viable
Necesarias o Nivel 3 Actividades importantes que deben ser recuperadas dentro de un razonable período de
tiempo para mejorar el nivel de operaciones.
No críticas o funciones Funciones que pueden ser excluidas de la lista de críticas, que podrán ser convenientes
deseables o Nivel 2 para tener eficiencia en las operaciones.
Triviales o No Sistemas que pueden ser excluidos del plan, pues no afectan a las operaciones del
importantes o Nivel 1 negocio.

5.2. Período Crítico de Recuperación

El período crítico de recuperación es el tiempo en el cual debe reanudarse el
procesamiento del negocio antes de incurrir en pérdidas, por lo cual se debe
realizar el siguiente análisis:
 Aplicaciones a recuperar en tiempo crítico

 Interrelación entre usuarios y el procesamiento de la información

 Prioridades de procesamiento

5.3. ¿Cómo armar un Plan de Contingencias?

Para poder armar un plan se debe tener en cuenta los siguientes puntos:
 Definición de los objetivos del plan

 Identificación de escenarios, amenazas y riesgos

Curso 5k3 - Grupo Nº 8 Pág. 8

U . T. N . - F. R . C . Auditoría de Sistemas

 Determinación de las aplicaciones críticas

 Establecer prioridades de recuperación
 Documentación de procedimientos
 Evaluación de recursos indispensables
 Establecer criterios de mantenimiento y prueba
 Definición del entrenamiento del personal involucrado
 Confección de la documentación total

5.4. Elementos que Componen un Plan de Contingencias

 Documentación del plan
A continuación detallamos los puntos que debe contener la documentación:
 Políticas
 Objetivos
 Alcance
 Organización de la emergencia: responsable, soporte técnico, seguridad
 Diagramas de instalaciones y de redes
 Aplicaciones críticas y no criticas

 Equipo de trabajo o personal necesario para llevar a cabo el plan

El equipo de trabajo va a estar compuesto por un comité de seguridad que se
va a encargar de realizar el análisis, va a definir las alternativas de solución y
evaluación de las mismas. La coordinación va a estar a cargo de la gerencia
de sistemas.
Dependiendo del tamaño de las operaciones del negocio podrán designarse los
equipos de:
 Acción ante la emergencia
 Manejo de la emergencia
 Almacenamiento OFF-SITE
 Operaciones de emergencia
 Recuperación de la red
 Preparación de datos y registros
 Soporte Administrativo
 Evaluación de daños
 Seguridad
 Insumos
 Aplicaciones
 Documentación
5.5. Procedimientos de Respaldo
Como requisito mínimo para una contingencia se debe tener en cuenta la copia de
datos en intervalos regulares y archivo de los datos en algún lugar seguro.
Las estrategias de copia de seguridad y archivadas son criticas para la protección
de los datos. Sin copia de seguridad apropiada, una corporación podría perder
mucho por cada día que dure su inactividad.

Curso 5k3 - Grupo Nº 8 Pág. 9

U . T. N . - F. R . C . Auditoría de Sistemas

Entre las técnicas de resguardo de datos y programas podemos enumerar las

siguientes:
 Copias de Seguridad On-Line

 Copias de Seguridad Off-Line

 Sistemas de Archivos Jerárquicos

 Copias de Seguridad en Cinta

 Copias de Seguridad Incrementales

 Copias de Seguridad Diferenciales

 Mirroring o Duplexing

 Medios y Dispositivos de Back – Ups

 Discos Flexibles

 Minicartucho

 Cinta de Digitalización Helicoidal

 Cinta de Audio Digital (DATS)

 Unidades de cintas varias

 Discos ópticos

Si el resguardo de los datos y programas se hace en cintas de resguardo se debe

definir una metodología de backups, es decir, los métodos de rotación de las
cintas. Para definir una metodología es aconsejable:
Disponer de varios conjuntos de copias de seguridad (al menos dos, en sitios
distintos); Establecer un esquema de rotación de las cintas, uno de los más
sencillos utiliza tres conjuntos de cintas: la copia de seguridad de la semana
actual, la previa y la de hace dos semanas.
Muchas de las empresas de nuestro país han comenzado a tomar conciencia de la
problemática que causa perder los datos, por lo cual se encuentran implementando
nuevas medidas de seguridad física para protegerlos, como medida de prevención.

5.6. H a r d w a r e y S o f t w a r e Al t e r n a t i v o
Las contingencias más costosas generalmente son las que perjudican las
instalaciones físicas primarias, como alternativa de solución ante esto, existen
sedes de Hardware alternativo o instalaciones de Backup Off Site. Estos son
lugares alternativos donde se puede continuar realizando el procesamiento de
datos de la empresa, en caso de producirse una contingencia de esta clase. Entre
este tipo de instalaciones podemos mencionar las siguientes:
 H o t S i t e s : son centros de procesamiento totalmente configurados y listos para
operar en pocas horas.
 W a r m S i t e s : centros parcialmente configurados, con algún equipo periférico y
sin CPU o una de menor tamaño.
 C o l d S i t e s : centros con el ambiente básico para montar un centro de
procesamiento de información.

Curso 5k3 - Grupo Nº 8 Pág. 10

U . T. N . - F. R . C . Auditoría de Sistemas

5.7. Procedimientos de Emergencia

Los objetivos de los procedimientos de emergencia son: administrar las tareas
inmediatas y posteriores al siniestro (son de corto alcance) y minimizar la
interrupción y daño potencial.
Principales procedimientos a establecer:
 Determinación de la Contingencia / Interrupción:

 Masiva
 Importante
 Parcial y Temporaria
 Menor
 Contacto con los responsables / organizar Equipos
 Contacto con Proveedores
 Contacto con Compañía de seguros
 Evaluación de daños, capacidad operacional remanente, determinando y
priorizando aplicaciones críticas a procesar

5.8. Prueba del Plan de Contingencias

Una vez confeccionado el plan deberá realizarse pruebas del mismo, uno de los
propósitos de las pruebas
Es determinar que tan bien trabaja el plan, y qué partes del plan sea necesario
mejorar. Las pruebas del plan deben contar con:
 Especificaciones de la prueba

 Verificar que la información del plan sea completa

 Evaluar el rendimiento del personal involucrado

 Evaluar el entrenamiento del resto del personal

 Evaluar la coordinación entre equipos

 Medir la real capacidad de recupero de datos

 Evaluar el estado de los materiales reubicados

 Medición del rendimiento general

 Pre-Prueba

 Prueba

 Post – Prueba

 En Papel

 A Nivel de Recuperación

 Totalmente Operativa

Durante la fase de las pruebas debe llevarse la documentación detallada de las

observaciones, los problemas y soluciones, determinar los resultados de las
mismas a fin de poder analizar:
 Tiempo de tareas

 Cantidad de trabajo

 Recuento de necesidades

 Exactitud de la recuperación

Curso 5k3 - Grupo Nº 8 P á g . 11

U . T. N . - F. R . C . Auditoría de Sistemas

5.9. Mantenimiento del Plan de Contingencias

Una vez finalizado el plan, deben hacerse revisiones y actualizaciones al mismo de
acuerdo con un cronograma, para reflejar un reconocimiento continuo de los
requerimientos cambiantes.
Es aconsejable contemplar las siguientes tareas para el mantenimiento del Plan de
Contingencias:
 Desarrollar un cronograma de revisiones

 Comunicar los roles al personal involucrado

 Revisar los comentarios y sugerencias

 Armar y coordinar las pruebas

 Participar en las pruebas

 Desarrollar un cronograma de entrenamiento

 Mantener un registro de actividades

 Actualizar el directorio de notificaciones

5.10. Auditoría del Plan de Contingencias

 Se debe evaluar el Plan de Contingencias para observar el grado de adecuación
y actualidad, mediante su revisión y comparándolo con los standard apropiados
y/o regulaciones.
 Se debe verificar que el Plan de Contingencias sea efectivo para asegurar que
las capacidades de procesamiento de información puedan ser reanudadas
rápidamente luego de una interrupción imprevista, mediante la revisión de los
resultados de pruebas previas realizadas por personal del centro de
procesamiento electrónico de datos y de los usuarios.
 Se debe evaluar el almacenamiento off – site para asegurar su adecuación por
medio de la inspección de las diversas facilidades, revisión de sus contenidos,
seguridad y controles ambientales.
 Se debe evaluar la habilidad del personal del centro de procesamiento
electrónico de datos y los usuarios para responder efectivamente en situaciones
de emergencia, mediante la revisión de los procedimientos de emergencia,
entrenamiento del personal y los resultados de las pruebas.
 Se debe evaluar el almacenamiento en la sede alternativa, para asegurarse de
la presencia, sincronización y actualidad de los medios magnéticos, resguardo
de datos, resguardo de aplicaciones y la documentación crítica.

Curso 5k3 - Grupo Nº 8 Pág. 12

U . T. N . - F. R . C . Auditoría de Sistemas

6. Conclusión
Está claro cuales son las desventajas que trae aparejado no contemplar o prevenir de
antemano posibles contingencias en los distintos sistemas informáticos de una
organización ya que las mismas pueden ocasionar perdidas irrecuperables, por eso
decimos que lo importante de esto es hacerse la pregunta ¿Qué pasaría si ocurriese
una contingencia?, y hacer un análisis adecuado de Costo-Beneficio para poder
dimensionar el valor que tiene la información, como así también la continuidad del
negocio.
Técnicamente, un plan que no fue escrito, que nunca fue probado, o que no está
disponible cuando se lo necesita, es simplemente una pérdida de tiempo, dinero y
energía. No existe tal cosa como un plan no escrito, es sólo una idea, y no sirve
absolutamente de nada cuando las cosas fallan.
Esto nos lleva a afirmar que todo lo que se planifique en materia de Plan de
Contingencias es una inversión a largo plazo en la organización y no un gasto; pero no
debemos perder de vista la relación costo beneficio, siempre existirá un modo más
económico de hacer las cosas y recuperar la información y en general este modo más
económico demandará un mayor tiempo de interrupción. Lo más difícil será determinar
el punto de equilibrio óptimo para la organización y este es uno de los puntos que
mayor valor agregado dará al informe final del Auditor.
Realizar un análisis correcto en el momento adecuado nos permite identificar posibles
mejoras de especificaciones en los distintos sistemas informáticos, como así también
de las instalaciones y en muchos casos provoca cambios que hacen maximizar las
capacidades de los mismos y mejorar los procesos de negocios para eliminar o
disminuir los riesgos y los puntos críticos detectados. Por este motivo debemos ver al
plan de contingencia como un objeto dinámico que debe acompañar el crecimiento y
los cambios que suceden en la organización
Para finalizar, es importante destacar la importancia que tiene concientizar a los
individuos responsables, tanto del área de sistemas como de toda la organización en
sí, con el objetivo de tomar los recaudos necesarios en cuanto al cuidado que merece
la información y los equipos que la contienen.

Curso 5k3 - Grupo Nº 8 Pág. 13

U . T. N . - F. R . C . Auditoría de Sistemas

7. Anexo I

7.1. Check List de Auditoría del Plan de Contingencia

Condiciones
V er i f i c a c i ó n
Si No No Aplica
1. *¿Existe un plan de contingencia documentado?
2. *¿Se identificó un responsable del mantenimiento e
implementación del plan de contingencia?
3. *Se identificaron y evaluaron los riesgos potenciales
en lo referido a:
 Ubicación
 Infraestructura
 Back up y protección de información
 Seguridad de la información (hardware, software,
datos, redes)
 Protección de base espejada
4. Impacto en el negocio
 *¿Se identificaron las funciones críticas del
negocio?
 *¿Se cuantificó el valor de la información?
 *¿Se valoraron las pérdidas financieras para el
negocio de la interrupción de la continuidad de los
sistemas?
 *¿Se determino el impacto en los clientes y
proveedores de la interrupción?
 *¿Se determinaron los tiempos de inoperatividad
permitidos para cada una de las funciones del
negocio (críticas y no críticas)?
5. Estrategias de Recupero
 *¿Se determinaron los riesgos y los niveles
aceptables para los mismos?
 *¿Se identificaron los recursos mínimos
necesarios para el funcionamiento del negocio?
 *¿Se establecieron sitios alternativos de
almacenaje y procesamiento?
 *¿Se evaluó la eficacia de los controles
preventivos?
 *¿Están documentados los procedimientos de
implementación para las estrategias de recupero?
6. *¿Se identificaron las capacidades de procesamiento
mínimas requeridas para las acciones de
recuperación?

Curso 5k3 - Grupo Nº 8 Pág. 14

U . T. N . - F. R . C . Auditoría de Sistemas

Condiciones
V er i f i c a c i ó n
Si No No Aplica
7. *¿Se identificaron los procedimientos técnicos de
recuperación y la secuencia de ejecución de los
mismos?
8. Servicios técnicos, comunicaciones, redes y soporte
 ¿Se cuenta con proveedores alternativos para el
servicio de comunicaciones?
 *¿Se cuenta con un respaldo de la información y
los programas en una ubicación física diferente?
 *¿Se seleccionaron las políticas, procedimientos y
tecnologías de backup?
9. *¿Se capacitó al personal en los procedimientos de
emergencia?
10. *¿Se realizan, de manera frecuente y aleatoria,
simulacros de recupero?
11. *¿Se testea la capacidad del centro de cómputos
alternativo?
12. *¿Se evaluaron los resultados de las pruebas y
simulacros de recupero, internas y del centro de
cómputos alternativo?
13. Actualizaciones
 *¿Se mantiene el plan de contingencia actualizado
frente a los cambios ocurridos en el negocio?
 ¿Se evalúan nuevas tecnologías y opciones de
recuperación que mejoren la relación costo
beneficio para el negocio?
14. *¿Es razonable la relación costo beneficio del plan de
contingencia implementado para el negocio?
15. software
 *¿Existe una copia del software original para
reinstalar fuera de la organización?
 *¿Se cuenta con una estimación del tiempo que
llevará la reinstalación para dejar el software
operacional?

Curso 5k3 - Grupo Nº 8 Pág. 15

U . T. N . - F. R . C . Auditoría de Sistemas

Condiciones
V er i f i c a c i ó n
Si No No Aplica
16. Hardware
 *¿Disponemos de un inventario del hardware de la
organización?
 *¿Está actualizado?
 *¿Se identificaron los componentes esenciales de
hardware?
 *¿Son reparables internamente los componentes
esenciales del hardware?
 *¿Hay dependencia hacia un tercero para realizar
reparaciones?
 *¿Existen componentes de hardware que no sean
reparables?

Nota:
Las preguntas indicadas con * (asterisco) son de carácter invalidante, si aplican, para la aceptación del Plan de
Contingencia de la Organización.

Curso 5k3 - Grupo Nº 8 Pág. 16

 U . T. N . - F. R . C . Auditoría de Sistemas

8. Anexo II

8.1. D e f i n i c i o n e s , A c r ó n i m o s y Ab r e v i a t u r a s
Término Definición
Backup Resguardo de la información
Off Site: Fuera de sitio
Hot Sites Cando se refiere a Hot Sites son centros de procesamiento totalmente equipados que
pueden estar en funcionamiento en pocas horas
Warn Sites Son centros de Procesamientos que tienen una estructura parcial
Cold Sites Son centros que tienen una estructura básica, pero para que funcionen hay que montar
todo el centro de procesamiento
Mirroring Duplicación de la información en línea, es decir, en el momento que se realiza una
transacción, se duplica

8.2. Referencias
A continuación se describen todas las fuentes consultadas para la generación del
presente trabajo.
ID del Documento Título del Documento Número de Fecha de Organización que lo
Reporte Publicación Publica
http://www.iir.com.ar “Como preparar y desarrollar un 30/01/2002 Institute for
(Sección Training) Plan de Contingencias para prevenir y International Research
recuperar Desastres Informáticos”
http://www.jebsen.com.ar Plan de Contingencia De Sistemas / IT 01/11/2000 Jebsen & Co.
(Sección Información -
Departamento de
Sistemas / IT)
http://www.jebsen.com.ar Plan de Contingencias 01/11/1998 Jebsen & Co.
(Sección Información -
Departamento de
Sistemas / IT)

Curso 5k3 - Grupo Nº 8 Pág. 17